What Does an Exposed Serial Interface Mean?

Whether you have the ability to directly interface with the embedded operating system (OS) using an exposed serial console or the ability to intercept, view, tamper with, or generate data on any of these intra-chip conversation paths, the effect is the same: more attack surface. As you read in Chapter 5, the size of a target's attack surface is directly proportional to how much it interfaces with other systems, code, devices, users, and even its own hardware. Being aware of these interfaces broadens your understanding of the attack surface of a whole host of devices, and not just those running Android.

Exposed UART on Android and Linux

It is common in embedded Android-based systems to find exposed UART serial ports that (when properly connected) will allow console access directly to the underlying operating system. As discussed throughout this book, the common way to interface with Android is via Android Debug Bridge (ADB). However, it is quite common for Android-based embedded systems (that have exposed UART) to have been compiled with these kernel compile-time options:

CONFIG_SERIAL_MSM
CONFIG_SERIAL_MSM_CONSOLE

Then generally the boot loader, such as uBoot and X-Loader, will pass the kernel the serial port configuration options via a boot-time option such as the following:

"console=ttyMSM2,115200n8"

In this case, all “stdout,” “stderr,” and “debug” prints are routed to the serial console. If the device is running Android or standard Linux and login is in the boot sequence, a login prompt also generally appears here.

With these interfaces, you can generally watch the device boot, print debug, and diagnostic messages (think syslog or dmesg), or you can even interactively interface with the device via a command shell. Figure 13.2 shows the UART pins of a set-top box.

When connected to the appropriate pins on the circuit board, the few leads shown in Figure 13.2 could be used to access a root shell on the embedded Android operating system. The exact same technique, when applied to a popular Broadcom-based cable modem, revealed a customized Real-time operating system. Although there was no interactive shell on the UART of the Broadcom, when services on the device's Internet Protocol (IP) address were fuzzed, stack tracks displayed on the UART, which ultimately informed the exploitation process. The UART pins for this device are pictured in Figure 13.3.

These are just two simple examples from our own research. This same vulnerability, an unprotected UART, has been found on many more devices privately. The Internet is rife with blog posts and information security presentations based entirely on exposed UARTs, such as femtocell hacking, OpenWRT Linksys hacks, cable modem vulnerabilities, and satellite dish hacks.

So how do you go about finding these hardware interfaces? How might you discover which pins do what? You will learn some simple techniques and tools for how to do this in the “Finding Debug Interfaces” section later in this chapter. First, though, you should have some background on the other types of interfaces you might also encounter so you can differentiate between them.

The JTAG Myth

Perhaps the greatest misconception about JTAG is that it is highly standardized with regard to software debugging. The standard defines a bidirectional communication path for debugging and management. In this case, the word “debugging” does not have the same meaning as software people are familiar with: watching a program execute. Instead it was initially more focused on “debugging” in the electrical engineering context: knowing if all the chips are present, checking the state of pins on various chips, and even providing basic logic analyzer functionality. Embedded in the lower-level electrical engineering debug functionality is the ability to support higher-level software debugging functionality. What follows is an explanation as to why this is.

In reality, JTAG is a more general term to describe a feature of a chip, IC, or microprocessor. With regard to firmware and software debugging, it is similar to referring to the transmission of a vehicle. The high-level concept is fairly easy to understand. The transmission changes the gears of the car. However, the intricacies of how a car's transmission is constructed changes with each car manufacturer, which in turn matters immensely when servicing it, dismantling it, and interfacing with it for diagnostics.

As a standard, JTAG sets forth guidelines for these lower-level features and functionality as a priority but does not specify how software debugging protocol data should be formed. From a software perspective, many JTAG on-chip debugger (OCD) implementations do tend to work alike and provide a consistently minimal amount of functionality. Single stepping, breakpoints, power resets, watch-points, register viewing, and boundary scanning are among the core functionality provided by most JTAG implementations. Also, the labels that denote the JTAG pins in a device (for the most part) use the same notation and abbreviations. So even from a functional standpoint it is easy to misunderstand what exactly JTAG is.

The JTAG standard defines five standard pins for communication, which you may or may not see labeled on the silkscreen of a PCB or in the specifications for chips and devices:

• TDO: Test Data Out
• TDI: Test Data In
• TMS: Test Mode Select
• TCK: Test Clock
• TRST: Test Reset

Figure 13.6 shows several standard JTAG headers that are used in various devices.

The pin names are basically self-documenting. A software person may immediately assume that JTAG, as a standard, defines not only the pins but also the communication that happens across those pins. This is not so. With regard to software/firmware debugging, the JTAG standard simply defines that two pins be used for data transmission:

• TDO: Test Data Out
• TDI: Test Data In

It then goes on to define some commands and the format of commands that should be transmitted over those pins (for broader JTAG functionality) but does not specify what kind of serial protocol should be used for that data. JTAG also specifies different modes for any device connected to the JTAG bus:

• BYPASS: Just pass data coming in on TDI to TDO
• EXTEST (External test): Receive command from TDI, get external pin state information, and transmit on TDO
• INTEST (Internal test): Get internal state information and transmit on TDO; also do “other” user-definable internal things

For all software/firmware debugging communication that happens across the data pins of a JTAG interface, it is up to the vendor to implement in the user-definable INTEST mode of JTAG communication. And indeed that's where all the software debugging stuff that we, as reverse engineers and vulnerability researchers, care about is contained. All software and firmware debugging information is transmitted between a chip and a debugger and is done so independent of the JTAG specification by making use of the “user definable” INTEST portion of JTAG specification.

Another common misconception is that JTAG is a direct connection to a single processor or that it is specifically for the debugging of a single target. In fact, JTAG grew out of something called boundary scanning; which is a way to string together chips on a PCB to perform lower-level diagnostics, such as checking pin states (EXTEST mentioned earlier), measuring voltages, and even analyzing logic. So JTAG is fundamentally meant to connect to more than just a single chip. Figure 13.7 shows how several chips could be connected together to form a JTAG bus.

As such, the JTAG specification has one master and a number of slaves. Therefore it allows for daisy chaining multiple processors in no particular order. The master is often the debugger hardware (such as your PC and JTAG debugger adapter) or diagnostic hardware. All the chips on the PCB are generally slaves. This daisy-chaining is an important thing to note for reverse engineers because often a JTAG header on a commercial product will connect you to the core processor as well as to peripheral controllers, such as Bluetooth, Ethernet, and serial devices. Understanding this simple fact saves time and frustration when configuring debugger tools and wading through debugger documentation.

The JTAG specification sets no requirement for device order. Understanding the fact that slaves never initiate communications makes using and examining JTAG devices much easier. For example, you can assume with certainty that your debugger will be the only “master” in the chain. Figure 13.8 shows an example of how communications paths would look with a master connected.

Hopefully you now see that JTAG was predominantly for electrical engineering debugging. As software developers, reverse engineers, and vulnerability researchers, what we care about is debugging the software or firmware on a device. To that end, the JTAG specification loosely designates pins and labeling for use in software/firmware debugging. That data is transmitted with serial protocols!

The JTAG specification does not specify which serial protocol is to be used or the format of the debugging data transmitted. How could it if JTAG is to be implemented on virtually any kind of processor? This fact is at the heart of the implementation differences and indeed the core misconception about JTAG in developer communities.

Each JTAG implementation for firmware and software debugging can use different data formats and be different even down to how it is wired. As an example, Spy-Bi-Wire serial communication is the transport used in the JTAG implementation for Texas Instrument's MSP430 series of microprocessors. It uses only two wires where the traditional JTAG implementation might use four or five lines. Even though a header on a MSP430 target may be referred to as JTAG or have JTAG labels on the silkscreen of the PCB, the serial pins of the JTAG connection use Spy-Bi-Wire. Therefore a hardware debugger needs to understand this pin configuration and serial protocol to pass the data to a software debugger. (See Figure 13.9.)

In Figure 13.9, you can see the traditional 14-pin JTAG header on the left, of which only two lines are used for data by the Spy-By-Wire MSP430 processor on the right (RST/NMI/SBWTDIO and TEST/SBWTCK). In addition to the physical wiring being different, sometimes the actual wire-line protocol (the debugger data flowing across the TDO and TDI pins inside the INTEST user-defined sections) can be different. Consequently, the debugger software that speaks to the target must also be different. This gave rise to a number of different custom debugging cables, debugging hardware, and debugger software for each individual device!

But don't be intimidated! We only explain this as background information. We offer it to you to help avoid the inevitable disappointment that would come when sitting down to try JTAG with the incorrect assumption that JTAG is a highly standardized and universal debugging silver bullet. You need an understanding of JTAG so that you know what tools to get and why.

JTAG Babel Fish

Fortunately, there are a handful of companies that recognized the need for a Babel fish (a universal translator) to help make sense of all the different JTAG implementations. Vendors like Segger, Lauterbach, and IAR have created PC-based software and flexible hardware devices that do all the magic translation so that you can use their single devices to talk to different JTAG-enabled hardware devices.

JTAG Adapters

These universal JTAG debuggers are very much like universal television remotes. The vendors that create these debuggers publish long supported device lists that catalog hundreds or thousands of IC/microprocessor serial numbers that a given JTAG debugger is known to reliably support. Also much like television universal remotes; the more features, programmability, and supported devices a debugger can support, the higher the cost. This is an important thing to keep in mind if you are purchasing for a specific project. Be sure that your target is supported by the JTAG debugger you are purchasing.

Perhaps the most popular JTAG debugger, and the one most readers will find more than adequate, is the Segger J-Link, shown in Figure 13.10. The relatively low cost and extremely long list of supported devices makes it the go-to JTAG debugger for developers. There are different models of J-Link, varying in feature sets, but the core universal debugger functionality is common to them all.

To begin debugging, you simply plug the J-Link hardware into your computer via USB and then attach the J-Link box to your target chip via a ribbon cable or jumpers that you wire yourself (which is covered in the “Finding JTAG Pinouts” section later in this chapter). The Segger software then speaks to the J-Link device giving you control of the hardware device. The J-Link software will even act as a GNU Debugger (GDB) server so that you can debug a chip from a more familiar GDB console! Figure 13.11 shows GDB attached to the Segger J-Link's debugger server.

Although the J-Link is the most popular debugger, there are more industrial debuggers, like those made by Lauterbach, that are highly advanced and boast the most device support. Lauterbach's debuggers are pretty astounding but they are also prohibitively expensive.

[s7ephen@xip ˜]$ openocd
Open On-Chip Debugger 0.5.0-dev-00141-g33e5dd1 (2010-04-02-11:14)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.berlios.de/doc/doxygen/bugs.html
RCLK - adaptive
Warn : omap3530.dsp: huge IR length 38
RCLK - adaptive
trst_only separate trst_push_pull
Info : RCLK (adaptive clock speed) not supported - fallback to 1000 kHz
Info : JTAG tap: omap3530.jrc tap/device found: 0x0b7ae02f (mfg: 0x017,
part: 0xb7ae, ver: 0x0)
Info : JTAG tap: omap3530.dap enabled
Info : omap3530.cpu: hardware has 6 breakpoints, 2 watchpoints

[s7ephen@xip ˜]$ telnet localhost 4444
Trying 127.0.0.1…
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
>

> help
bp                        list or set breakpoint [<address> <length> [hw]]
cpu                       <name> - prints out target options and a comment
                          on CPU which matches name
debug_level               adjust debug level <0-3>
drscan                    execute DR scan <device> <num_bits> <value>
                          <num_bits1> <value2> …
dump_image                dump_image <file> <address> <size>
exit                      exit telnet session
fast                      fast <enable/disable> - place at beginning of
                          config files. Sets defaults to fast and dangerous.
fast_load                 loads active fast load image to current target -
                          mainly for profiling purposes
fast_load_image           same args as load_image, image stored in memory -
                          mainly for profiling purposes
find                      <file> - print full path to file according to
                          OpenOCD search rules
flush_count               returns number of times the JTAG queue has been
                          flushed
ft2232_device_desc        the USB device description of the FTDI FT2232
                          device
ft2232_latency            set the FT2232 latency timer to a new value
ft2232_layout             the layout of the FT2232 GPIO signals used to
                          control output-enables and reset signals
ft2232_serial             the serial number of the FTDI FT2232 device
ft2232_vid_pid            the vendor ID and product ID of the FTDI FT2232
                          device
gdb_breakpoint_override   hard/soft/disable - force breakpoint type for gdb
                          'break' commands.
gdb_detach                resume/reset/halt/nothing - specify behavior when
                          GDB detaches from the target
gdb_flash_program         enable or disable flash program
gdb_memory_map            enable or disable memory map
gdb_port                  daemon configuration command gdb_port
gdb_report_data_abort     enable or disable reporting data aborts
halt                      halt target
help                      Tcl implementation of help command
init                      initializes target and servers - nop on subsequent
                          invocations
interface                 try to configure interface
interface_list            list all built-in interfaces
irscan                    execute IR scan <device> <instr> [dev2] [instr2]   

Evaluation Kits

Evaluation kits are the standard way that engineers and designers find the right products for their systems. Virtually every commercial processor and controller will have an evaluation kit created by the manufacturer. They are often very low cost, ranging from free to $300 (many are about $100). In general, it behooves manufacturers to make evaluation kits cheap and accessible for people that might be developing products that use their processors.

Some manufacturers even go so far so to provide reference designs that bundle the Gerber files (the 3D model and wiring specifications) of the evaluation kits themselves along with the Bill Of Materials (BOMs) so that embedded engineers can quickly manufacture their own products without building a whole PCB around the processor from scratch. In this way, evaluation kits can also be immensely useful to reverse engineers and vulnerability researchers. Figure 13.12 shows the STMicro ARM development kit.

The primary way that these evaluation kits are useful to reverse engineers is with regard to debuggers. The evaluation boards contain all that is needed for a developer to debug, program, and interface with a processor. They may also provide any specifications about security features of the processor that might've been employed by the manufacturer to protect the product.

You can use the evaluation kits as a control environment to test your debugging setup with software like OpenOCD. By building this kind of control environment you can test your debugger setup under ideal conditions to eliminate some of the independent variables discussed earlier. Having eliminated those, you can be confident that your debugger setup should work if your wiring is correct (to the target) and the device has JTAG enabled.

Finally Connected

After you have a debugger device connected to your target chip, either by a programming header or hand-wired connections, the debugger software notifies you that the debugger device is successfully connected to the target. In the case of the Segger J-Link, you can begin using GDB against the target immediately as shown in Figure 13.13.

Enter the Logic Analyzer

Perhaps the most useful tool for determining what a pin is used for is a logic analyzer. These devices have a rather intimidating name, especially for software people, but in reality they are very simple. These devices just show you what is happening on a pin. You connect a probe from the device and if there is data being transmitted on a pin it shows you the square wave of that data and even attempts to decode it for you using a number of different filters.

Traditional logic analyzers were a bit more complex, but new generations of them connect to computer-based applications that eliminate the esoteric nature of these devices. These kinds of logic analyzers themselves have no user interface on the device itself and instead are controlled entirely by user-friendly and intuitive computer-based applications. One such device is the Saleae Logic Analyzer, shown in Figure 13.14.

Using the Saleae, you can connect the color-coded electrodes to pins on your target device, which enables using the software application (that receives data from the Saleae via USB) to capture activity. The results are displayed in the interface corresponding to the color of the pins of the electrodes, as shown in Figure 13.15.

As if this was not useful enough for the layperson, Saleae included a bunch of other useful functionality in the application. For example, filters attempt to decode a captured data stream as a bunch of different types such as I²C, SPI, and asynchronous serial (UART) at varying baud rates. It will even attempt to identify baud rates automatically. Figure 13.16 shows the filters commonly supported by the Saleae software.

These filters act much like Wireshark's protocol dissectors, allowing you to quickly view the captured data as if it were being parsed as different formats. The Saleae interface even overlays the byte encoding on the square wave form in the interface, as shown in Figure 13.17.

From this, you can generally immediately identify a UART signal (if not by the filters then by eye) as most UART connections are used for transmission of ASCII text.

Lastly, Saleae exports this decoded data as a binary file (for you to parse yourself) or as a comma-separated value (CSV) file with some metadata included (such as timing, pin number, etc.). This is very useful for further analysis or logging purposes.

Finding UART Pinouts

Finding UART pinouts is crucial, as UART is often used as a means to transmit debug output or to provide shells or other interactive consoles to a developer. Many production-grade products go to market not only with these interfaces active, but with the pins overtly exposed. In 2010 and 2011, Stephen A. Ridley and Rajendra Umadras demonstrated this fact in a series of talks in which they discussed a specific brand of cable modem being distributed by the home Internet service providers in the New York City metropolitan area. This series of home cable modems used a Broadcom BCM3349 series chip (specifically the BCM3349KPB) for which the four UART pins were exposed on the PCB in the small four-pin header shown in Figure 13.18.

In this case, there was little knowledge about what the pins on that header were or what they were responsible for. As a precautionary measure, a voltmeter was first connected to those pins as shown in Figure 13.19.

This was done to be sure that they didn't carry a voltage that would burn the analysis equipment. Additionally, the pin that carried no voltage would likely be the ground pin.

The presence of 3.3 volts, as shown in Figure 13.19, generally (but not always) implies that the target pin is used for data as most supply voltages (or lines used exclusively to power devices and not transmit data) are around 5 volts. This was a first indication that these pins might have serial data.

Next, the Saleae was connected to each pin, with each electrode connected to the pin in question. In the Saleae user interface, the color of each graph area corresponds directly to the color of each electrode on the physical device, which makes referencing it very simple. Recording data from the Saleae was started while power cycling the cable modem. The prevailing assumption was that the cable modem would likely output data during its boot sequence as the device powered on. After several recordings of boot sequences, the square waves shown in Figure 13.20 were observed on the pins.

The regularity of the square wave on Input 3 (which was red) indicated that the pin that the red electrode was connected to was likely a clock pin. Clock pin signals generally accompany data signals. They are the metronome to which the sheet music of data is played. They are important for the recipient to know the timing of the data it is receiving. The regularity of that square wave and subsequent irregularity of the adjacent input (Input 4) indicate that both a clock and data pin have both been observed simultaneously.

Using the Saleae functionality further, this hypothesis was tested by running the captured square waves through some of the built-in filters or analyzers.

After this Analyzer has run, it overlays the suspected byte values for each corresponding section of the square wave, depicted in Figure 13.21. It will also display the suspected baud rate.

This data was output to the computer's file system as CSV data and then cleansed using a simple python script like the following:

#!/usr/bin/env python
import csv
reader = csv.reader(open("BCM3349_capture.csv", "rb"))
thang = ""
for row in reader:
    thang = thang+row[1]
thang = thang.replace("\r", "x0d")
thang = thang.replace("\n", "x0a") #clean up Windows CR/LF
thang = thang.replace("''","") #Cleanse Saleae CSV output quotes
#print thang
import pdb;pdb.set_trace() # drop into an "in scope" Python interpreter 

Executing this Python script enables you to view the CSV data and manipulate it interactively from a familiar Python shell. Printing the variable thang yielded the output shown in Figure 13.22.

As you can see, the data captured across those overt pins is in fact boot messages from the device. The device goes on to boot a real-time operating system called eCos. The researchers that presented this technique went on to explain that the cable modem was also running an embedded webserver that they fuzzed. Stack-traces of the crashes caused by fuzzing were printed on the UART serial port shown in Figure 13.23. This information assisted in exploitation of the device.

Finding SPI and I²C Pinouts

The process of finding SPI and I²C devices is similar to that of finding UART. However, SPI and I²C are generally used locally on the PCB to pass data between chips. As such, their functionality and usability can make them a bit different to identify. However, they will occasionally leave the PCB and be used for peripherals (often proprietary). The canonical example of this is the Nintendo Wii controllers and other game consoles that often use SPI as a way to connect to the main game console for wired connections. The pinout for this connector is shown in Figure 13.24.

The data transmitted on these SPI pins varies based on how the manufacturer of the device (or controller) chooses to format it. In this way, the data across an I²C or SPI bus is specific to whatever you are attempting to target. Read more on how to spy on these busses in the following sections.

Finding JTAG Pinouts

Finding JTAG pinouts can be daunting. As described in great detail earlier, the pinouts for JTAG Serial Wire Debugging (SWD) depend on the manufacturer of the target device. Looking at standard JTAG headers, like those used in development kits and evaluation kits, it is clear that there can be many pin configurations. Figure 13.25 shows the most common headers.

If there are so many possibilities in controlled environments like these, then what can you expect from devices in the wild?

Thankfully, as mentioned earlier, the reality is that for JTAG SWD there are only a few pins that are actually needed to perform basic debugger functionality. Again, those pins are the following:

• TDO: Test Data Out
• TDI: Test Data In
• TMS: Test Mode Select
• TCK: Test Clock
• TRST: Test Reset

In reality, even TRST is optional as it's only used to reset the target device.

When approaching a new device, figuring out which pins from a block of unlabeled pinouts is merely a guessing game. There are some heuristics reverse engineers could apply to find pins like the clock pin. A regular square wave, like those we discussed in the section “Finding UART Pinouts,” would reveal that this was TCK. However, this process can be very time consuming to perform manually, taking days, if not weeks, depending on the target. This is due to the need to try such a large number of possible combinations.

Recently, however, hacker/reverse engineer/developer Joe Grand created an open source hardware device called the JTAGulator. It allows a reverse engineer to easily iterate through all possible pinouts and thusly brute-force JTAG pinouts blindly! The schematics, bill of materials (BOM), and firmware required for creating your own device are completely open and downloadable from Joe Grand's website at www.grandideastudio.com/portfolio/jtagulator. Further, you can purchase fully assembled and operational units, such as the JTAGulator shown in Figure 13.26 from the Parallax website at www.parallax.com/product/32115.

With the JTAGulator, you first connect all the questionable pins to screw-down terminals or headers on the JTAGulator. Make sure that at least one pin from the target's ground plane connects the ground (GND) on the JTAGulator. The JTAGulator is USB bus powered. Connecting to the device is simple using a standard terminal program like PuTTY, GNU Screen, or Minicom.

[s7ephen@xip ˜]$ ls /dev/*serial*
/dev/cu.usbserial-A901KKFM    /dev/tty.usbserial-A901KKFM
 [s7ephen@xip ˜]$ screen /dev/tty.usbserial-A901KKFM 115200

When connected to the device, you are greeted with a friendly interactive CLI that displays the creator and firmware version:

JTAGulator 1.1
Designed by Joe Grand [[email protected]]
: :
?
:
JTAG Commands:
I   Identify JTAG pinout (IDCODE Scan)
B   Identify JTAG pinout (BYPASS Scan)
D   Get Device ID(s)
T   Test BYPASS (TDI to TDO)
UART Commands:
U   Identify UART pinout
P   UART pass through
General Commands:
V   Set target system voltage (1.2V to 3.3V)
R   Read all channels (input)
W   Write all channels (output)
H   Print available commands
:

Press the H key to display interactive help.

Joe Grand has posted videos and documentation on the web in which he uses the JTAGulator to brute force the JTAG pinouts of a Blackberry 7290 cellular phone. Still, any device with JTAG pins can be targeted with the JTAGulator. For demonstrative purposes, we chose an Android-based HTC Dream and a Luminary Micro LM3S8962 ARM Evaluation Board. To interface with the (very difficult to reach) JTAG pins of an HTC Dream we purchased a special adapter from Multi-COM, a Polish company that makes debug cables, adapters, and other low-level devices for mobile phones. After all your suspected pins are connected from the target to the JTAGulator, you select a target voltage, which is the voltage that the device uses for operating the JTAG pins. You can either guess the voltage or find it in the specifications of your target processor. The standard for most chips is to operate at 3.3 volts. The V command enables you to set this parameter:

Current target voltage: Undefined
Enter new target voltage (1.2 - 3.3, 0 for off): 3.3
                                                 New target voltage set!
:

When that is done, it is quickest to begin with an IDCODE scan because it takes less time to perform than a BYPASS (Boundary Check) scan. IDCODE scans are written into the JTAG SWD standard as a means for a JTAG slave (in this case the target device/processor) to quickly identify itself to a JTAG master (in this case our JTAGulator).

The JTAGulator quickly iterates through the possible pin combinations initiating this rudimentary communication. If the JTAGulator gets a response, it records what pin configurations yielded a response from the device. Consequently, it is able to determine which pins provide which JTAG functions.

To perform this against an HTC Dream, initiate an IDCODE scan using the I command. Tell the JTAGulator which of its pins we connected with suspected JTAG pins:

Enter number of channels to use (3 - 24): 19
Ensure connections are on CH19..CH0.
Possible permutations: 6840
Press spacebar to begin (any other key to abort)…
JTAGulating! Press any key to abort…
TDI: N/A
TDO: 4
TCK: 7
TMS: 5
IDCODE scan complete!
:

The JTAGulator then displays all the possible combinations of pinouts it will try and initiates brute forcing at your command. Almost instantly it gets responses, identifying which pin configurations yielded IDCODE scan responses. You can now connect these corresponding pins into your J-Link or other JTAG debugger and begin debugging the target device!

Connecting to Custom UARTs

Many cell phones, including Android devices, expose some form of UART through the use of a nonstandard cable. These cables are often called jigs. The name comes from metalworking and woodworking, where it means a custom tool crafted to help complete a task. You can find more information on jigs for Samsung devices, including the Galaxy Nexus, in the XDA-Developers forum at http://forum.xda-developers.com/showthread.php?t=1402286. More information on building a UART cable for the Nexus 4 which uses the device's headphone jack, is at http://blog.accuvantlabs.com/blog/jdryan/building-nexus-4-uart-debug-cable. Using these custom cables enables access to UART, which can also be used to achieve interactive kernel debugging as shown in Chapter 10.

Package on Package

One common obfuscation technique is something referred to in the industry as Package on Package (PoP) configurations. These are generally used by manufacturers to sandwich components together to save real-estate space on the PCB. Instead of positioning a component adjacent to a processor on the PCB and running interface lines to it, the manufacturers instead build vertically and put the component on top of the CPU. They then sell it as a package that can be purchased in different configurations by the device manufacturer. Figure 13.29 illustrates one potential PoP configuration.

This practice is most commonly used (in our experience) with microprocessors and memory. Instead of putting a bank of flash memory horizontally adjacent to a CPU, some manufacturers use a PoP configuration. In this case, the only visible serial number is that of the memory atop the processor. In these cases, doing an Internet search for that serial number does not yield the specifications for what you'd expect (the microprocessor).

The solution to this can depend on the device. Sometimes the manufacturer of the visible device is the same as the manufacturer for the device underneath it. Sometimes a specification sheet for the top device yields a number of compatible devices that could be packaged with it. There is no one solution in this case, and it takes some sleuthing to find the name of the hidden device. In some cases, you can find third-party information — such as details about tear-downs performed by other technology enthusiasts — that can yield information for common consumer devices.

Sniffing USB

There are a number of devices available on the market that you can use as USB debuggers or protocol analyzers. Perhaps the best of them all are those made by Total Phase. Total Phase manufactures a number of wire-line protocol analyzers, including ones for SPI, CAN, I²C, and more. While we will discuss these later, Total Phase's USB analyzers are the best on the market. Total Phase makes several USB protocol analyzers at several different price points. All their devices (including the non-USB analyzers) use a common software suite called Total Phase Data Center. Each device varies in price and capabilities, with the main differences in capability being the speed of the USB bus that it can analyze. The more expensive devices can do fully passive monitoring of USB SuperSpeed 3.0 devices; the middle-tier devices can monitor USB 2.0; and the least expensive devices are only capable of monitoring USB 1.0.

At a high-level, the USB specification makes a distinction between things as either USB hosts or devices. This distinction is made within the USB controllers. USB hosts generally consist of larger devices such as desktop computers and laptops. USB devices are generally smaller devices — thumb drives, external hard-drives, or mobile phones, for example. The difference between hosts and devices becomes increasingly relevant in later sections. The Total Phase analyzers sit in-line between the USB host and USB device to passively spy on the communication between the two.

The Total Phase Data Center application controls the Total Phase analyzer hardware via a USB cable. The user interface for the Data Center application is presented in Figure 13.30.

This application is functionally equivalent to the well-known open source Wireshark network monitoring tool, but it's for USB. It enables you to record and view the protocol conversation, as well as dissect it and analyze it in a number of ways. Total Phase also exports an application programming interface (API) that enables you to interact directly with their devices or software to perform captures, receive callbacks/triggers, and passively parse or manipulate data from the bus.

In addition to the power of all this, Data Center also includes many other features, such as the ability to add comments in the data stream, online help for references to USB protocol lingo, and amazingly useful visualization tools for tracking and analyzing USB data as it flies across the bus. One such tool is Block View, which enables you to view protocol data visualized in the protocol packet hierarchy of the USB protocol. Block View is shown in Figure 13.31.

For passively monitoring data on a USB bus, Total Phase takes the cake. It does virtually everything you could want to do with data you observe for any protocol. However, when the time comes that you need to actively interface with USB devices, the Total Phase tools are simply not designed to do that. They do not do traffic replay or packet injection of any kind.

Depending on your target, you can go about this in several ways. The main way you choose to go about actively replaying or interfacing with USB devices at a low-level USB protocol level depends on your target and desired goal. All of these differences are rooted in whether you want to interface with the target as a USB host or a USB device. There are different ways to go about both.

Interfacing with USB Devices as a USB Host

Perhaps the easiest way to go about interfacing with a target is as a USB host. If your target designates itself as a USB device (which can be observed with passive monitoring using a tool like the Total Phase) then you can use libusb to write custom code to speak to the device.

libusb is an open source library that gives the developer access to the USB-level protocol communications as a USB host. Instead of opening a raw USB device (via the /dev file system, for example), libusb provides wrappers for basic USB communication. There are a number of bindings for libusb for common languages like Python and Ruby with varying levels of support across several different versions of libusb.

There are quite a few examples available on the Internet of people using PyUSB or high-level languages to communicate with devices such as the Xbox Kinect, human interface devices (or HIDs, such as keyboards and mice), and more. Should you choose to go that route, libusb is popular enough that you can generally search for and find answers to simple questions.

Interfacing with USB Hosts as a USB Device

In contrast to interfacing with USB devices, interfacing with USB hosts as a device is a much more complex issue. Because USB controllers declare themselves as either devices or hosts, you cannot easily tell the USB controller in your laptop or desktop computer to simply pretend to be a USB device. Instead, you need some form of intermediary hardware. For many years, devices that performed this function were virtually nonexistent. Then, several years ago, Travis Goodspeed unveiled an open source hardware device he called the Facedancer. The PCB layout of version 2.0 of the Facedancer appears in Figure 13.32. This device uses special firmware for the embedded MSP430 processor to accept data from a USB host and proxy it to another USB host as a device.

Unfortunately, version 2.0 of Facedancer had some simple circuit errors that were corrected by Ryan M. Speers. Travis Goodspeed has since deprecated the Facedancer20 design and with Speer's fixes released the Facedancer21.

The Facedancer device is fully open source and the code repository for the device includes Python libraries that speak directly to the hardware via USB. Developers can then use those Python libraries to write programs that speak to other USB hosts (via the Facedancer) as if they were USB devices.

The Facedancer code includes several examples out of the box. One such example is an HID (keyboard) that when plugged into a victim's computer will type messages to the victim's screen as if she were using a USB keyboard. Another example is a mass storage emulation, which allows a developer to mount (albeit slowly) a disk image (or any file) from the controlling computer onto a victim's computer as if it were a USB flash drive.

The Facedancer started off as an electronics hobbyist project. Travis Goodspeed had fabricated the PCB, but because assembly is a very expensive task to perform in bulk, it was up to the purchaser to acquire all the parts and solder it together. However, at the time of publishing, the INT3.CC website at http://int3.cc/ sells fully assembled Facedancer21 units.

There are other devices that have since released that assist with low-level USB development in the same way as the Facedancer. One such device is called SuperMUTT. It was created out of collaboration between VIALabs and Microsoft. The device is intended to work with the Microsoft USB Test Tool (MUTT, hence the name of the device). It claims to be able to simulate any device traffic on the bus, and is apparently the preferred tool of USB developers.

Whichever device you choose, it is now possible to programmatically simulate a USB device where previously it required obscure hardware tools or custom hardware development.

Sniffing I²C, SPI, and UART

Earlier, when detailing how to find UART pinouts, we introduced the use of a logic analyzer to record traffic on the bus. We mentioned that tools like the Saleae have software filters that can be used to intelligently guess what serial protocol is being observed. In the earlier example, a UART analyzer was used to find and decode the data output by mysterious pins exposed inside a Broadcom cable modem.

The Saleae performs analysis for I²C and SPI serial communications in much the same way. However, there are other tools that can be used to observe traffic specifically on I²C and SPI ports.

Total Phase makes a relatively low cost USB-controlled device called the Beagle I²C that can observe and analyze I²C and SPI data. The Beagle uses the Data Center application that was discussed earlier in this chapter in the “Sniffing USB” section. The Data Center interface is more suited to protocol analysis than that the interface Saleae Logic Analyzer, which simply observes square waves and guesses at protocols.

In Figure 13.33, the Total Phase Beagle was used to sniff the I²C pins of a VGA cable. Specifically, we intercepted the Extended Display Identification Data (EDID) protocol exchange that happens between a video display and a video card. In this case, the EDID data was intercepted as a monitor was plugged into a computer via a custom-made video tap, which enabled us to access all pins in a VGA cable while it was in use between a monitor and computer.

Like UART, SPI and I²C can run at various speeds, so it is important that you attempt to decode at the correct baud rate. Both the Saleae and Total Phase can guess the baud rate pretty accurately using the clock pins. However, there are some small differences to note.

I²C, unlike UART, is used to network multiple components that might live on a PCB. Much like JTAG, each I²C device declares itself as either a master or a slave. Each device connected to the I²C bus (when active) changes the voltage on the overall I²C loop because it consumes the voltage causing an overall voltage drop on the line. When all devices in the I²C chain are inactive, they act as if they are disconnected from the circuit. To keep the voltage draw on the I²C lines, I²C requires a pull-up resistor on the clock and data pins to keep the voltage up even though a component in the chain is inactive. A “pull-up” resistor does exactly that; it “pulls” the voltage up to the expected levels.

As you might imagine, connecting a probe or analysis device (such as the Beagle) to an I²C bus might also change the voltage on the line. Consequently, when connecting an analysis tool to a line, you might need a pull-up resistor to pull the voltage up to the correct level. Fortunately, many I²C analysis tools take this into consideration and internally have pull-up resistors you can enable or disable with software switches. This feature exists in the Beagle analysis tools as well as the Bus Pirate, which is covered in the next section.

Talking to I²C, SPI, and UART devices

So how might you begin to interactively or programmatically speak to I²C, SPI, and UART devices? Perhaps the lowest cost method for this is to use a device called the Bus Pirate, which is shown in Figure 13.34.

The Bus Pirate started off as a hobbyist device on the website Hack-A-Day (http://hackaday.com/), but quickly proved to be widely useful outside of the hobbyist community. It is extremely low cost, and you can buy it from a number of online retailers for around $30.

Much like the JTAGulator mentioned earlier, the Bus Pirate is a USB device that has a helpful CLI. You can access it using any terminal emulation program — such as PuTTY, Minicom, or GNU Screen — via a USB cable on a host computer. The following excerpt shows the help screen that can be accessed using the ? command:

[s7ephen@xip ˜]$ ls /dev/*serial*
/dev/cu.usbserial-A10139BG    /dev/tty.usbserial-A10139BG
 [s7ephen@xip ˜]$ screen /dev/ tty.usbserial-A10139BG 115200HiZ>
HiZ>?
General                                 Protocol interaction
---------------------------------------------------------------------------
?       This help                       (0)     List current macros
=X/|X   Converts X/reverse X            (x)     Macro x
˜       Selftest                        [       Start
#       Reset                           ]       Stop
$       Jump to bootloader              {       Start with read
&/%     Delay 1 us/ms                   }       Stop
a/A/@   AUXPIN (low/HI/READ)            "abc"   Send string
b       Set baudrate                    123
c/C     AUX assignment (aux/CS)         0x123
d/D     Measure ADC (once/CONT.)        0b110   Send value
f       Measure frequency               r       Read
g/S     Generate PWM/Servo              /       CLK hi
h       Commandhistory                         CLK lo
i       Versioninfo/statusinfo          ^       CLK tick
l/L     Bitorder (msb/LSB)              -       DAT hi
m       Change mode                     _       DAT lo
o       Set output type                 .      DAT read
p/P     Pullup resistors (off/ON)       !       Bit read
s       Script engine                   :       Repeat e.g. r:10
v       Show volts/states               .      Bits to read/write e.g. 0x55.2
w/W     PSU (off/ON)            <x>/<x= >/<0>   Usermacro x/assign x/list all
HiZ>

You can connect the Bus Pirate to the target pins of your SPI, I²C, or UART bus using a convenient bundle of probes that plug directly into the Bus Pirate, as shown in Figure 13.35.

Unlike the JTAGulator, which guesses pinouts, the Bus Pirate probes need to be connected to the target bus in specific configurations depending on what you are targeting. You can use probe-color-coded Bus Pirate cheat sheets that are widely available on the Internet to make the Bus Pirate interface with SPI, I²C, and UART devices. For these interfaces, you need to tell the Bus Pirate some details, like baud rates (see Figure 13.36), which you can intelligently guess using tools like the Saleae discussed earlier.

After it's connected, the Bus Pirate enables you to interactively or passively communicate with the target bus. Because the Bus Pirate interface is text based, it does not have an easy way to observe binary data on these busses. The Bus Pirate displays binary data by printing byte values (for example, 0x90). This is not optimal for interacting with binary data streams. In many cases, people have written their own software using libraries like PySerial to control the Bus Pirate, receive its ASCII data stream, and convert the bytes they care about back to their literal byte values.

To fill this gap, Travis Goodspeed developed the GoodFET, which acts as a Python API–controlled Bus Pirate. It is (unlike the Facedancer21) available fully assembled from a number of retailers. Using the GoodFET, you can programmatically interface with the busses you need to receive or transmit binary data outside the range of ASCII-printable characters.

Boot Loaders

After you have interactive connectivity to a device, the first thing you may encounter when the device is reset is messages from the boot loader. Many boot loaders, such as Das U-Boot or U-Boot for short, allow you a small window of time to press a key to enter an interactive boot loader menu. Figure 13.37 shows a screenshot of such a prompt in U-Boot.

This case alone can often lead to complete compromise of a device because the boot loaders often provide a plethora of functionality such as the following:

• Reading or writing to flash memory
• Booting from the network
• Upgrading or accepting new firmware via serial port
• Partitioning or manipulating flash file systems

Figure 13.38 shows the full extent of the commands provided by a typical U-Boot deployment.

Many devices with accessible UART that make use of a boot loader like U-Boot will often let you interactively drop into a session like this. If the manufacturer did not think to disable UART, generally it also leaves U-Boot exposed.

SPI EEPROM

Much like the SPI devices mentioned earlier in this chapter (accelerometers and temperature sensors, for example), SPI EEPROM makes use of SPI. Where other types of memory use custom interfaces and “address lines” to fetch and store data, SPI EEPROM uses a simple serial line to read and write data. The way these kinds of storage devices work is simple. An address is written to the SPI or I²C bus (for example, 0x90) and the EEPROM device responds with the data that is at that location. Figure 13.39 is a screenshot of the Total Phase Beagle observing a device reading and writing from an I²C EEPROM.

In the Transaction View near the top of the window you can clearly see that each Write Transaction is followed by a Read Transaction. The CPU wrote the value 0x0013 to the I²C bus, and the I²C EEPROM responded with the value at that location, 0x68. In this way, reading these types of EEPROM is trivial. You can spot these types of EEPROM simply by doing an Internet search for their serial numbers.

Should you want to do more than observe a CPU make use of this kind of EEPROM, Total Phase Data Center has additional functionality for reading data directly from SPI or I²C EEPROM automatically. Using this functionality, you can reconstruct the binary data as a file on your local file system. You could also conceivably use the Bus Pirate or GoodFET to perform the same function.

MicroSD and SD Cards for Firmware Image Storage

Some devices take firmware upgrades or store firmware images on MicroSD or SD cards. In the case where those storage devices make use of a mountable file system, it is merely a matter of unplugging and mounting the device in your analysis computer. In some cases, embedded developers write the data raw, or in their own format, to the SD cards. Remembering that MicroSD and SD cards are inherently SPI, you can apply the same technique to the one described in the preceding section for reading and writing from an SPI EEPROM.

JTAG and Debuggers

You can use a JTAG debug interface or a debugger to inherently view contents of processor registers. In addition, you can often view the contents of memory. On embedded systems, specifically those executing bare metal images, this means that you can consequently extract firmware. This is another reason that gaining JTAG debugger access to a device can be extremely advantageous. Many tools, such as the Segger J-Link, use the JTAG functionality to reconstruct the firmware image on the file system of the controlling computer. Using the GDB server functionality for the J-Link, the GDB memory dump command often works for dumping the entire contents of memory.

Removing the Chip

Perhaps the most obtrusive and destructive technique for obtaining a firmware image is to physically remove the chip from the board and read it. At first glance, this may seem like a laborious and highly skilled technique. In reality, it is not.

De-soldering a surface mounted device (SMD) and reading it can be quite easy and fun. Some people use heat guns (which are essentially hot hair dryers) to simultaneously melt all solder on the connections that bind a SMD component to a PCB. This is very effective and straightforward method.

Another technique is to use a product called Chip Quik. Kits, like the one shown in Figure 13.40, come with everything needed to apply this product.

Chip Quik is essentially composed of a metallic alloy that has a lower melting temperature than traditional solder. Applying molten Chip Quik to solid/cooled solder transfers heat to the solder and consequently melts it. Because the Chip Quik stays hotter longer, this enables you enough time to remove or de-solder chips from PCBs. Even if you are horrible at soldering, you can effectively apply Chip Quik clumsily and have great success. There are many demonstration videos on the Internet that describe the whole process.

After the target CPU or flash chip is de-soldered from the board, then what? Fortunately, a company called Xeltek has built a family of useful devices that help with the next part: reading the chip. Xeltek offers a number of devices called Universal Flash Programmers; their top-of-the-line devices are in the SuperPro line. The SuperPro devices can essentially read and write hundreds of different kinds of flash memory and processors. One such product is the Xeltek SuperPro 5000E, which is shown in Figure 13.41.

In addition, Xeltek makes hundreds of adapters that fit all the possible formats and form factors that chips may take. Figure 13.42 shows some of the adapters for the SuperPro 5000E.

The Xeltek website even has a searchable database in which you can enter a chip serial number to find out which Xeltek adapter will fit your target chip! The Xeltek device itself plugs into a computer using a USB cable and the included software is equally as simple to use. You simply start up the application, which detects the adapter type you are using and asks you if you want to read it. Click Read and a few minutes later there is a binary file on your file system of the contents of the chip! Figure 13.43 shows a screenshot of this tool in action.

It is literally that simple to rip the firmware out of chips. Priced at several thousand dollars, the Xeltek devices (like the advanced Total Phase USB tools) may be prohibitively expensive if you don't have a business need for them, but they provide an incredibly useful and simple function.

Bare Metal Images

As mentioned earlier, microcontrollers blindly execute whatever it is they are pointed at during boot. The specifications sheet for your target tells you exactly how bootstrap works within the processor (where the entry point is, initial register states, and so on). But maybe you just want to quickly know what you are looking at. Sometimes this might require walking through the file in a hex editor to glean clues about what is in the big binary blob.

In many cases, the extracted firmware image is not just the firmware. It might also include tiny file systems like CramFS, JFFS2, or Yaffs2. In cases where you extracted data from NAND flash, these binary blobs are likely to be strictly the tiny file systems. Tools like binwalk can detect these and provide a bit more information about the contents of a binary blob. binwalk uses heuristics to locate recognizable structure in files. The following excerpt shows an example of using binwalk:

[s7ephen@xip ˜]$ binwalk libc.so
/var/folders/jb/dlpdf3ns1slblcddnxs7glsc0000gn/T/tmpzP9ukC, 734:
Warning: New continuation level 2 is more than one larger than current
level 0
DECIMAL       HEX           DESCRIPTION
----------------------------------------------------------------------
0             0x0           ELF 32-bit LSB shared object, ARM,
version 1 (SYSV)
271928        0x42638       CramFS filesystem, little endian
size 4278867 hole_support CRC 0x2f74656b, edition 1886351984,
2037674597 blocks, 1919251295 files  

In this simplified example, we execute binwalk on libc.so extracted from an Android device. You can see it correctly identifies the contents of the file as an Executable and Linking Format (ELF) and what it suspects to be a tiny CramFS file system on the end.

binwalk is not a silver bullet. It often fails to identify the contents of binary files. This tends to happen more commonly on the image extracted from targets such as CPUs (specifically the CPUs embedded flash) and NAND. The following excerpt demonstrates an attempt to use binwalk on an extracted firmware image.

[s7ephen@xip ˜]$
s7s-macbook-pro:firmware_capture s7$ ls -alt Stm32_firmware.bin
-rwxrwxrwx  1 s7  staff  1048576 Mar 14  2013 Stm32_firmware.bin
[s7ephen@xip ˜]$ binwalk Stm32_firmware.bin
/var/folders/jb/dlpdf3ns1slblcddnxs7glsc0000gn/T/tmprDZue9, 734:
Warning: New continuation level 2 is more than one larger than current
level 0
DECIMAL       HEX           DESCRIPTION
----------------------------------------------------------------------
[s7ephen@xip ˜]$

In the preceding example, binwalk fails to identify anything within a one megabyte binary image extracted from an STM32 microprocessor. In these cases, unfortunately, manual review of the binary image and custom development is generally the only recourse.

Importing into IDA

If you know enough about the binary image to carve out any unnecessary bits, or if the executable binary image was obtained using other means, then importing into IDA is the next step. Importing binary images into IDA often requires some shoe-horning. Loading a binary from an embedded system into IDA is unfortunately not as straightforward as it is with ELFs, Mach-O, and Portable Executable (PE) executable images. That said, IDA does offer a lot of functionality to assist the reverse engineer with loading and parsing firmware images.

When loading a firmware image into IDA, you generally have to follow a three-step process. First, open the file with IDA and select Binary File or Dump as shown in Figure 13.44.

Next, select the target's architecture from the dialog shown in Figure 13.45. You need to know enough about the architecture of your target processor to select it (or one close to it).

Finally, you need to know enough about your target to complete the form shown in Figure 13.46. This dialog essentially informs IDA about the entry point of the binary. You can gather some of this information from the specifications sheet of your target processor.

At this point, if you are fortunate, IDA loads the binary. When used to reverse engineer PEs, ELFs, or Mach-O binaries you may have only noticed Fast Library Identification and Recognition Technology (FLIRT) when it has failed to help you (disassembling function entry or incorrectly identifying structures, for example). But with firmware reverse engineering, FLIRT really shines. You can access the FLIRT dialogs at any time by selecting the flower icon from the toolbar as shown in Figure 13.47.

Much like binwalk, FLIRT combs through the file looking for signatures that you can then apply to parts of your binary. Instead of identifying common binary file formats or file systems, FLIRT signatures aim to identify the compiler used to generate the code. If any FLIRT signatures match the firmware, the dialog shown in Figure 13.48 displays so you can select the correct signature set.

This whole process is very much imperfect, but there are use cases for it on the Internet (generally for video game ROMs and such). Anticipate spending time fiddling with IDA configurations quite a bit. Even when the binary appears to be properly loaded in IDA, you can also anticipate performing quite a few additional fix-ups in the middle of the disassembly. In the case of ARM code, additional fix-ups will likely be required because IDA will likely have difficulty identifying the function entry points or the instruction mode (ARM or THUMB). You'll simply have to perform these bits manually or make use of custom IDC or IDA Python scripts to help you out.