Reversing the Trendnet TS-402

The Trendnet TS-S402 is a discontinued network storage enclosure that was sold to individuals for personal data storage. Like every Internet-of-Things (IoT) device, it runs on software programmed and/or configured by the manufacturer before shipping it to the end-user, i.e. the firmware. Firmware versions 2.00.10 and below of this particular device have a serious vulnerability allowing remote root access . This target thus provides an excellent exercise for reverse engineering while providing an example of a vulnerability that is unfortunately way too common in IoT: backdoors by design. In this post, we will introduce Binwalk and provide the background necessary to do the same on a large variety of firmware for consumer-level devices, using the TS-S402 as a practical example. A video of this post is also available.

Trendnet TS-S402
The Trendnet TS-S402 Network Storage Enclosure (from trendnet.com)

The Trendnet TS-S402

Before reversing any device, it’s important to actually understand its functionalities, components and any other piece of information that may help along the analysis of its firmware. The webpage of the product highlights the following features:

  • Access your data from the Internet (FTP) and on your local network
  • Microprocessor: Marvell 88F5182
  • IDE Controller: ITE IT8211F
  • Real Time OS: Embedded Linux (Kernel Version 2.4.25)
  • File Protocols: Microsoft Networks (CIFS / SMB) Internet (HTTP 1.1) FTP, FTPS (SSL FTP)

Why are these facts important? Not all of the will be useful, but some may provide you with an overall idea of what to expects once you start analyzing the firmware file. In many cases, especially with consumer-level devices, reversing firmware is fairly straightforward and common open-source tools will do the heavy lifting for you. But if you move on to industrial firmware, awareness of the device is important as you will be faced with unheard operating systems, libraries and unknown file formats. In this case, we can expect to see a Linux-based Operating System (OS) hosting a HTTP and FTP server, along with Samba compatibility. The manufacturer is even generous enough to provide the underlying microprocessor, which can be helpful when conducting even deeper analysis for vulnerabilities in the binaries.

Reversing the Firmware

The vulnerability we are looking for is present only in versions 2.00.10 and below of the firmware, which you can download from the repository of the company. Unzip the archive and you’ll to obtain the following files:

  • TS-S402_FW_2_00_10.bin
  • readme.txt
  • release_TS-S402.txt
  • REMOTE_PACKAGE_2_20.bin

It’s always a good idea to read the release notes and README files. Doing so may save you time and headaches trying to figure things out. If you’re into bug hunting, the release notes can be useful to list the changes and patches included in this version, providing potential hints to patched vulnerabilities of previous versions.

The two “.bin” files contain the programs and OS of the device. In this case, based on the filename, the TS-S402_FW_2_00_10.bin is the main firmware file and thus, the focus of this post. The first step is always to check if we can determine the file type by using the file command. If we are lucky, it is a known file type and some application exists to extract the relevant files/information out of it.

However we are not so lucky. The file command returns “data”, which means it found the file to be binary data without any specific structure or format. So we will need to use a more powerful tool: binwalk. Binwalk is very useful reverse engineering toolkit which can analyze and extract files from unknown binary files. However note that it can also return quite a few false positives. The only way to recognize them is with experience and trial-and-error. If not already done, install binwalk with apt using  sudo apt-get install binwalk and run the following command:

The command above asks binwalk to check out the TS-S402_FW_2_00_10.bin file and try to find interesting files or structures inside it. We use the “-x lzma” argument to eXclude any findings about LZMA-compressed data: these are false positives in this case. You will obtain the following result:

In other words, there seems to be a 32-bytes header followed by a GZip-compressed file. At this point, we want to carve this gzip file out of the binary file for further investigation. You can use the dd command to do so, but binwalk provides the -e option to Extract files for you.

The carved files will be outputted to a directory labelled _TS-S402_FW_2_00_10.bin.extracted, in which you will find a single file called 20, which is the offset of the file in the larger firmware. Using the file command again, we now get a more interesting result:

This time, the file command clearly recognized a TAR archive, meaning we can simply untar the file with the command below:

This archive contained even more files: a uImage and a filesystem:

  • uImage
  • rootfs.armeb.squashfs

The uImage is the boot loader of the firmware and you will often find this file or something similar in most Linux-based firmware. Analysis of the uImage will be left for another post. For now, we are interested in the filesystem contained in rootfs.armeb.squashfs, which as its name implies, is a SquashFS. To access the files it contains, we can normally use the unsquashfs tool, however in this case doing so won’t work:

Depending on how the file system was created and the development software used, it may have incompatibilities with the way unsquashfs expects the file system to be structured. As a workaround, we will use Sasquatch, which is more flexible when it comes to extracting file from non-standard Squash file systems. Clone the project and build the code by following the instructions n the README.md file, or you can download a pre-compiled binary for Ubuntu and variants. Now let’s try again carving out the files, but with Sasquatch this time by typing  ./sasquatch rootfs.armeb.squashfs . After a while, Sasquatch will extract all files in the squashfs-root directory, at which point you can finally access the files hosted on the targeted device.

Find the Backdoor

There is a fairly obvious backdoor hidden in the file system. Go ahead and explore the files and configuration and see if you can find it. When you are ready read on.

Most commercial devices are accessible remotely via a web interface. The web server and its contents are therefore a good starting point to hunt down potential vulnerabilities. On the TS-S402, the web application is located in the /home/httpd directory. The partial listing of the contents of this directory is included below:

As you can see, one of the web page is named “backdoor.html”; quite an obvious indicator that something is wrong. If you look at the webpage, you’ll notice that it seems to enable the telnetd daemon, thus allowing Telnet connections to the device. Unless specially configured to be blocked in the network firewall, this web page should be accessible to anyone on the network, potentially anyone if facing the Web. All that is missing right now is credentials to access the device. Let’s look at /etc/shadow to see if we can potentially figure out the default password for the root account:

Well, there isn’t any password setup for the root account. So in other words, anyone who can access the backdoor.html page on the device can enabled remote Telnet connections, and then login as root. While I haven’t tested it as I do not own this device. this vulnerability was previously confirmed and reported.

Conclusion

This post provided an example of reversing the firmware of a consumer-level IT appliance to locate vulnerabilities allowing remote access to the device. Such vulnerabilities may seem trivial an unimportant until a botnet such as the Mirai botnet comes along and use tens of thousands of these vulnerable devices – which are rarely updated – to DDoS websites across the web. Hence the need to understand the techniques and skills require to pwn these devices in order to defend them.

See Also

Learn More

 

 

Reversing the Parrot SkyController Firmware

Introduction

The Parrot SkyController is a remote control sold for long range flights with the Parrot Bebop drone, sometimes used in the real estate sector. It enables integration of smartphones and tablets for flight control via Wifi connection, allowing transmission of real-time data from the drone. In other words, the SkyController acts as an intermediate between the flight management software (smartphone/tablet) and the actual drone. In this post, we explain how to reverse the firmware of the SkyController to be able o view the contents of the internal operating system and understand its inner workings. A lot of the information provided is based on [1] and is applied on this specific firmware. Code is provided along this post that will extract files and information from the SkyController firmware.

The Parrot SkyController Device
The Parrot SkyController Device (taken from the Parrot Store)

Contents

The firmware of the Parrot Skycontroller appears to be a well-defined format which is reused across multiple products from the company. The firmware contains 2 types of structures the header and a sequence of “data entries”. The header is located at the beginning of the file and is followed by multiple entries which contains configuration and file system information. We will look at both structures in the following sections.

Header

The firmware header starts with four magic bytes which spells out “PLF!”. These can therefore be used to identify valid Parrot firmware files. A quick Python snippet is included below as an example.

Immediately after the magic bytes, a sequence of thirteen 32-bit unsigned integers provides additional information about the firmware. Defined as a C structure, the header would look something like this:

The header version specify the type of format used for the firmware header. Within the SkyController firmware, the value for this field was “0x0D”, possibly indicating that there are 14 variations of header formats. The header size provides the number of bytes included in the header while the entry header size specifies the number of bytes in headers of entries within the firmware. The next 5 integers are undefined at the moment, as is the before-last integer. One of them is likely a CRC32 checksum. The dwVersionMajor, dwVersionMinor and dwVersionRevision defines the version of the firmware. Lastly, the header contains the size of the file in bytes.

Entries

Each entry has a header of constant size, which is specified within the firmware header by the dwEntrySize value. In the SkyController, each entry is composed of 20 bytes used as follows:

 

The section type specify the type of data contained within the entry. This can be configuration data, partition details or file information. These will be explained in further details in the sections below. The entry size contains the number of bytes within the entry, without consideration for null-byte padding. This field is followed by a CRC32 value. It’s unclear at this point how this value is calculated. The last known integer is the size of the data once uncompressed. If this value is 0, then the contents are not compressed. Each type of entry have further fields defined, and these are explained below.

Firmware Entries

There are multiple types of entries within the firmware. In this section we will describes the one we came across in the file we have analyzed.

Bootloader and Boot Configuration (0x03, 0x07)

Entry 0x03 contains a binary file which appears to be the bootloader of the system based on strings contained within, however more analysis will be required to understand how it actually works. In the SkyController, a PLF file was observed, but within that PLF file, this entry had binary data. Similarly, entry 0x07 also appears to be related to the boot process as shown by the string “ecos-bootloader-p7-start-246-ge30badf”, “ecos” referring to the eCos operating system.

File System Data (0x09)

There is a  “File System Data” entry for each file contained in the firmware. As such, this entry is the most common one. Depending on whether the file is compressed or not, the structure of this entry is slightly different: when its contents are uncompressed, this entry starts with the filename (or directory name), which is a zero-terminated string. The name is then followed by 3 unsigned integers.

The first integer contains flags specifying the type of file, which can be a directory, a normal file or a symbolic link. This is specified by reading the bits 12 to 15. The 12 other bits contains the permissions of the file. Converted into octal form, the last 12 bits will provide the same format as the one used in Linux. For example:

Extracting File Permissions from the Firmware Entry
Extracting File Permissions from the Firmware Entry

When compressed, the flags are within the Gzip-compressed data. The data must therefore be first uncompressed and then, the same procedure applies: the filename will be a null-terminated string right at the beginning, followed 3 unsigned integers, the first containing the type and permissions. The remaining bytes are the content of the file. In the example below, the filename is system/pulsar/etc/boxinit.hosted. The flags are 0x000081A0 (little-endian) and the contents of the file starts at 0x32. 

Partition Data (0x0B)

The 0x0B entry contains information about partitions on the device.The header of this entry is composed of 10 values. The first 4 integers are version information, the next 5 ones are unknown and the last unsigned integer is the number of partitions defined within the entry.

For each partition defined within the entry, a sub entry is available which contains further information about the partition: the device ID, volume data and the mount point on the target device. The defining structure for this entry are:

Volume type can be either RAW, STATIC and DYNAMIC. A raw partition contains no file systems, for example swap partitions. Static partitions are read-only, such as the boot partition and finally, the dynamic partitions are read-write and contains modifiable files.

Installation Data (0x0C)

This entry was included early in the file and contained another PLF file within its data. This PLF file contained a 0x00 entry, which is unknown, a 0x03 entry and a 0x07 entry. The 0x07 entry contained boot options:

Conclusion

I have upload a Python program [2] which will extract information and files from the SkyController firmware here. It also successfully extracted files for a Bebop2 firmware and I suspect it will work for other recent firmware. With additional work, it may reverse older ones. Repacking an unpacked firmware should be doable, but I do not have any of the device to test it out. Before doing so, determining how the CRC value for the header and each entry is calculate is required. Future work would include testing additional firmware files and implementing the program to repack an unpacked and modified firmware. Finally, reading the eCos documentation may clarify many of the unidentified values.

References

[1] “PLF File Format”, E/S and I, https://embedded-software.blogspot.ca/2010/12/plf-file-format.html (accessed 2016-12-13)

[2] Racicot, J. “Vulture”, https://github.com/InfectedPacket/vulture (accessed 2017-01-03)

The Byte-BOS Real-Time Multitasking Operating System

Compared to operating systems in general computing, the world of embedded devices remains a world to be discovered by security analysts and hackers alike, and it offers much to explore. While reverse engineering of many newer appliances is revealing well known operating systems such as Windows or Linux, others remains fairly unexplored, such as TinyOS or μOS. Legacy devices, still in used across many industries, also provide a rich variety of unknown software and architectures. One of them is the Byte-BOS Real-Time Multitasking Operating System (RTMOS).

Introduction

Compared to operating systems in general computing, the world of embedded devices remains a world to be discovered by security analysts and hackers alike, and it offers much to explore. While reverse engineering of many newer appliances is revealing well known operating systems such as Windows or Linux, others remain fairly unexplored, such as TinyOS or μOS. Legacy devices, still in use across many industries, also provide a rich variety of unknown software and architectures. One of them is the Byte-BOS Real-Time Multitasking Operating System (RTMOS). This short article attempts, based on limited information, to detail this little known system, explore its history, usage and basic composition.

History

The Byte-BOS RTMOS was initially developed in 1994 by Numerical Services Inc. The company, defunct since 2004, sold the full C source code of the RTMOS to customers for 7495 $USD. Possession of the source code allowed the buyer full customization of the operating system according to the device being designed. The system supported a restricted set of microcontrollers (see table 1) including the Intel x86 and Motorola M68000. Other lesser known microprocessors supported included architectures from Hitachi, Mitsubishi and Texas Instruments, which were used in embedded devices within the medical, industrial and telecommunications sectors. Due to the long life-cycle of these devices, it may still be possible to identify devices leveraging the Byte-BOS RTMOS. Development and support for the RTMOS ceased around 2004. As such, documentation is very scarce, and remnants of information are available only via the Internet Archive [1]. At the time of writing, the domain “www.bytebos.com” resolves to “Scheumacher Engineering”, owned by the original developer of Byte-BOS. However the website is nothing more than a single page which was last updated in 2013.

Table 1 – Microprocessors supported by the Byte-BOS RTMOS.
Intel 80×86 Coldfire Mitsubishi M16C Texas Instruments
C2x/C5x DSP
Intel 80188/86 Motorola 68000 Mitsubishi M32D Texas Instruments
C3x/C4x DSP
Intel 80×86 (32bit) Motorola 68HC11 Hitachi H8300 ARM/THUMB
Intel 8096 Motorola 68HC16 Hitachi H8300H
Intel i960 Mitsubishi
M37700
Hitachi SHX

Description

The Byte-BOS RTMOS is a minimal operating system providing task scheduling management for user applications, along with typical OS activities such as interprocess messaging, memory allocation and prioritization. It performs pre-emptive and non-pre-emptive scheduling of an unlimited number of queued tasks. The system enforces scheduling via interrupt service routines (ISRs) which can suspend and/or resume tasks based on events and their priority. When multiple tasks with a similar priority are requesting resources, the RTMOS assign the resources via a round-robin selection method.

As other operating systems, memory allocation appears to follow a standard process by keeping track of used and free memory chunks via a heap implemented by a double-linked list, which is the data structure used across the RTMOS to store unlimited numbers of objects. Tasks can dynamically allocate and free memory as needed. It also manages events and interaction with devices on behalf of user applications by abstracting the underlying hardware via a Device object (see figure 1). Byte-BOS also provides inter-tasks communications mechanisms for synchronization amongst tasks such as messages and semaphores.  In terms of data structures the double linked list and buffer objects appear to be the main structures used across the RTOS. Memory chunks, tasks and most of the other objects are all managed via the List object.  It also supports the queue structure used to manage tasks. A software stack is also provided and used by tasks to run.

Security-wise, Byte-BOS does not have any authentication or specific security methods for access to memory or special “kernel” functions; all tasks have the same level of authority than the RTOS. Basically, Byte-BOS is completely flat.

Architecture

The RTMOS is written in C or specific variety of C specification depending on the targeted microprocessor. The 10 main components of the operating systems are represented in figure 1 and provide an excellent overview of the functions accomplished. A simulated “this” pointer to the various “struct”s is made available to the developer to give an Oriented-Object Programming (OOP) feel. This section describes briefly the main components of Byte-BOS, along with some of the features marketed by the original developer.

UML Representation of the different objectsfooun in the Byte-BOS RTMOS
Figure 1 – UML Representation of the different objects defined in the Byte-BOS RTMOS

The Task Object

The main object of the RTMOS is the Task object, which is very similar to the similar concept modern software development. Just as in any C/C++ object, a constructor is initiated prior to executing the body of the task, which is defined by the developer to conduct a specific task. Data of the task is allocated and accessible via the this_data pointer. Tasks also allocate sub-objects, opens required devices, initialize variables and synchronize state machines. Once constructed, the task runs its main function until it returns or is removed. Access to a task is done via the this_task pointer. Both pointers described are always in scope and usable within the task. Once the main task completes, the destructor of the structure is called, which frees memory and pointers of sub-objects. It also terminates any internal state machine.

The Memory Object

This object manages the memory heap and stores the pointer to the heap, the block size and the number of memory blocks. It also exposes various functions for memory management, mainly alloc_fmem and free_fmem. The heap is implemented using a double-linked list in which each node contains metadata about the memory blocks. While details are not available, it can be assumed that the size of the block, its status (free or allocated) and a pointer to the next block is included.

The Semaphore Object

As its name implies, the Semaphore is used for signaling and control between multiple tasks by either being in the Up or Down status. A timeout can be defined as needed.

The MessageBox Object

The MessageBox acts as a central repository for tasks to exchange data. Tasks and ISRs can create messages to initiate other tasks or exchange . The MessageBox basically provides two functions: put and get. When a new message is created, memory is allocated. Similarly, the memory is freed when retrieved from the box.

The Timer Object

Similar to any standard timer in other system, this object is used to create timeouts and schedules of tasks and events.

The Event Object

Events are created by tasks and ISRs to schedule other tasks.

The Device Object

This item abstracts interaction between the user application and the hardware device. It does so by pointing to the memory blocks used by the device and managing input/output to the area.

The List, Queue and Buffer Objects

These objects, as their name implies, are implementation of a linked list, a queue and buffer data structures.

Features

Byte-BOS boasted the following additional features on their website from 2000, providing some extra insight on the internals of the system.

Interrupt Handling

ISRs can make operating systems calls and schedule tasks by including the ENTER_ISR and EXIT_ISR macros at the beginning and end of the routine. Most services are available to ISRs, giving them considerable access over the entire OS.

Critical Section Handling

Byte-BOS provides critical section handling by protecting non-reentrant code sections from both interrupt and task pre-emption. Protection of critical sections appears to be done via the following mechanisms:

  • Disabling interrupts
  • Locking and unlocking code sections
  • Prioritization of tasks

Task Execution Trace

Tasks are provided with a trace buffer configurable at both compile time and run time. The trace buffer contains information about the sequence of calls, the parameters passed, and the return value of the called function. The tracing option is extremely useful for debugging purposes.

System Requirements

The Byte-BOS RTMOS requires very little in terms of resources. While the requirements varies depending on the underlying processor, the size of the kernel is a few kilobytes, while the RAM requirements are less than 100 bytes of globally accessible memory and less than 100 bytes per task and ISR. The detail figures are listed in table 2.

Table 2 – Memory requirements for the Byte-BOS RTMOS according to microprocessor
Microprocessor Minimum Kernel
Size (KB)
Maximum Kernel
Size (KB)
RAM Requirement
for Global Variables
(bytes)
RAM Requirement
per Task (bytes)
Intel 80×86* 4 10 28 30
Intel 80×86
(32bit)*
6 15 48 58
Intel 80188/86* 2 10 28 30
Intel 8096 2 8 20 20
Motorola 68000 1.5 12 50 70
Motorola 68HC11 1.2 8 28 20
Motorola 68HC16 2 8 28 20
Mitsubishi M37700 2 10 28 20
Mitsubishi M16C 2 12 64 48
Mitsubishi M32D N/A N/A N/A N/A
Hitachi H8300 1.2 8 28 20
Hitachi H8300H 2 10 38 40
Hitachi SHX 7.8 19.5 72 60
Texas Instruments
C2x/C5x DSP
1.2 8 28 20
Texas Instruments
C3x/C4x DSP
2.3 19.5 28 words 20 words
ARM/THUMB 4 15 50  70

* For Intel-based architecture, the memory footprint reported above is based on usage of the Borland C++ compiler.

Additional volatile memory is required for objects created dynamically. As such, the numbers provided above do not represent the total amount of memory consumed by Byte-BOS.

Compilers Supported

In general, Byte-BOS supports the development tools and compilers provided by the semi-conductor manufacturer. For Intel-based processors, the Borland C/C++ compiler was supported. The complete list of supported compilers is provided in table 3.

Table 3 – Supported compilers by the Byte-BOS RTMOS.
Microprocessor Supported Compilers
Intel 80×86 Microsoft C/C++ (large model)
Borland C/C++
Watcom C/C++
Intel 80×86(32bit) Watcom, Metaware and most of C compilers
Intel 80188/86 Microsoft C/C++ (large model)
Borland C/C++
Intel 8096 IAR
BSO Tasking Compiler
Motorola 68000 Cross-Code
Intermetrics
Introl
Microtec
Motorola 68HC11 IAR
Introl
Cosmic
Motorola 68HC16 Introl
Cosmic
Mitsubishi M37700 IAR
Microtec
Mitsubishi M16C IAR
Mitsubishi Compiler
Mitsubishi M32D N/A
Hitachi H8300 IAR
Microtec
Hitachi H8300H IAR
Hitachi SHX GNU
Green Hills
Texas Instruments
C2x/C5x DSP
Code Composer /
Texas Instrument Compiler
Texas Instruments
C3x/C4x DSP
Code Composer /
Texas Instrument Compiler
ARM/THUMB  ARM

Identification

Devices using the Byte-BOS RTMOS can be identified by looking at ASCII and Unicode strings in their firmware. In almost all cases, if not all, the firmware will contain a copyright notice identifying it as well as the target microcontroller it was compiled for. For example, by extracting the strings from the firmware for the Seagate Cheetah 10K.6 Disc Drive, either using the simple strings.exe (or strings in Linux) or IDA, the copyright notice string “Byte-BOS 8096 Multitasking Operating System — Copyright 1990 Numerical Services Inc.” can be observed (see figure 2).

Byte-BOS Copyright Notice into the Firmware of the Seagate 10K.6 Disc Drive
Figure 2 – Byte-BOS Copyright Notice into the Firmware of the Seagate 10K.6 Disc Drive

While appliances posterior to 2004 will likely use modern RTMOS such as Linux , Byte-BOS can still be found on legacy devices. One such example is the Baxter IPump pain management medical device, which refers to its usage in the manual [2]. Of note, the manual refers to the detection of stack overflows within the Byte-BOS RTMOS. Industrial controls, aircraft, telecommunications systems and other systems designed prior to the 2000s may still harbour this little known RTMOS.

Conclusion

The Byte-BOS RTMOS will likely disappear as legacy embedded devices are life-cycled for newer systems with more processing power and extended memory. Until that moment, for developers of these systems, or simple hobbyists, information remains scarce and limited. While we provided a brief overview of its architecture and features, details about creating user applications remains obscured by the lack of online information such as an API description, code examples or more importantly, the source code. Such data would greatly ease development and engineering efforts of legacy systems.

References

[1] “Bytebos Home Page.” Bytebos Home Page. Internet Archive, 20 Oct. 2000. Web. 01 Nov. 2015. <https://web.archive.org/web/19990208011926/http://www.bytebos.com/>.

[2] Baxter IPump Pain Management System – Service Manual, Baxter Healthcare Corporation, Chapter 4 – Troubleshooting, p.4-8. 2007. Web. 01 Nov. 2015. <Link>

Removing Debugging Information from Visual C++/C# Projects

It’s often surprising how many malware programmers forget to do the simplest things. Mostly because many are so concerned with functionality, stealthiness and other production concerns, that details slip easily of their minds – a clear advantage to forensics. One of these details is the Program DataBase (PDB) information added by Visual Studio, which most malware authors used for Windows development. While it may seem innocuous, this string reveals a lot about the operating system used by the author, its user name and most notably, symbols that can be used by IDA and ease understanding of the disassembly.

Introduction

It’s often surprising how many malware programmers forget to do the simplest things. Mostly because many are so concerned with functionality, stealthiness and other production concerns, that details slip easily of their minds – a clear advantage to forensics. One of these details is the Program DataBase (PDB) information added by Visual Studio, which most malware authors used for Windows development. While it may seem innocuous, this string reveals a lot about the operating system used by the author, its user name and most notably, symbols that can be used by IDA and ease understanding of the disassembly. This information allows to link multiple pieces of malware together, by using the username for example. Of course, this also allows for the creation of signatures. Thus, removing this information will add a hurdle to the analysts.

Contents

The Program Database File

The Program Database (PDB) is a binary file used to store debugging information about DLL and EXE files. The PDB file is created when you build your project and stores a list of symbols  their addresses along with the name of the file and the line number on which the symbol was declared. PDB files is also used for services collecting crash data to send it to developers for resolution.

Debugging Information

In Visual Studio, you can select to build your project in Debug or Release mode. In Debug mode, VS will include debugging information with your executable. In Release mode, no debug information is included by default, but in some cases is enabled so that if the program crashes, information can be retrieved and sent to the author for fixing. However for some reasons, some developers don’t really bother to use the Release mode, and simply use the executable generated by the Debug mode. Generally, you don’t want that if you are making malware (or any program really!). If left within the executable, a path to the PDB file will be included and can be extracted:

Path to the PDB file
Path to the Program Database (PDB) file used by Visual Studio for debugging purposes, extracted using the “strings” program.

Within the strings, you can determine that:

  1. The program was developed on Windows 7+ (because of C:\Users folder),
  2. The username of the developer is SUPPORT_23e45RT
  3. The source, or part of it, can be found on Github
  4. The original name of the program is CaitSithTest

These indicators can be useful to link this specific program with others and provide a common link between multiple malware. Additionally, the username could potentially be used to conduct open source research and find linked accounts or forum posts. But wait, there’s more…

If you leave the debugging information, you may be able to restore all the original names of variables and functions of the source code using IDA. IDA will first detect debugging information and ask the analyst if he wants to retrieve it, either via Microsoft – http://msdl.microsoft.com/download/symbols (not browseable)- or by looking locally.

IDA detected that debugging information is available and ask if the user wishes to retrieve it.
IDA detected that debugging information is available and ask if the user wishes to retrieve it.

If for some reason, the user is able to retrieve the information, he will have access to the names of the original symbols, which will make reverse engineering much more easier.

Since symbol information is available, the original names of the variables are displayed.
Since symbol information is available, the original names of the variables are displayed.

Compare the information from the figure above to the figure below, in which debugging information has been stripped at build time:

IDA could not find any debugging information and thus used its own labelling system to identify variables.
IDA could not find any debugging information and thus used its own labelling system to identify variables.

You can see that the variables defined in the first figure, such as ClipboardData, isProcessElevated and isDebugged have been preserved. By keeping information about the symbols, reverse engineering is much more easier compared to figure 2, in which information about the code is lost.

Disabling Debugging Information

To prevent VC from including this information in your executable, right click on your project, go to Project Properties > Linker > Debugging configuration menu. Select No in the Generate Debug Info option.

Removing debugging information in Visual Studio.
Removing debugging information in Visual Studio.

After doing this, rebuild your project and rerun the string extraction program against your binary, the path to the PDB file should not be present in the executable anymore.

no_debug_info
The path to the PDB file is not included in the executable once debugging information has been omitted.

Doing so makes it a bit more difficult to fingerprint the malware and hides information about the author’s system.

Conclusion

This is a simple tactic that is often omitted not only by malware author, but penetration testers, which are often Google programmers, i.e. copy-pasting code snippets from Stack Overflow or googling functions 😉 If you attempt to hide your malware into the System32 folder, looking for this information in the EXE or DLL files will quickly tell you which files are bad, since legitimate files will rarely have this info, or have legitimate looking one. As such, if you want to make sure, create a legitimate-Microsoft-looking user (Bill.Gates) on your machine and put your code into a Microsoft-looking project and path (C:\users\Bill Gates\Documents\HTA\Release\).

ENISA releases list of mobile phones vulnerabilities

The European Network and Information Security Agency (ENISA) release a paper about general vulnerabilities that is affecting or will affect mobile communications. The organization surveyed experts via different medias to gather concerns from the industry about the future of wireless communications. The document discusses security issues about three different types of devices, each using wireless mechanism: mobile devices, contactless cards and smart cards.

Mobiles phones

The paper mentions two possible vulnerabilities on mobiles, which one of them is rather obvious and really didn’t need to be detailed:

  • Theft or Loss of device
  • Untrustworthy Interface

Since a lot of information is store on cells phones and other devices, theft can be a security issue, especially if used in a commercial/governmental context. Since mobiles devices are called to be

Untrustworthy interface refers to any exploits, worms or social engineering that usually affects computers. After all, mobiles use operating systems like any computer such as Android, Windows Mobile, Symbian OS, Linux or iPhone OS
Untrustworthy interface refers to any exploits, worms or social engineering that usually affects computers. After all, mobiles use operating systems like any computer such as Android, Windows Mobile, Symbian OS, Linux or iPhone OS

used for more and more uses, such as purchasing items and services as it’s actually done in Japan, theft will be a problem. As far as I know, not much can be done to prevent mobiles from being stolen except caution. On the other hand, encryption and authentification should be use to protect data stored inside the device.

Untrustworthy interface refers to any exploits, worms or social engineering that usually affects computers. After all, mobiles use operating systems like any computer such as Android, Windows Mobile, Symbian OS, Linux or iPhone OS. None of the OS can pretend to be 100% secure, and none should ever do either. For those who think that such things doesn’t happen on phones, here are a couple of example that might change your mind:

Last year, at the Black Hat conference which took place August 2nd, an attack against the iPhone was carried out by a team at the Independent Security Evaluators security company[1]. By setting up a fake access point with the same SSID and encryption type that an access point previously used by the user, one could use the fake access point to add malicious code to websites requested by the user[2].

At the beginning of the year, Symbian OS was victim of another worm, called Beselo that spread itself by harvesting contacts and sending MMS with a SIS attachment disguised as a picture or mp3 file[3].

In October, Google’s Android shipped with an outdated version of the WebKit package, which could allowed an attacker to steal saved passwords and cookies by crafting a malicious website[4].

Do I even need to give examples for the Windows Mobile OS? If yes, then the ones who come in mind what the one found by Collin Mulliner a while ago and disclosed at the 23rd CCC[5]

As mobile phones become more and more computers, exploiting cell phones will become more and more common.

Smart Cards

The paper mention specifically two issues concerning smart cards:

  • Physical Attacks
  • Side Channel Attacks

Physical attacks consist of studying the underlying hardware in order to reverse-engineer it:

“These kinds of attacks are usually invasive, eg, rewiring a circuit on the chip or using probing pins to monitor data flows. Physical attacks include altering the environment around the card, such as temperature or radiation, in order to induce faults. The goal of the attacker is to bypass security mechanisms and gain secret information stored on the card. In general, modern smart cards are quite resistant to physical attacks. Nevertheless, there have been a number of reverse-engineering attacks in attempts to retrieve private keys or find flaws in the hardware design.[6]

This usually involves a lot of different techniques and lots of time. Concrete examples of applying a physical attack on smart cards could go back to 2002, when two researchers from Cambridge University discovered they could extract data from smart cards by using a camera flash. Without forgetting that modern smart cards are often programmed with a subset of Java, therefore open to programming errors and exploit[7].

Side-Channels attacks are way touchier as they imply retrieving information from the card by analysing physical properties such as power consumption, radiation and signals duration to steal data from the card[8]. Using side-channel attacks can lead to the gathering of sensible information about the implementation of a cryptographic algorithm:

One of the most successful side-channel attacks exploits the correlation between the power consumption of a given device and the data being processed. These Power Analysis Attacks have particular relevance since for some of them, no knowledge regarding the implementation of the target device is needed in order to be effective.[9]

Contactless Cards

  • Skimming
  • Eavesdropping
  • Tracking
  • Relay Attack
  • Falsification of Content
A brilliant example of a skimming attack was the work done in the now infamous Oyster card case
A brilliant example of a skimming attack was the work done in the now infamous Oyster card case

A brilliant example of a skimming attack was the work done in the now infamous Oyster card case[10]. After reverse-engineering the MIFARE contactless card[11] by using acid to remove the plastic and studying the architecture of the hardware used in the card, the encryption algorithm was understood and could be cracked. In order for the hack to work, the attacker needs to skim the victim Oyster card by building a custom reader.

The last attack that I will shortly describe in this article is the relay attack as the others are well known. The relay attack is simply a man-in-the-middle attack, that will send data skimmed from a card to a reader by using a middle attacker relay.

The document also states two other vulnerabilites, which could be applied to various types of devices actually: cryptanalytic attacks and man-in-the-middle attacks (see Cyber-Espionage : The Triggerfish for an example of cell phone man-in-the-middle attack).

The paper also goes on with various use-case scenarios of these attacks for your reading pleasure.

See also:

Security Issues of Authentication Using Mobile Devices”, Ingo Naumann, Giles Hogben, November 21, 2008, http://www.enisa.europa.eu/doc/pdf/deliverables/enisa_pp_mobile_eid.pdf (accessed on December 3, 2008)

PocketPC Security Research“, Collin Mulliner, July 9, 2007, http://mulliner.org/pocketpc/ (accessed on December 3, 2008)

Optical Fault Induction Attacks“, Sergei P. Skorobogatov, Ross J. Anderson, University of Cambridge, http://www.cl.cam.ac.uk/~sps32/ches02-optofault.pdf (accessed on December 3, 2008)

Add to FacebookAdd to NewsvineAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to Ma.gnoliaAdd to TechnoratiAdd to Furl


[1] “IPhone Flaw Lets Hackers Take Over, Security Firm Says”, John Schwartz, The New York Times, July 23, 2007, http://www.nytimes.com/2007/07/23/technology/23iphone.html?_r=1 (accessed on December 3, 12)

[2] “Exploiting the iPhone”, Independent Security Evaluators, 2007, http://securityevaluators.com/content/case-studies/iphone/ (accessed on December 3, 2008)

[3] “Fortinet: Symbian OS worm spreading in mobile networks”, Jack Rogers, SC Magazine, January 23. 2008, http://www.scmagazineus.com/Fortinet-Symbian-OS-worm-spreading-in-mobile-networks/article/104452/ (accessed on December 3, 2008)

[4] “Vulnerability patched in Google’s Android-powered phone”, Angela Moscaritolo, November 03, 2008, http://www.scmagazineus.com/Vulnerability-patched-in-Googles-Android-powered-phone/article/120322/ (accessed on December 3, 2008)

[5] “How to Exploit A Windows Mobile Handset”, Sergiu Gatlan, January 4, 2007, http://news.softpedia.com/news/How-to-Exploit-A-Windows-Mobile-Handset-43621.shtml (accessed on December 3, 2008)

[6] “Security Issues of Authentication Using Mobile Devices”, Ingo Naumann, Giles Hogben, November 21, 2008, p.10

[7] “Smart Card Security from a Programming Language and Static Analysis Perspective”, Xavier Leroy, INRIA Rocquencourt, Trusted Logic, 2003, http://pauillac.inria.fr/~xleroy/talks/language-security-etaps03.pdf (accessed on December 3, 2008)

[8] “Security Issues of Authentication Using Mobile Devices”, Ingo Naumann, Giles Hogben, November 21, 2008, p.10

[9] “Power Attacks Resistance of Cryptographic S-boxes with added Error Detection Circuits”, Francesco Regazzoni, Thomas Eisenbarth, Johann Großschädl, Luca Breveglieri, Paolo Ienne, Israel Koren, Christof Paar, University of Lugano, 2007, http://www.crypto.rub.de/imperia/md/content/texte/publications/conferences/dftsrome2007cameraready.pdf (accessed on December 3, 2008)

[10] “Oyster card hack published, released at security conference”, Nicholas Deleon, CrunchGear, October 7, 2008, http://www.crunchgear.com/2008/10/07/oyster-card-hack-published-released-at-security-conference/ (accessed on December 3, 2008)

[11] “Dismantling MIFARE Classic”, Flavio D. Garcia, Gerhard de Koning Gans, Ruben Muijrers,Peter van Rossum, Roel Verdult, Ronny Wichers Schreur, Bart Jacobs, Radboud University Nijmegen, 2008, http://www.sos.cs.ru.nl/applications/rfid/2008-esorics.pdf (accessed on December 3, 2008)