Tag Archives: Netgear

I recently bricked a Netgear DG834G v3 by modifying the bootloader’s environment variables*. I purposefully set mtd1 to a bogus starting address (0x90120000), to see if ADAM2, unable to locate the OS, would drop me to the prompt. I did this because, with this particular modem, you cannot interrupt the boot process and talk to the bootloader; it always starts the OS. The result, however, was not what I expected. Upon rebooting the modem I received the following through my serial connection:

ADAM2 Revision 0.22.02
(C) Copyright 1996-2003 Texas Instruments Inc. All Rights Reserved.
(C) Copyright 2003 Telogy Networks, Inc.
memsize == 0x01000000
Usage: setmfreq [-d] [-s sys_freq, in MHz] [cpu_freq, in MHz]
maca                  00:1b:2f:78:bb:d2
macb                  00:1b:2f:78:bb:d3
memsize               0x01000000
flashsize             0x00400000
modetty0              115200,n,8,1,hw
modetty1              115200,n,8,1,hw
bootserport           tty0
cpufrequency          211968000
sysfrequency          105984000
bootloaderVersion     0.22.02
ProductID             DG834
HWRevision            Unknown
SerialNumber          none
prompt                ADAM2
firstfreeaddress      0x9401bd20
req_fullrate_freq     125000000
mtd0                  0x900d0000,0x903e0000
mtd1                  0x90120000,0x900d0000
mtd2                  0x90000000,0x90020000
mtd3                  0x903e0000,0x903f0000
mtd4                  0x903f0000,0x90400000
oam_lb_timeout        100
modulation            MMODE
autoload              0
autoload_timeout      45

ADAM2 > addr=90120000
File for wrong Endian!
gocommand even2
Copying download from b0017000 to b4020000

Then the process froze, with the power and check mark (√) leds blinking continuously. The modem was bricked.

Time to debrick

To recover from this state you need to connect to the modem through its JTAG interface. You can see the JTAG header pictured below.

The Netgear DG834G v3 board. You can see the JTAG interface top right. Note you will need to solder the header on the board.

The Netgear DG834G v3 board. You can see the JTAG interface top right. Note you will need to solder the header on the board.

According to this modem’s wiki page on OpenWrt (where you can also find another picture of the JTAG header, probably better than mine too), the interface’s pinout is as follows:

Pin # Function Function Pin #
9 TCK GND 10
11 nSRST KEY 12

This corresponds to MIPS EJTAG 2.5.

Assuming that your computer does not have a parallel port, to implement this connection you need a USB-to-JTAG adapter, such as the TUMPA. With modem and TUMPA powered off, make the following connections:

TUMPA DG834G Notes
Pin 5 Pin 3 TDI to TDI
Pin 7 Pin 7 TMS to TMS
Pin 9 Pin 9 TCK to TCK
Pin 13 Pin 5 TDO to TDO
Pin 4 Pin 4 GND to GND

Lastly download zJTAG from


What I want to do in my case is use zJTAG to grab the part of memory that holds the environment variables, save it on my computer, edit it with a hex editor to undo the change I made that bricked the router, and, finally, write it back to memory. (Of course there are other ways you can brick/debrick your router and not everyone will be in the same type of situation as me. For those other cases check this. Please note: I haven’t tried the other methods described there, so I can’t comment on them.)

Connect TUMPA (I suppose you have already installed its drivers) to your computer and power on the modem. Now, assuming you messed up the bootloader’s environment variables like I did, proceed as follows:

1. Run zJTAG to get the environment variables.

C:\zjtag 1.8>zjtag.exe -backup:custom /start:0x903f0000
              /length:0x10000 /window:0x90000000 /L1:3 /fc:030
              /nodma /LE

               zJTAG EJTAG Debrick Utility v1.8 RC3

Dev 0:
 Description=TIAO USB Multi-Protocol Adapter A
 Set I/O speed to 7500 KHz

USB TAP device has been initialized. Please confirm VREF signal
Press any key to continue... ONCE target board is powered on!

Detected IR chain length = 32

There are 1 device(s) in the JTAG chain
 IDCODE for device 1 is 0x0000100F (IR length:1)

Probing bus ... Done

Defined IR Length is 5 bits

CPU assumed running under LITTLE endian

CPU Chip ID: 00000000000000000001000000001111 (0x0000100F)
*** Found a TI manufactured TNETD7300GDU(AR7WRD) REV 01 CPU ***

    - EJTAG IMPCODE ....... : 01000001010000000100000000000000
    - EJTAG Version ....... : 2.6
    - EJTAG DMA Support ... : No
    - EJTAG Implementation flags: R4k DINTsup ASID_8 NoDMA MIPS32
    *** DMA Mode Forced Off ***

Issuing Processor / Peripheral Reset ... Done
Enabling Memory Writes ... Skipped
Halting Processor ...  ... Done
Clearing Watchdog ... Done
Loading CPU Configuration Code ... Skipped
*** Manually Selected a MX29LV320AB 2Mx16 BotB   (4MB) from Macronix

    - Flash Chip Window Start .... : 90000000
    - Flash Chip Window Length ... : 00400000
    - Selected Area Start ........ : 903F0000
    - Selected Area Length ....... : 00010000

*** You Selected to Backup the CUSTOM.BIN ***

Backup Routine Started

Saving CUSTOM.BIN.SAVED_20140130_223245 to Disk...
Done  (CUSTOM.BIN.SAVED_20140130_223245 saved to Disk OK)

bytes written: 65536
Backup Routine Complete
elapsed time: 121 seconds


C:\zjtag 1.8>

2. Open the file zJTAG just generated (CUSTOM.BIN.SAVED_X_Y) with a hex-editor.

3. Locate the bogus entry. In my case the offending line is located at 0xd80.

The mtd variable I modified, thus bricking the router.

The mtd variable I modified, thus bricking the modem.

4. Undo the changes you made. In my case I find that the original mtd1 value is still present at 0x900, so I can safely remove my entire new entry, by filling those bytes with ff. Save the file as custom.bin.

5. Write back the edited and corrected environment variables.

C:\zjtag 1.8>zjtag.exe -flash:custom.bin /start:0x903f0000
              /length:0x10000 /window:0x90000000 /L1:3 /fc:030
              /nodma /LE

6. Reboot the modem.

If all went well your modem should now be debricked. Congrats!

If you have any questions or if you spotted any errors or omissions, please leave me a comment.

* There are a few ways to modify the bootloader’s environment variables, even when you can’t get to the bootloader prompt. The variables are stored in /proc/sys/dev/adam2/environment and in /proc/ticfg/env. You can read and write either of those at runtime, once the OS has loaded, through your serial connection, or through telnet (provided you’ve enabled telnet first).

If you have any questions or if you spotted any errors or omissions, please leave me a comment.