DEVELOPMENT OF A JTAG PIN FINDER

Some years ago I was contacted by a Detective from the Victoria Police - Forensics Department inquiring if I knew a way to determine the TAP pins on cell phones when the pins are not labeled. Upon giving it some thought, and researching the particulars of the JTAG protocol, I determined that it would be possible to some extent. So I began putting a prototype board together, and with the use of two Samsung phones the Detective sent me, I started to it. This design however is now outdated as since then, electronic devices have started using lower and lower voltages and this Pin Finder is only useful for 5.0v and 3.3v systems but for a time was quite popular and several units found their way to various law enforcement agencies around the world.

A newer version that can go as low as 1.8v with the added bonus of JTAG pass thru so you can use the Pin Finder to locate pins and then have another JTAG master then test those pins further without the need to disconnect and reconnect wires to the device under test saving time and possible damage to the device. A future post that will talk about this newer version in more detail will be coming soon.

Hardware

The hardware is decidedly simple. I used a Parallax Propeller microcontroller connected to an FT232 USB to Serial converter and a USB mini connector. I chose the Propeller because of its easy programming and debugging through the USB as well as the fact that it has 28 free pins for interfacing. The interface to the cell phones is nothing more than 100 ohm resistors in series with the pins under test for current limiting purposes. In addition, a 10K resistor is connected from each channel pin to a free IO pin. This allows the unused channel pins to be pulled either high or low independently. As the sniffer has 12 channels, 24 IO pins are used along with 2 for the UART, and 2 for the 32K EEPROM for a total of 28 used pins and 4 free pins left over. This particular setup is easily implemented on any microcontroller with enough free pins.

Software

The software is the heart of the unit. At its core is the combination array used for testing. I spent some time researching combinatorics and looking unsuccessfully for an algorithm to generate the possible combinations. Since then, I have created an algorithm saving a large amount of space on the microcontroller and will be used on the newer version. I found many websites that described the total number of combinations possible, and in my case, I needed the number of 4 line combinations of a possible 12 lines with the order being important. This total was 11880 possible combinations. I did find a website (Mathisfun.com) that listed all the combinations for me and had a handy option to save this as a file. All that was left to do was to write a small VisualBasic.NET program to parse the file and save the data in a binary format usable by the Propeller. Since I have 12 channels, each combination item would fit into a nibble. As such, each combination consumed 2 bytes of memory, and since there are 11880 combinations, a total of 23,760 bytes were needed to store all the possible combinations on the Propeller. So for the first combination (0,1,2,3) – Byte 0 = 0x01, Byte 1 = 0x23. This is why I chose 12 lines and not more. As you add more lines, the possible combinations grow exponentially. For example: 13 lines – 17160, 14 lines – 24024, 15 lines – 32760, 16 lines – 43680. Since the Propeller has 32K ram on board, memory for 12 lines is the most it could hold directly.

Operation

The basic operation of the firmware is as follows:

• Load the first combination from memory

• Set the TCK, TMS, TDI channel pins to output and the TDO pin as input as specified by the loaded combination.

• Set all channel 10K resistors to pullup so as to prevent floating pins.

• Reset the device TAP.

• Scan for possible devices. If no devices are detected, load the next combination.

• If the ID command is known, send the ID command to the device and read back the ID code.

• If the ID command is not known, reset the device and move directly to the Shift-DR state and read the ID code.

• If the ID code is equal to 0xFFFFFFFF or 0x00000000, discard the combination and load the next combination.

• If a possibly valid code is found and the ID command is known, reread the ID code directly after a reset and confirm that the codes match. If they do not match, discard combination and load the next combination. If they do match, save the combination and ID code.

• If a possibly valid code is found and the ID command is not known, save the combination and ID code to be listed after all combinations have been tried.

• Once all combinations have been tried, list all the possible combinations.

The particulars of moving to and from various TAP states can be found quite readily online, so I won't go into the specifics of TAP control or basic JTAG operations here.

One additional feature that was added to the firmware is to enter the number of unknown channels to use. By doing this, the firmware will skip any combinations that include any channels that are not used. This will speed up the search process depending on the number of channels used.

The JTAG portion focuses on the ID word contained in the device.The ID command is optional according to the IEEE 1149.1 spec but most if not all manufacturers implement the command. After resetting the TAP, the ID code is automatically loaded into the Data Register. If you move the TAP to the Shift-DR state, you can clock out the ID code.

This is how the firmware searches for possible combinations without using the Instruction Register. The disadvantage to this method, is that it will likely result in multiple combinations being found. However, by inspecting the found combinations, you can deduce what pins to focus on. If you look at the screenshot, you will see that the firmware found 6 possible combinations. This is on the phone shown above. You can see that the TCK and TDO pins are identical on all combinations, and the TMS is the same for 3 of the 6 combinations which would be a good guess that it is the correct pin. Finally, The TDI pin is channels 0, 4, or 6. So from being completely in the dark with an unknown header, the firmware has reduced the options to just 3.

This is the search option for an unknown device ID command, scroll down to the next section to see how the firmware resolves a known device ID command.

The best way to find the unknown pins is with the use of the ID command. To search this way, the firmware needs to know two things: The length of the Instruction Register, and the ID command value. Both of these can be found in the Boundary Scan Description Language file, or BSDL file for the processor being examined. In addition to these two requirements, the BSDL file will also contain the ID code value. This is great because it adds another level of confidence when the firmware finds a valid combination. The caveat of course is that many manufactures keep this file proprietary but it's great is you are able to source the information.

In the next example, the Samsung SCH-i910 phone uses the PXA312 processor. After a short search online, the BSDL file specifies an Instruction Register width of 11 bits, an ID command of 0x04, and an ID code of 0x2E649013.

Plugging the two requirements into the software and starting a search resulted in the combination shown to the right. As you can see the ID code is exact, and there was only one valid combination found, which is also correct.

I have tested it with the other phone the Detective sent me, which happens to be another Samsung model with a different processor, with similar results as shown here, as well as tests using a few Xilinx chips.