Memelabs

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
# Buffalo WZR-D1800H - Truly unbricking!!!!

## Introduction

Many on-line references are just plain wrong about this device. Pinout was wrong, information about the JTAG was wrong. Information about memory architecture was wrong. No clarification about what the buttons was complete.

This page comes as a hopeful clarifications to many missing or wrong information on the web on how to unbrick this device.

## Prelude: How I broke my device: DD-WRT just plain wrong instructions.

DD-WRT has many places where some one can get the wrong idea of how to upgrade this device. Some problems:

- One page says: use the .bin file if upgrading from the web interface, other say the TRX file.
- One page said, go to the latest release for this particular device other pages said that only some particular releases were supported, or tested. (Not even the wording is clear)
- Some pages clearly tell you, that you can use TFTP if something breaks
- Also, during flashing, there is no clarification of the flashing process with respect to flashing time and what to expect during or after flashing. At some point I found something like: "better just wait 20minutes, for just in case situations"

### Specific errors I made:

- Probably used the wrong type of file (don't remember which one). I already had a 2013 dd-wrt firmware running and wanted to see if there was a newer release supporting 802.11 meshing.
- I did the web flashing and it seemed that like nothing happened. I think it literally rebooted and the release version was just the same old 2013 version. I just tried several times to flash the same binary.
- After the third trial, it bricked.

### How it bricked

- No pinging
- Only the "Buffalo banner" (From now on B-LED) LED turned on. This light actually has two lights: a red light and a white light. (from now on BR-LED and BW-LED respectively)
- When connecting an ethernet cable the respective Ethernet LED turned on and blinked (this was important to know there was something alive)
- When turning on, all LED turned for a short time and then only the BR-LED stayed on. This later proved to be important to know that the device was still alive.
- No pinging to no know IPs. I tried to have my Laptop with interfaces on three networks: 192.168.1.0/24, 192.168.11.0/24, 192.168.10.0/24 (UP .2 always for my laptop)
- Later I discovered that switching the device on, while holding the AOSS front button it pinged back from 192.168.11.1 for some seconds.
- I applied the 30/30/30. Did nothing
- I tried the TFTP methods (several tricks here). Nothing
- I tried connecting to the UART port (tried several tricks). Nothing
- I connected partially successfully to the JTAG. Couldn't use it to recover. Couldn't do much.
- I tried to use an available (CFE Collection project) CFE image of a similar device. Didn't work.

In the next sections I will describe what I tried and if you want to do yourself, you probably would like to try these things in this order. They more or less increase in complexity but also in possibility to success!

## What I tried to recover from bricked

### Factory Reset 30/30/30

I just must have to say that it did nothing.

After doing this I tried all the recovery methods: Pinging: nothing, TFTP recover: nothing, UART: nothing back, JTAG: not successful, several SPI ICs flashings: didn't matter.

### TFTP

- I tried the setting the fixed mac method with arp -s . I think this is useful to detect pings as early as possible but it didn't matter to be able to recover in my case. TFTP was just not working enough to be able to accept files.
- Tried to send to 11.1, 10.1, 1.1 ... nothing
- Tried with help of UART (another section). UART never worked (until the device was fixed)

### UART

- The given pinout in some of the few webpages I found was wrong. But I was always conecting me PC RX pin to both pins on the device just in case this was inverted on the references. And nothing
- Some forums commented about the existance of an empty resistor disconecting RX or TX line from the pin headers. But this wasn't the case. There was an empty component from, what at the time, seem to be TX. But the other pad was connected to Vcc. I connected a pull-up in case this was necessary: it did nothing.
- I tried Ctrl-C several times after turning it on. Also holding it during turn on. Nothing

### JTAG

- Everybody said that this always works! Not really.
- Tried connecting. I was never sure about the pinout of the connector. The board has a 10pin connector that looks very much like a JTAG thingy.
- At some point I was able to get a response. 

```
Info : JTAG tap: bcm4706.cpu tap/device found: 0x000c317f (mfg: 0x0bf (Broadcom), part: 0x00c3, ver: 0x0)
```

but this was possible only in irlen 32, what is apparently know as the Broadcom JTAG TAP controller and not the EJTAG MIPS Core space. Which is the real processor.

- The idea of using the JTAG controller in the first place is to reflash the NAND device. But also then the SPI Flash. Given the state of my bricking, and that it is typical for the CFE to be inside the SPI flash instead of the NAND flash, this was the correct course of action: flash the SPI. I was just not able to get passed of the detection of the Broadcom chip. Anything extra I did, put the chip into a halt mode and stoped answering to the JTAG interface completely. This was notorious for turning all the LEDs on the device completely off.
- The problem was that apparently for this device and it is maybe common with broadcom chips, it starts in a 32 bit JTAG Tap mode, called the Broadcom TAP. One has to pass over this mode into 5bit mode to be able to actually talk to the MIPS core.
- For this I tried the following:

** NAND and SPI flash shorting **

- I tried the NAND shorting technic of shorting the ALE, WR, IOs ADx pins to ground. It did nothing to the JTAG communication. It still only worked in the 32 bit mode and the crashed when trying to do anything on it.
- During this time I discover there was a SPI 8pin flash at the other side of the board. An MX25L4006E. I also tried shorting some of pins (Clk and SO). Same result.
- The last thing I wanted to try was to load the CFE onto RAM and execute directly from there. This was also not possible while working on the JTAG 32 bit mode.
- More ahead, I disoldered the SPI IC and tried the JTAG connection again and it did nothing to the situation.
- During this time I also tried pressing Reset and other buttons during power up to see of the changed some working mode on the processor. I discovered that pressing and holding AOSS during turn on. Produced pings from 11.1 but nothing else was possible: TFTP didn't work JTAG didn't improve, UART showed nothing.
- During the next section I also flashed several SPI binaries producing different behaviors on the LED lights, and non allowed to change to 5bit mode.

### Re-flashing the SPI
- The last resort. And everybody said it should work. But, there is a problem: you need a donor image. I couldn't find a donor image for exactl this device available on the web. The most similar one I found was for an Asus_RT-N66U-B1 also with a broadcom BCM4706 SoC device. The network devices were different. And this could be a problem. Later after many trials I asked with private messages directly to particular people on the dd-wrt forum and one nice Adrian answered. He sent me an image of the CFE for the exact same device. Just with one detail. For privacy and security concerns he sent me the file with the MAC addresses and other details edited. Which I totally understand. The problem: the checksums.
- One of the first things I did was to get the SPI IC detected. The detection was not stable. But I was able to make a backup like this of my SPI IC. This I discovered possibly had reading corruption.
- Later I discovered that reading twice from the SPI IC gave different results. Reason: noise on the lines, solution: 0.1uF capacitor between Vcc and GND on the IC breakout board I used and increase the SPI programming speed. Lowering speeds actually increased errors! I found a nice behavior at 10kHz SPI reading and writing. I tested this by reading multiple times from the IC and comparing md5sums between reads. Must consistently read fine! Then I did a complete erase before doing the final write. And then after writing another reading and comparing to the original file. But unfortunately I discover this problem after I had programmed the IC once. I only had a backup from when I still had data corruption during reading. Fortunately, this backup binary was not corrupted enought to case a Checksum error on the first NVRAM space. (this I guessed later)
- During my searchs and in this case with the assistance of AI search assist I was able to get to some ideas of how to calculate the CRC. AI made a lot of wrong assumptions, hallucinated a lot of times, incorrectly extrapolate a lot. It gave different answers for almost the same questions in different days. Until it finally helped me find the correct answer together with my own hex editing examination tools, the three different CFE files I had and the different behaviors I was getting. 

### This was the final solution:

1. Using a raspberry pi zero w as an SPI IC flasher: do a backup of the original SPI. Important for getting the MAC addresses and for corroborating that the CRC calculation was correct. This wasn't perfect: the reading of this backup was possibly corrupted.
2. Use the donor CFE binary but:
- Adjust all the MAC addresses using the original backup from my SPI.
- Adjust the pin or secret according to the label on the product
- Check that all the wireless power configurations and other calibration details were correct. I didn't need to adjust any. 
- Recalculate the checksum field. This was an special CRC8 checksum using polinomial 0x9B LSB-reflected to 0xAB with inverted shifting. I had a lot of problems to get the right calculation.

### The CRC problem

- There are many CRC variants: 32, 16, 8 bit, and for each of this you can use a lot of different polinomials and initial values. They more or less are standard or known.
- The CRC used in this case for broadcom was not standard. Also broadcom used different algorithms depending on the particular SoC.
- First clue: the layout of the flash data. In particular the header of the NVRAM area. In particular, some broadcoms had a 32bit space for the checksum. But mine always had 0x00 0x00 in the MSBs. I could check this because I had 3 different CFEs (two from buffalo and one from Asus). The other MSB had always a 0x01, and finally the LSB was the one changing. AI initially suggested a normal XOR calculation which was wrong. Then it suggested a crc8 variant and incorrectly suggested a particilar known one. I had to finally search for the source files from broadcom, identify which ones were the most related ones (router NVRAM tools, checking tools in kernel sources etc) and finally inspect in detail the calculation. I ask accordingly to AI to give snippets of this to make a program to calculate them. It wrongly programmed the functions. I had to finally print the table to be able to compare it against the broadcom original one to finally make the corrections and finally I could check, only against one CFE image: my backup, that it was correct. The other CFE images had the MAC adddresses modified and I didn't know the original values. Then checksums couldn't be used for checking. The I applied this calculation to the Buffalo donor CFE file to each of the four NVRAM copies, and it worked! The device not only started to blink the LEDs differently, but it actually responded to pings at 192.168.1.1 but also the web interface responded with dd-wrt again and everything was up and running like before! 

## Detailed information of the Buffalo WZR-D1800h for unbricking and hacking

### Real UART Pin-out (checked!):

1. Vcc (checked)
2. GND (checked)
3. TX (output from the device) (checked)
4. RX (send signals here) (checked)

The device has an empty pair or tiny pads near the RX pin. One pad connects to RX and the other to Vcc. One could put a pull-up resistor there. I did and it didn't change anything. I later removed it. Now that the device is unbricked, TX and RX work without anything on these pads. Don't solder anything: it is not necessary!

### Shorting NAND or SPI IC:

- Does nothing. Don't do it.

### Pressing AOSS during booting:

- Makes ping to respond on 192.168.11.1. It may work for getting the TFTP working with you. You should try this method before even trying UART

### JTAG

- Responds to 0x000c317f in 32bit mode but this is limited TAP device that as soon as you try anything on it, it crashes the JTAG
- I couldn't find a method to switch to 5bit mode for communicating with the MIPS core. I tried many things: shorting NAND/SPI flahes, pressing buttons during turning on, Tricks on openocd to do early starts, delayed transitions to 5bit mode, and many things. 
- I would not recommend to try this. Soldering the connector is a pain in the ass. The connected is previously full of solder and it takes a lot of patience to remove/clean the solder before soldering a connector on the holes. I was not worth it. It is easier to desolder the SPI IC.
- Once the device was unbricked, I still was not able to switch to 5bit mode.

### CFE binary layout

```
0x000000 -> 0x0003FF: CFE initialization code (very important to be not corrupted)
0x000400 -> 0x000A07: NVRAM_1: First factory NVRAM space (mostly sure)
0x050000 -> 0x0570E7: NVRAM_2: First main NVRAM space (guess)
0x070000 -> 0x077FFF: NVRAM_3: Second factory NVRAM space (guess)
0x078000 -> 0x078687: NVRAM_4: Second main NVRAM space (guess)
```

** one NVRAM layout **
```
0x0000 32bits: MAGIC Key: FLSH
0x0004 32bits: Length: length of whole NVRAM block
0x0005 1byte: Checksum (calculated from 0x0006 till the section end)
0x0006 1byte: version: 0x01
0x0007 2bytes: Flags: 0x0000
0x0008 -> end of section: Data
Data: key=value ending with \00
Data section ends with \00\00
```

```
CFE> show devices
Device Name          Description
-------------------  ---------------------------------------------------------
uart0                NS16550 UART at 0x18000300
uart1                NS16550 UART at 0x18000400
flash0               ST Serial flash size 512KB
flash0.boot          ST Serial flash offset 00000000 size 256KB
flash0.trx           ST Serial flash offset 00040000 size 1KB
flash0.os            ST Serial flash offset 0004001C size 224KB
flash0.nvram         ST Serial flash offset 00078000 size 32KB
flash1.boot          ST Serial flash offset 00000000 size 256KB
flash1.trx           ST Serial flash offset 00040000 size 224KB
flash1.nvram         ST Serial flash offset 00078000 size 32KB
nflash0.trx          Samsung NAND flash offset 00000000 size 1KB
nflash0.os           Samsung NAND flash offset 0000001C size 131072KB
nflash1.trx          Samsung NAND flash offset 00000000 size 121856KB
nflash1.brcmnand     Samsung NAND flash offset 07700000 size 9216KB
eth0                 Broadcom BCM47XX 10/100/1000 Mbps Ethernet Controller
*** command status = 0
```

```
CFE> show clocks
Current clocks: 600/300/150/25 Mhz.


CFE> show pci
PCI bus 0 slot 0/0: vendor 0x14e4 product 0x0800 (flash memory, rev 0x01)
PCI bus 0 slot 1/0: vendor 0x14e4 product 0x4715 (ethernet network, rev 0x01)
PCI bus 0 slot 4/0: vendor 0x14e4 product 0x471a (USB serial bus, interface 0x10, rev 0x0)
PCI bus 0 slot 4/1: vendor 0x14e4 product 0x471a (USB serial bus, interface 0x20, rev 0x0)
PCI bus 0 slot 5/0: vendor 0x14e4 product 0x0820 (PCI bridge, rev 0x01)
PCI bus 0 slot 6/0: vendor 0x14e4 product 0x0820 (PCI bridge, rev 0x01)
PCI bus 0 slot 7/0: vendor 0x14e4 product 0x052e (undefined subclass 0xff, interface 0xff)
PCI bus 0 slot 8/0: vendor 0x14e4 product 0x080e (RAM memory, rev 0x01)
PCI bus 0 slot 9/0: vendor 0x14e4 product 0x0534 (undefined subclass 0xff, interface 0xff)
*** command status = 0

CFE> show memory
Range Start  Range End    Range Size     Description
------------ ------------ -------------- --------------------
000000000000-000006FFFFFF (000007000000) DRAM (available)
000007165000-000007FFFFFF (000000E9B000) DRAM (available)

CFE> nvram getall
DEF-p_wireless_eth1_11a-crypto=aes
DEF-p_wireless_eth2_11bg-crypto=aes
boardrev=0x1204
et0macaddr=10-6F-3F-16-17-76
4331_cckbw20ul2gpo=0x3333
boot_wait=off
watchdog=3000
et0mdcport=0
43a2_mcsbw805glpo=0x00000000
hw_rev=0
reset_gpio=5
pmon_ver=CFE 6.30.15-1.04
vlan2ports=0 8
43a2_mcsbw805ghpo=0x11111111
gpio4=robo_reset
sromrev=8
boardtype=0xf52e
43a2_mcsbw405glpo=0x00000000
4331_cckbw202gpo=0x3333
lan_netmask=255.255.255.0
43a2_mcsbw405ghpo=0x33333333
nvram_version=1.00
region=US
vlan2hwname=et0
pmon_date=Tue Apr 24 09:04:01 JST 2012
DEF-p_wireless_eth1_11a-authmode=psk
xtalfreq=25000
boardflags2=0x0
DEF-p_wireless_eth1_11a-wpapsk=u3h5nykr5a4nj
wait_time=3
DEF-p_wireless_eth2_11bg-wpapsk=u3h5nykr5a4nj
melco_id=RD_BB11119
wl_dmatxctl=0x24c0040
43a2_maxp5ga0=40,100,100,66
43a2_maxp5ga1=40,100,100,66
43a2_maxp5ga2=40,100,100,66
wl_dmarxctl=0x24c0000
4331_mcsbw20ul2gpo=0x11111111
clkfreq=600,300,150
lan_ipaddr=192.168.11.1
vlan1hwname=et0
DEF-p_wireless_eth2_11bg-authmode=psk
sdram_config=0x0105
vlan1ports=1 2 3 4 8*
boardflags=0x110
wandevs=vlan2
DEF-p_wireless_eth1_11a-authmode_ex=wpa2-psk
sdram_refresh=0x0000
sdram_ncdl=0x00000000
4331_mcs32po=0x0002
pincode=62456838
product=WZR-D1800H
DEF-p_wireless_eth2_11bg-authmode_ex=wpa2-psk
43a2_mcsbw205glpo=0x00000000
et0phyaddr=30
wl_pcie_mrrs=128
landevs=vlan1 wl0 wl1
4331_maxp2ga0=52
4331_maxp2ga1=52
4331_maxp2ga2=52
43a2_mcsbw205ghpo=0x00000000
4331_legofdmbw20ul2gpo=0x11111111
43a2_mcsbw1605glpo=0x00000000
sdram_init=0x0000
43a2_mcsbw1605ghpo=0x00000000
4331_legofdmbw202gpo=0x11111111
4331_mcsbw402gpo=0x88888888
custom_id=0
boardnum=00
4331_mcsbw202gpo=0x11111111
bootflags=1
size: 1668 bytes (31100 left)
```

### NAND details:

No idea. I didn't have to get to this

## Resources

- Minicom.cap: capture from the UART booting process (once it was unbricked and upgraded to revision r53130
- My CFE (emailme)
- patch_all2.py: Script to calculate and fix CRC8 checksums
- wzr_recovery7.cfg: openocd config file (5% successful)

## References

https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324862

Real hndcrc8 table: https://github.com/spotify/linux/blob/master/drivers/staging/brcm80211/util/bcmutils.c#L570
https://git.wut.ee/qi-hardware/openwrt-xburst/src/commit/843274aa37f00bacea2b88c03525c8d6564a54c7/package/nvram/src/crc.c
https://github.com/GetOcean/ocean-os-drivers/blob/45785ee9d212973039d1e993043873bc81922106/ap6210.drivers/bcmutils.c#L1369
https://github.com/Coool/Broadcom-CFE/blob/cb59f58fdfdd849430cb59258f960b4da7ebef69/cfe/main/bcmnvram.c#L231

HndCRC8 used: https://git.wut.ee/qi-hardware/openwrt-xburst/src/commit/843274aa37f00bacea2b88c03525c8d6564a54c7/package/nvram/src/nvram.c


NVRAM_CRC_START_POSITION: https://git.wut.ee/qi-hardware/openwrt-xburst/src/commit/843274aa37f00bacea2b88c03525c8d6564a54c7/package/nvram/src/nvram.h

General Info:
https://deviwiki.com/wiki/Buffalo_WZR-D1800H
https://wiki.dd-wrt.com/wiki/Buffalo_WZR-D1800H


dd-wrt downloads:

https://github.com/Coool/Broadcom-CFE/blob/cb59f58fdfdd849430cb59258f960b4da7ebef69/cfe/main/bcmnvram.c#L231


dd-wrt recommended downloads (according to webpage): Danger!!! Warning!!!. This was probably the reason I bricked my device. The webupgrade points to a bin file, and the factory flash points to a trx. It is the other way around!
https://dd-wrt.com/support/router-database/?model=WZR-D1800H%20(AC1750)_-