Why Do Manufacturers Use JTAG?
With the invention of integrated circuits came the need to test physical interconnects. That is: test whether "Point A" on a circuit board correctly connects to "Point C". As industry drove toward higher density interconnects and finer pitch (i.e. smaller) components, a standardized way of testing integrated circuits (or "chips") was needed. By embedding the test logic within the IC itself and limiting the physical interface to just a few signals, JTAG/boundary-scan presented an elegant solution to testing, debugging, and diagnosing modern electronic systems. Simply stated, boundary Scanning allows you to read and write individual bits, on individual pins, of the individual chips on a board. This ability to read and write 1's and 0's directly onto the pins is extremely powerful, but widely misunderstood.
The JTAG interface gives manufacturers a way to test the physical connections between pins on a chip. When electrical engineers talk about using JTAG to "debug" a chip, they are talking about something very different than traditional software debugging. They are talking about making sure pin A on chip A is physically connected to pin B on chip B, and that all those pins are functioning correctly. Since JTAG gives you direct hardware access to a device, it's also a fantastic tool for security research.
4 Pins, Plus 1
The official JTAG standard requires 4 standard pins (or signals), and defines an optional 5th. These signals, and the small bit of silicon logic that connects and controls them, are collectively referred to as the Test Access Port, or TAP controller.
- Buzzword: It is a infosec buzzword, everyone talks about it but few really share actionable info
- Loaded Word: JTAG has come to mean many things to many people. For example, in the gamer community "JTAG" means a hardware modification for a console that allows playing pirated games or loading homebrew content (i.e. "a jtagged XBox"). This makes it difficult to search for useful information.
- Vernacular Overlap: As mentioned above, when an Electrical Engineer says "debug" he means: "Are the pins in the right place? Is there enough power? Is the logic of the circuit correct?" When a Software Engineer says "debug" he thinks of GDB or WinDBG. JTAG is designed for the former, not the latter.
- Misunderstanding: As software developers the closest similarity to JTAG is maybe Kernel debugging via a debug cable (USB, Parallel, or Serial). But this is a dangerous comparison, because even on the "debugee" (in that scenario) there is software code executing on the remote system handling the translation of commands arriving on the debug cable. The JTAG state machine implemented entirely in hardware on the target.
- The name of a specific device for debugging firmware or hardware
- The name of a piece of software used for debugging software code running on an embedded device.
- The name of a protocol: The JTAG specification doesnt even define the protocol for how data is passed between debugger and debugee (i.e. there is no .h file you can reference defining a "JTAG packet" to be passed over a serial, parallel, or USB cable to a target)
- The name of a kind of connector: Unlike a specification like USB or Ethernet, the JTAG specification doesn't even define what connectors should look like. This leads to a VERY confusing diversity of "JTAG" connectors. This is often a huge source of confusion to a software person. Imagine if every USB cable was different!
- TCK: Test Clock
- The drummer, or metronome that dictates the speed of the TAP controller. Voltage on this pin simply pulses up and down in a rhythmic, steady beat. On every “beat” of the clock, the TAP controller takes a single action. The actual clock speed is not specified in the JTAG standard. The TAP controller accepts its speed from the outside device controlling JTAG.
- TMS: Test Mode Select
- Voltages on the Mode Select pin control what action JTAG takes. By manipulating the voltage on this pin, you tell JTAG what you want it to do.
- TDI: Test Data-In
- The pin that feeds data into the chip. The JTAG standard does not define protocols for communication over this pin. That is left up to the manufacturer. As far as JTAG is concerned, this pin is simply an ingress method for 1s and 0s to get into the chip. What the chip does with them is irrelevant to JTAG.
- TDO: Test Data-Out
- The pin for data coming out of the chip. Like the Data-In pin, communication protocols are not defined by JTAG.
- TRST: Test Reset (Optional)
- This optional signal is used to reset JTAG to a known good state, we'll explain why this is optional in a few paragraphs.
...the JTAG State Machine is so simple that you can write Arduino code to "bit-bang" interface with it...
The JTAG specification IEEE 1149.1 specifies not only the signals but how the "State Machine" embedded in the TAP Controller of a device must behave. The State controller diagram is in the upper left of the video below. By manipulating the voltage on the TMS pin of the TAP controller and the TCK pin, you control the way the State Machine changes state. On each beat of the clock, the JTAG TAP controller in your targeted device checks if there is voltage on the TMS pin, and interprets that as either a 1 (voltage) or a 0 (no voltage). This series of 1’s and 0’s moves JTAG through a relatively simple State Machine. This state machine is so simple that you can even write Arduino code to manipulate it. The value of the TMS pin needed to change state is denoted with a tiny "1" or "0" in the state machine diagram. You can see the operation of the state machine in the animation below
Note that data is read into and out of the TDI and TDO pins while the state machine is in the Shift-IR or Shift-DR states. The specific differences between these states, and the registers they utilize are beyond the scope of this article. Suffice to say that IR (Instruction Register) and DR (Data Register) are like function calls. The value in IR is the "function" and the value in DR is the "argument". The JTAG specification doesn't define what the "functions" should be, that's up to the manufacturer.
Animation of the JTAG TAP controller "Train Station". The TAP controller's state routes the TDI/TDO tracks to the register "platforms".
Finally, be aware that the JTAG interfaces of multiple chips on the same board can be daisy-chained, so you don’t need a separate set of JTAG pins for every chip on the board. They can all be tested through a single set. This is particularly interesting with System-On-Chip (SoCs) where multiple components (ethernet, wifi, bluetooth, etc) are in a single chip. The JTAG chain often passes between these different cores internally in a single chip.
JTAG for Security Research: The Full Toolkit
JTAG is an interface and does not know how a chip will react to command strings. Trying to hack a device using JTAG alone would technically be possible, but it would be extremely time consuming and require a deep, holistic understanding of all the internal workings and architecture of the chip. For JTAG to be an effective research tool you need something that can translate between human-readable code and the low-level instructions coming in and out of the JTAG TAP controller. The true power of JTAG is unlocked by giving debugging software like OpenOCD control over the JTAG interface. OpenOCD is THE ONLY Open Source repository (knowledge base) for a variety of chips and interfaces. OpenOCD can (when paired with a JTAG interface device) manipulate the JTAG’s TAP controller on a target device to send bits to it (via the state machine above), which the chip will then interpret as valid commands.
Running OpenOCD over the JTAG interface will allow you to pause and step through an operation, inspect memory, write bytes directly into memory, set watch-points and break-points, and even inject code into the process or process memory. We call this technique “Hardware-based Software Debugging.” We are manipulating the hardware to perform traditional software debugging tasks. In fact, OpenOCD even allows you to use familiar software debugging tools by spawning a GDB server, allowing you to debug firmware and software in devices via GDB, IDA Pro, or anything that is capable of acting as a GDB client.
With all the thousands of different chip architectures out there, how does OpenOCD know how to communicate with them all? Simply put, OpenOCD uses special config files to learn these instructions. The config file teaches OpenOCD the correct way to manipulate the TAP controller for that particular chip’s architecture. You must have the correct config file for the chip you want to communicate with. Config files for many of the most common chip types are included with OpenOCD and most others are easily downloadable online.
Most computers don't have the necessary hardware built in to communicate with JTAG. Hobbyist devices such as the Shikra or BusPirate can be obtained easily and affordably online. Professional devices may provide greater control and throughput, and often include their own debugging software, but the cost increases accordingly. If you are using OpenOCD, it also needs a configuration file that will teach it how to communicate with this device. Communication between your computer and the JTAG controller is usually done through a serial interface.
Hopefully at this point you've begun to realize the potential impact of getting JTAG access on a device. When set up properly, the power and control it can give you is unparalleled. In a sense, if you have JTAG access on a device, you've already owned it. You can see data as it goes by, modify data at will, and usually dump out the contents of RAM and FLASH chips on the board. Despite these advantages, JTAG is often overlooked by security researchers, in favor of software based ingress methods.
Mounting an Attack: Rooting a Home Router
Use JTAG to quickly and easily bypass the login prompt, get a root shell, thereby completely defeating the built-in security of the device.
- Connect a Serial-to-USB cable to the UART interface on the device. This will allow you to monitor what the router is doing while we are setting the hardware bits.
- Power on the device to reach the login prompt we’re going to be bypassing. This gives you UART access to the regular user interface.
- Hook up the Shikra to the JTAG interface to actually hack the device. One pin on the Shikra connects to the corresponding pin on the device. If you are not sure which pin is Data-In and which is Data-Out, it's easiest to just try one, and if you're wrong, reverse them. You can see the JTAG pinouts on the Shikra in the diagram below and find more information on how to connect the Shikra here.
- Connect the Shikra into a USB port on your computer, and then physically wire the pins on the Shikra to the JTAG interface on the router.
With everything hooked up correctly, your setup would look like this, with the target device (in our case an Access Point) connected through our "JTAG Interface" (in our case The Shikra) to the Controlling computer running the software for interfacing with JTAG (in our case OpenOCD and GDB).
JTAG is there for a reason...it's there because Manufacturers need it for everything from validating proper assembly of the circuit board to loading firmware on the device...
With JTAG access we can:
- Read and Write from memory
- Pause execution of firmware (set breakpoints and watchpoints)
- Patch instructions or data into memory
- Inject instructions directly into the pipeline of the target chip (without modifying memory)
- Extract Firmware (for reverse engineering/vulnerability research)
- Bypass protection mechanisms (encryption checks, password checks, checksums, you name it)
- Find hidden JTAG functionality that might do far more than we imagine.
- ...do whatever we want really
JTAG is an extremely powerful interface to embedded devices. Developers that write code that is deployed on embedded systems are often unaware that this level of access exists. We've seen systems where the firmware developers seemed to have poured hours into encrypting and protecting data in their code without realizing it can be subverted trivially with hardware-level access.
There is far more to JTAG than can be covered in a single blog post, but hopefully this has gotten you thinking about some of the numerous opportunities that JTAG access provides. Still want more on JTAG? Check out the hands-on training we offers on this subject.
With these kinds of debug interfaces ubiquitously present in embedded devices, many of them are extremely vulnerable. So how can you protect against someone that has put the effort into work like this? Monitor your embedded devices!