Category: Hardware

Extracting Flash Memory using JTAG

I previously mentioned dumping memory contents using SPI, with a BusPirate. Sometimes that’s not feasible – such as if the flash memory module is a little inaccessible and you’re not feeling like deconstructing the board just yet.

An alternative is to pull memory over JTAG. I talked about accessing JTAG and interacting with a chip using OpenOCD previously, however this time around I’d like to go a step further.

The board I’m using in this example is a Netgear DG834Gv1, which has an exposed JTAG, shown below on the bottom right of the board (in red):

I’ll pick up from where the previous post left off, at that point we had connected OpenOCD to the device and ran “scan_chain”, which I use just to confirm communications are working as expected. However now we’re going to set up an additional config file which maps out the CPU and Memory.

We’ll need a few details about the chips – on this board their markings are visible which makes things a little easier. For example, the CPU can be seen near the centre of the board – marked TNETD7301GDU. This will lead to the data-sheet which will lead to the information required for the config file. For example, the data-sheet says it’s a Texas Instruments AR7, which is a MIPS architecture.

It’s worth pointing out that for the DG834Gv1, OpenOCD already has a configuration file – but I’ll include what I’m using here so you can take a look at what it contains and what each part does:

adapter_khz 1000
transport select jtag

set partition_list {
all { "All 4MB" 0x90000000 0x00400000 }

jtag newtap ti-ar7 cpu -irlen 5 -expected-id 0x0000100F
target create ti-ar7 mips_m4k -endian little -chain-position ti-ar7.cpu
flash bank ti-ar7.norflash cfi 0x90000000 0x00400000 2 2 ti-ar7

So with the above, we’re configuring information about the CPU architecture, and the flash memory we’d like to interact with. On this board there is 4MB of flash (determined by looking at the chips on the board and finding their data-sheets – then this is defined on the last line of the config file with the flash bank command). The CPU architecture is given as a target create command, are defined as MIPS.

We’re setting it up to pull the entire flash contents over JTAG here. If you would like to pull a “piece” of memory instead, you can arbitrarily alter the “partition_list” variable by changing the start (here that’s set to 0x90000000) and length (which here is 0x00400000, that’s hex for 4MB) variables.

So above I’ve just configured “all” to refer to the entire memory content – but alternatively you could configure something like this:

set partition_list {     
loader { "Bootloader (ADAM2)" 0x90000000 0x00020000 }
firmware { "Kernel+rootfs" 0x90020000 0x003d0000 }
config { "Bootloader config space" 0x903f0000 0x00010000 }

This set up is sourced from the OpenOCD configuration file for the DG384v3 board and shows how you can separate bits out from the memory, if you know the layout and only want a specific piece. However, this “partition” separation isn’t mandated, you can (as with my config file above) pull out the whole thing. Separating it in the way the OpenOCD file does allows you to optionally pull specific areas of memory if so desired.

To actually extract the contents, the above configuration file can be supplied along side the configuration file for your JTAG interface (as before I’m using a UM232H) and the firmware-recovery tools files. Then you can extract the memory like this:

openocd -f /usr/share/openocd/scripts/interface/ftdi/um232h.cfg -f /home/hollyw/config3.cfg -f tools/firmware-recovery.tcl -c "dump_part all output.bin"

The above command will load the configuration for the UM232H, which as mentioned previously is the JTAG interface that I’m using. It will configure the architecture and memory layout – defining an “all” partition referring to the full 4MB of flash. It then loads the “dump_part” function from firmware-recovery.tcl and uses it to output the flash contents to a file called output.bin!

Pulling a bit of firmware over JTAG!

That’s it!

An Introduction to Logic Analyzers

Getting up and running with PulseView and reading pin output with an Analyzer!


Logic Analyzers are inexpensive devices that allow you to just take a look at what a small number of pins on a chip are up to. They can be hooked into software like PulseView to read pin output and decode it into something more useful. Many decoders are available, but in this introduction we’ll have a quick look at PulseView and reading (decoding) UART data.

I’ve previously written about UART and how to find them with a JTAGulator, but here’s a different approach.

Continue reading: An Introduction to Logic Analyzers

Finding Serial Interfaces (UART)

Discovering UART with the JTAGulator and connecting to it with UART PassThrough and a USB-to-UART!


UART stands for Universal Asynchronous Receiver/Transmitter, however in the context of Hardware Hacking we’re generally looking for an serial interface which will give us text output from the system and possibly allow for command input. The general intention from the manufacturers point of view – is to allow easy debugging, both out of the factor (to check the system is working as intended) and if a device is returned as broken.

Continue reading: Finding Serial Interfaces (UART)

JTAGulating JTAG!

Discovering JTAG ports with the JTAGulator, and connecting to them with UM232H!

What is JTAG?

JTAG is short for Joint Test Action Group and generally refers to on-chip debugging interfaces that follow the IEEE 1149.x standard. The standard doesn’t mandate a certain connection – it just dictates a standard for communicating with chips in a device. It uses 5 pins: TCK, TMS, TDI, TDO and (options) TRST; which are (Test) Clock, Mode Select, Data In, Data Out, and Reset.

It can be useful to hardware hackers in various ways, such as extracting device IDs, extracting firmware, overwriting memory.

Continue reading: JTAGulating JTAG!