From Zynamics BinCrowd presentation

Bincrowd, a project I had the pleasure of contributing to, has been released by Zynamics. Bincrowd simplifies the collaborative option in reverse engineering and brings it en masse. Any function a user has ever submitted documentation for can be found quickly in your target. It also introduces greater flexibility and reliability by adding additional signature methods for functions. Further, server access and clients for various disassemblers are free (ida client here).

To fully understand how this could create an evolutionary step for software reverse engineering (RE) lets walk look at a typical RE session. You open your target in your favorite disassembler and find it
has several hundred functions. If you are lucky you will have a signature database that matches the OS version, library versions and compiler version your target was built with.  This will let you find the system calls quickly, fiddling down the undocumented code you need to RE to a hundred or so functions. Once you have reverse engineered a function that is missing a signature you could create one for it but until now it has been difficult to share this with others. With Bincrowd you can share this information quickly for team based RE efforts or just for posterity sake.  If 10 years from now someone runs into similar code somewhere else this information becomes useful. Further, Bincrowd goes further by adding more flexible signature routines to the mix. Signatures often used today are based on the raw bytes of a compiled function. The added signatures in Bincrowd are based on the flow of the function instead. The flexibility this introduces means you might find details and signatures for functions that were compiled with a different version compiler, different version of libraries, different compiler and libraries entirely, different hardware architectures or even different OS’s. Research from Zynamics has been the ground breaking in this field.

My efforts on Bincrowd were supported by Recurity-Labs. Both Recurity-Labs and Zynamics are great companies to work with.

JTAGenum is an open source Arduino based hardware platform I built last year with three primary goals: [1. Given a large set of pins on a device determine which are JTAG lines 2. Enumerate the Instruction Register to find undocumented functionality 3. be easy to build and apply] The development of a device has various distinct stages handled by different people/companies that each assume the other has properly secured their part. The security of devices often rely on obfuscation which makes it dificult for any part of the chain to evaluate the security of the whole. This is a problem that JTAGenum helps address. This was built for personal research and while working on various projects at Recurity Labs. Please feel free to contact me with any questions, problems, targets or updates. I would be more than happy to share credit.

Related work: There are two other tools for finding JTAG pins: JTAGScan presented by Benedikt Heinz (hunz) at ph-neutral which inspired Arduinull by Sébastien Bourdeauducq (lekernel). JTAGenum is most similar to the latter with the added feature of finding undocumented functionality. Felix Domke (tmbinc) recently gave a lecture on enumarating undocumented JTAG instructions and anyone considering using JTAGenum would do well to check his paper(cache)/lecture from the 26c3.

About JTAG

JTAG is a common hardware debugging interface. It is used throughout the development chain of a device. Layout designers and board manufactures that employ pick-and-place machines will use JTAG to test interconnectivity of components. ASIC designers use it to test the internal state of the chips they build. Software developers often use it to load firmware onto the device and to debug software.

For a varity of reasons JTAG is often left in the final product. As such each stage of the development chain will attempt to obfuscate its existence or functionality. ASIC manufactures often build in added functionality (such as logic analysis tools) and avoid mentioning both extended and often basic functionality from their final documentation. Layout designers might remove JTAG pins from the board, spread their contacts throughout on the board, remove contacts and hide JTAG lines on inner layers of the board. As mentioned before, this can make it difficult for any one part of the development chain to evaluate the security of the device as a whole. If you are unfamiliar with the inner workings of JTAG skip to the A bit more about JTAG section for the basics.

Hardware

To use JTAGenum you need an arduino compatible microcontroller. Arduino is a simple development enviornment (IDE) for various microcontrollers. At the moment AVR and PIC variants are available and can be purchased anywhere from $10 to $50. JTAGenum has been tested on the official Arduino Duemilanove, Arduino Mega (see hackerspace.be modifications), RBBB clone and Teensy++. When picking your microcontroller platform consider two issues: 1. How many pins do you want to check on your target. 2. what voltage level does your target device require.  Concerning voltage most Arduinos work at 5 volts. Some are switchable but even those that are not can be modified. For example revision 1.0 of the Teensy++ with over 30 pins of i/o can be modified by hand to operate at 3.3 volts. I show where to cut lines and install a voltage regulator over here (Update: Teensy++ version 2.0 has a spot on the pcb to install a 3.3v regulator). For voltages other than 3.3v and 5v there are a variety of solutions that depend on if you need uni-directional or bi-directional support on your i/o lines. Alessandro provides schematics and board/shield design for bi-direction i/o voltage conversion.

When connecting the microcontroller to the pins of your target one thing to be aware of is possible cross-talk between wires. I’ve been using a patch cable from Amontec that has a lot of cross talk.  JTAGenum has a mode that helps check for this which I will get into more detail later.

Usage

Download the JTAGenum code and open it in the Arduino IDE. The following needs to be changed in the code depending on your microcontroller:

• pins[] define which pins on the microcontroller are being used to connect to the target
• pinname[] is a convenient way to map the pins to names which correspond to the names of pins on your target
• IR_LEN defines the length of the JTAG instruction register. If you change this you should also add ’0′s to each of the coresponding IR_** instruction definitions. You can find the IR_LEN in the documentation for your target. If you cannot find it just guess. (10 is the current value, 8 is also common)

Upload the sketch to your microcontroller and open the serial console with a baud of 115200.  Sending a ‘h’ to the console will print usage information that describes each function. Each function is enacted by sending the defined one character code:

v > verbose

Toggles verbose output. At times verbose might present too much information or without it too little.

l > loopback check

Find loopback pairs that will generate false-positives for other tests. After running you should remove any loopback pairs from your pins[]/pinnames[]. Looback pairs are found by sending a predetermined pattern[] to all possible pins while checking all pins for matching output.  Because the JTAG clock (TCK) and state (TMS) pins are NOT being stimulated the input/output pairs where the pattern is found represent loopbacks. NOTE: you should probably run this once with and without internal pull-up resistors set (‘r’) to avoid problems of cross-talk which is discussed in detail later.

s > scan

This routine is used to check all possible pins and find JTAG  clock, state, input and output pins lines (TCK,TMS,TDI,TDO). This is done by setting the JTAG state (TMS) into Shift_IR mode and then sending pattern[] to TDI and checking for it on TDO while clocking TCK. This check is run for every possible pin combination and it is important that you remove loopback pins before running. While this scan is meant to determine all of the JTAG pins required it is possible that the  TMS pin found is incorrect.  This depends on if the target uses the bypass register by default (described later). If an IDCODE register is present then bypass mode is not the default and you can assume that the pin this scan defines as TMS is correct.  Otherwise, only the TCK, TDI and TDO pins can be determined.  NOTE: run with pull-ups on (‘r’) as any cross-talk might result in false-positives.

y > brute force IR search

This will set the instruction register (IR) to all possible values and check the output. This can be used to find undocumented instructions and examine their results via the data register (DR). To run this scan you should have already determined the 4 JTAG pins and define pins[] as such: [0]=TCK [1]=TMS [2]=TDO [3]=TDI.  NOTE: run with pull-ups on (‘r’) as any cross-talk might result in false-positives.

x > boundary scan

This will return the state of all the pins on the target.  Actually it is not just the pins but the contents of the scan/sample register. This should be a rather large register and is defined in the code by SCAN_LEN+100. You can check your targets documentation and specify this or just leave it as a large number (currently 1800). To run this scan you should have already determined the 4 JTAG pins and define pins[] as such: [0]=TCK [1]=TMS [2]=TDO [3]=TDI.  NOTE: run with pull-ups on (‘r’) as any cross-talk might result in false-positives.

i > idcode scan

The JTAG standards specify that if an idcode register is present it should be set as the default data register (DR) and attached to output (TDO) by default. Meaning, regardless of the state of the JTAG chip (set with TMS line) and regardless of input being sent to the chip (TDI) by clocking the chip (TCK) it should return the contents of the idcode to the output (TDO). Hence, this routine iterates through all possible TCK,TDO pairs of pins, CLK’ing each bit along the way, and prints the output when there is any change (we assume an idcode will not be all 0′s or 1′s). You should examine the documentation of your target(s) to see if the idcode matches. NOTE: run with pull-ups on (‘r’) as any cross-talk might result in false-positives.

b > shift_bypass

Broken atm (need to add TCK enumeration). The JTAG standards specify that if and idcode register is NOT present on the chip then the bypass register (length of 1) should be the default DR. Essentially this means what is sent to the input (TDI) should come out on the output (TDI) with a one clock delay (TCK). It is important that you remove loopbacks before running this test otherwise the loopback pins will look like valid JTAG lines. NOTE: run with pull-ups on (‘r’) as any cross-talk might result in false-positives.

r > set pull-up resistors & cross-talk

If like me the cables you use to connect between JTAGenum to your targets are flimsy or uninsulated you might run into issues of cross-talk whereby when one pin is transmitting a nearby pin picks up the transmission even though they are not connected. To avoid this you can turn on the internal pull-up resistors which will force the pin to a default state. If for some reason you continue to have sporadic issues run the following in sequence to check if the problem is the cable, target or other:

1. Disconnect the cables between your target and JTAGenum. Disconnected them entirely from JTAGenum as well.
2. Run a loopback check (‘l’) with pull-ups off. In this state the pins are in open mode and might fluctuate.  You’ll notice that as you move the microcontroller around, turn lights on and off or move other devices close to or away from it that the results change.
3. Turn on pull-ups (‘r’) and run the test again. The results should now be consistent. If they aren’t, then let me know.
4. Now attach your cables to JTAGenum but not the target.  Run steps 2 and 3 again. Step 2 will give you a feel for how much inconsistency the cable may add. If the loopback check results in actual pattern matches then your cable has cross-talk. Step 3 should still result in a consistent state of either all high (1′s) or all low (0′s) and if it doesn’t then your cross-talk issues are such that all JTAGenum tests are going to be buggy at best. Feel free to give me an emailand I will happily try to help solve the problem.

Code references

Examining code of various jtag scanning derivitives is probably the best way to modify JTAGenum however you want or when wanting to cross reference JTAG logic to debug a problem.

• JTAG Finder – the microcontroller provides a pin protocol/interface to a C client running on the PC which does the actual scanning logic. This was one of the first (if not the) JTAG scanner.  It trades simplicty of code and protocol for efficiency and speed.
• JRev – Not meant for scanning pins to find JTAG. It does however implement some logic not in any of the JTAG scanners mentioned here.  In paticular, support for chain mapping, IR length detection and perhaps others I’m missing.
• Arduinull – The first simplified scanner running all in the microcontroller.
• JTAG pinout detector – a port of Arduinull and JTAGenum for the Arduino Mega board.

Additionally Jal2 and Zoobab have written their branches of JTAGenum.  I will try to merge their features to the JTAGenum branch as quickly as possible but if you run into problems or for general curiosity you can check their code.

A bit more about JTAG

Basic understanding of how JTAG works will be helpful when using JTAGenum. There are 4 lines/pins: TDO=output, TDI=input, TCK=clock, TMS=state machine control.  Say you want to read the ID of the chip. First you would send the IDCODE instruction to the instruction register (IR). The JTAG controller then places the actual id code value of the chip in a data register which you could then read out. You would think that it would be enough to have one input line going to the IR and one output coming from the DR but JTAG also supports writing to the DR. As apposed to adding another input line specific to the DR instead JTAG works by moving the input and output lines between IR and DR. The TMS line is used to switch TDI/TDO to IR when you want to place an instruction and back to DR when you want to read or write data. With all operations, be it state change (TMS) reading (TDI) or writing (TDO), the clock line must be cycled once (TCK) for every bit or change. This was a brutal and drastic simplification but with that understood reading the Usage section should be comprehensible.