JTAG Pin Finder

 Update: We are now currently selling the JTAG Pin Finder. Click here for details.  

    Recently 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.


    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.

    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. 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 (link here) 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.

    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 Pin Finder connected to one of the Samsung phones
send to me by the Detective.


    
    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 image on the right, 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, scroll down to the next section to see how the firmware resolves a known device.















     

 
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. 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.
    In the example on the right, 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.












Copyright © 2012 by 100RandomTasks. All rights reserved.
Comments