Imagine you are handed this device and asked to get root on it as quickly as possible. No further information is given. Where would you begin? (If you just want to see the router get rooted, jump down to "Mounting an Attack: Rooting a Home Router" ;-)
Our target: A VERY common/popular consumer Access Point.
Since you have the device in your hands, you might try directly attacking the hardware. However, if you've never done any kind of hardware hacking, getting started can be intimidating. In this post, we are going to talk about the fundamental information you need to know to use JTAG for hacking hardware. We'll also go over a quick example to illustrate the power of direct hardware access.
Why Do Manufacturers Use JTAG?
JTAG is a common hardware interface that provides your computer with a way to communicate directly with the chips on a board. It was originally developed by a consortium, the Joint (European) Test Access Group, in the mid-80s to address the increasing difficulty of testing printed circuit boards (PCBs). JTAG has been in widespread use ever since it was included in the Intel 80486 processor in 1990 and codified as IEEE 1491 that same year. Today JTAG is used for debugging, programming and testing on virtually ALL embedded devices.
Boundary Scanning
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.
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. |  |
JTAG Fundamentals
Before we go into using JTAG to actually hack something, let's review the JTAG fundamentals.
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.
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.
The JTAG "Tower of Babel"
One of the most confusing thing about learning to get hands-on with JTAG is how much partial and disinformation there is about it. Manufacturers' websites tell you the "theory" of how it works, but leave you longing for more information about "how to get started". To further confuse things there are other factors:
- 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.
What JTAG ISN'T!
In an effort to dispel disinformation (which is so rampant) here is what JTAG isn't.
- 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!
All of the connectors above can be referred to as "JTAG" connectors.
 JTAG connector for a DD WRT router |  JTAG connector for a Point-Of-Sale device |
All of the connectors above are "JTAG" connectors. Why do they look so different? Where is the standardization? In practice, you can find hundreds or thousands of different looking "JTAG" connectors in devices. Why? Before we explain why, let's not talk about what it isn't and talk about what it is (according to the specification).
What JTAG IS: The Five required JTAG Pins (or "Signals")
Here is what JTAG is. In it's most fundamental. The JTAG specification 1149.1 requires these five signals:
- 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.
Now that we know what pins/signals are really defined as "JTAG" let's take a second look at the sample of connectors from above:
Ah hah! We now see that each of these connectors have JTAG related signals!
We now see that what makes these connectors "JTAG" is not their pin configurations, but rather the mere presence of these JTAG signals. It is with these signals that we can manipulate and communicate with the State Machine of a target device via it's "Test Access Port" (or TAP) controller embedded in its silicon.
...the JTAG State Machine is so simple that you can write Arduino code to "bit-bang" interface with it...
The JTAG State Machine
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
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
The JTAG State Machine in operation. (A very simplified representation.) In reality, the signal sampling is slightly different (sampling of signals happening on the rising or the falling edge, differently). Also the "clock signal" visualization above is slightly buggy in that there is only one State Machine operation per clock cycle. Sampling happens with each Clock cycle.)
| 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". |
It’s also interesting to note that, from anywhere in the state machine, if TMS is held at a 1 for five clock cycles in a row, you will wind up in the "Test Logic - Reset" state. If the TRST pin is omitted, this method can be used to reset the TAP controller to a known good state. Hence why TRST is "optional" as we mentioned above.
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.
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.
  |   |
Examples of how JTAG passes through several devices (chips) or even several different cores in a single chip!
JTAG for Security Research: The Full Toolkit
In an effort to provide their engineers and developers easy access to test and program integrated circuits, manufacturers developed JTAG. However, if you put a state-of the art lock on your door and leave the key under the doormat, your "secret" is only as secure as the knowledge of where to find the key. In this case, JTAG gives attackers an easy way to find the keys to the kingdom. Let's dive into the world of JTAG and see how this useful developer tool can be used for security research purposes.
JTAG Is a Simple "Dumb" Interface
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.
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.
Hardware-Based Software Debugging
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.
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.
Configuration Files
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.
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.
The Shikra is a "hardware hacking" swiss army knife Additional Hardware
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.
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.
The Under-Appreciated Ingress
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.
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
To demonstrate how easy it can be to completely own a device using JTAG, we will step through an example borrowed from our Software Exploitation via Hardware Exploitation class. Remember that little wifi router we mentioned at the top? The manufacturer implemented a standard login prompt, which prevents you from issuing any commands on the device until you’ve provided appropriate credentials. The credentials for this prompt are not well known, and the manufacturer is keeping them secret. Your mission: get into the device anyway.
Use JTAG to quickly and easily bypass the login prompt, get a root shell, thereby completely defeating the built-in security of the device.
| 1. Hooking Everything Up In this example we will use a Shikra as our JTAG controller and OpenOCD as our debugging software, running in a Linux virtual machine. |  |
- 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.
Once the UART connection is made to the device, when the device is powered on we interactively watch the device boot!
Any excitement from that is quickly tempered when confronted with this login screen after the device has fully booted.
We need a way to bypass this login screen...
JTAG Interface on our access point. We'll see if we can leverage a JTAG connection to help us bypass this login screen!. Finding the JTAG interface on your device can be a challenge. JTAG is rarely exposed to the outside of the device, so you'll probably need to open the case up. Once you have it open, sometimes the correct pins are obvious. Other times the manufacturer has hidden them, or removed the pins altogether. If the JTAG pins are not immediately obvious, spec sheets and technical documentation are great places to look to begin tracking them down. If spec sheets are unavailable, or not helpful, tools like voltage meters, logic analyzers, and the JTAGulator can be used to identify the JTAG interface. If the manufacturer has been truly diligent about disabling JTAG, accessing the interface might require a soldering iron. Many of the techniques for how to handle this are covered in our sexviahex.com course.
The MCU is there in the center.
2. Getting Root
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).
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).
Our target is all connected up through the Shikra. Little does he know it but he's about to get 0wned.
With the UART connection we can interact with the device, but as we begin opening terminals to start OpenOCD we want to keep an eye on the UART terminal as well because that will help us see if the device throws any errors or reboots.
The three main screens of an OpenOCD session.
The first thing we might try is a halt command to pause the operation of the router. Unfortunately, if you're watching the UART front end, you’ll see that after about a second, the router reboots. This is due to a feature of the router’s operating system called the Watchdog Timer. If the Watchdog notices that the router has stopped working for a set amount of time (usually less than a second), it automatically reboots the router. This feature can easily be bypassed by issuing the halt command, waiting for the reboot, then immediately issuing the halt command again, before the watchdog timer has had a chance to load. Since we want to modify the boot parameters, we want to issue that second halt command before the boot loader has had a chance to actually start the operating system.
Having paused the router, we can set breakpoints, step through the operation, and inspect/inject memory on the device.
To root the router we will be modifying boot arguments in memory to boot the router into Single User mode. To do this, all we have to do is add a space character and the number 1 to the end of the boot options for the router. To view the boot arguments we use an extracted firmware image from the router. We'll use the "xxd" trick to turn Vim into a "hex editor":
Step 1: Using Vim as a "hex editor"
 Step 2: Using Vim as a "hex editor" |  Step 3: Using Vim as a "hex editor" |
Step 4: Using Vim as a "hex editor"...There are the boot arguments!
Using the extracted firmware image of the device, we have an idea of where the boot arguments will be in live memory. We can set a watchpoint on the place in memory that we know the boot arguments will likely be once the kernel is decompressed into memory shortly after boot. This will allow us to observe the device not only performing this decompression but also reading from those kernel arguments before the kernel boots . We set a watchpoint on that memory address and resume operation.
Setting a watchpoint on the place we know the kernel boot arguments will be.
The router will continue its boot process, but as soon as it touches the memory address where our watchpoint is set, execution will pause again. Once execution pauses for the watchpoint as the kernel is being decompressed into memory, we can perform a memory write to append a "<space> 1" (which as a hexadecimally represented short is: 0x2031) to the end of the boot arguments. We can then remove the watchpoint, and allow the router to finish booting up.
using the "mdw" (memory dump word) command to dump memory and the "mww" (memory write word) values to perform our critical overwrite.
And if we observe the device continue booting....we now see that our boot sequence is a little bit different!
ROOTED!
We now have a root shell on the router via the UART interface. Start to finish, this entire process can be done in about 15 minutes.
SexViaHex.com participants bypass router login prompts, extract firmware, and modify memory all via JTAG
Mitigations
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...
JTAG is incredibly useful to chip manufacturers during design, testing, and production phases. As such, it is included in nearly every embedded system on the market. However, as we've demonstrated, JTAG also represents a huge potential attack vector. Manufacturers are aware of this risk, and will often take steps to prevent access to JTAG interfaces. Manufacturers may try to obfuscate JTAG traces on the board, or even cut them entirely. They may deliberately blow fuses in the JTAG wiring as part of the manufacturing process. These methods are somewhat effective, but a determined attacker who is talented with a soldering iron can almost always repair the damage. Several different standards have been suggested for adding encryption and cryptographic authentication to the JTAG standard, but they have not been codified, and are rarely implemented in practice.
Conclusion
One of the immutable tenets of IT security is that if an attacker has unrestricted physical access to your device, it is no longer your device. JTAG is one of those technologies which makes this statement the truism that it is, and hopefully this article has helped you understand why.
With JTAG access we can:
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!
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!
Special thanks to Dalin McClellan for helping us compose this article!
RSS Feed