bricked router [Buffalo wzr-1750dhp]

[pitfermi]

Hi,

I have an old buffalo router which was flashed with dd-wrt 2 years ago. It worked fine with the right firmware version. Recently I decided to upgrade/change my home network configuration, so I figured I'd flash the stock firmware from the manufacturer, for whatever reason I thought it would be a good idea, which turned out not to be.

Basically, I flashed the latest openWrt firmware, then found a beta Tomato(shibby) firmware Version for this router and decided to give it a go, see how the later performs. Upgrade was done via the web gui.
After the flash, the router would not turn on anymore, the power led would flash 2 times red and won't post/boot.

I then went ahead and took it apart, gaining access to the uart interface. Attached picture shows the main uart0 interface on the board. I have various ebay usb-ttl adapters, so I used a 3.3V one,  hooked it up according to attached picture taken from the dd wrt forum (https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=176310), and I got no readings on the Putty terminal. Thinking that the adapter might be broken, I grabbed another one(5 V logic data pins), same situation, no output on the TX pin of the router. I then found another post from someone who messed around with the serial interface (https://kdpeter.blogspot.com/2015/04/adding-serial-console-to-buffalo-air.html?m=1, where they mention that the serial data pin connection is the other way around..
Booting into CFE with 115200/8/1/n using the 3.3V dongle was no problem(did not try with the 5 V one again). I got lucky here apparently, the serial pins are 5V tolerant?

So inside CFE, I was able to verify that something was broken when it tried to boot, according to following message:

Code: [Select]

check_trx: start flash1.trx
Invalid boot block on disk
check_trx: exit flash1.trx
fw is broken
blinking led 2

Code: [Select]

show devices command yields the following list, based on what I remember. i regret not making screenshots..

Code: [Select]

uart0
uart1
flash0.boot
flash0.trx
flash0.os
flash0.nvram
flash1.boot
flash1.trx
flash1.nvram
eth0

So then I had to flash a firmware manually using a windows tftp client in order to get it back to boot. First ran tftp Put command on Pumpkin client then,
Flash commands I used:

Code: [Select]

flash -noheader : flash1.trx
flash -noheader : nflash1.trx
At this point, i was unsure if "nflash1" or "flash1" was correct, so I tried both(i know, my bad),
While/after flashing, i got error code -4. something with I/O being incorrect(reason why i kept trying to flash different firmwares). sorry, forgot to take screenshot.

Following I issued the below commands to clear nvram. Read it helps.

Code: [Select]

flash -erase nflash1.nvram
flash -erase nflash1.brcmnand
nvram erase


After that, I issued a reboot and the serial output of the router was no longer there. The TX pin on the usb adapter blinks, when I try to interrupt the boot with Ctrl + C, indicating that it can send data, sadly the input from RX is nonexistent. Power led on the front is not blinking, no white, no red, meaning it wont even start the bootloader(?). This is the point where I knew something was really wrong. From what I was told, the only option I'd have now is to program the onboard flash via jtag, starting with the bootloader? The 4 serial header Pins were already soldered, the (presumably) Jtag Interface is where i soldered the 14 header pins.

Regarding its pinout, check attached macro picture. The red shorted pins on the left represent(are connected to) the 2 pads on the left, where resistors are missing. yellow marked pins are grounded, i checked.
purple/pink pins are Vcc(3.3 V). The other pins measure infinite resistance/high impedance to either Vcc or Gnd. some of them are pulled high, some low when the router is in operation(less than 3.3 V). Sadly, I have no experience with jtag so I did not  try anything smart yet.

Things that I tried after this whole mess.
-spammed ctrl+c while booting, very rapidly, in case the bootloader does not output anything and hands over execution to the cpu, while the firmware is bad.. But i couldnt enter CFE.
-checked pins with an oscilloscope. only constant voltages on serial/jtag.
-trying the tftp "rescue" method described here: http://g300nh.blogspot.com/2010/06/firmware-flash-and-brick-recovery.html . No luck, File is not transferring, windows detects no device on port 1 of the router..

Firmware files that I recall flashing using CFE/TFTP(Tftpd64):
-wzr_1750dhp_ap_227 (oem firmware from buffalo.jp website)
-wzr1750dhpd-v24sp2-23709c.bin
-wzr1750dhpd-v24sp2-23709c_recover.enc

links that I used in the process:
https://kdpeter.blogspot.com/2015/04/adding-serial-console-to-buffalo-air.html?m=1
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=176310
https://openwrt.org/toh/buffalo/wzr-1750dhp
128M NAND Flash: https://zentel-europe.com/datasheets/A5U1GA341ATS(BF)_v1.4_Zentel.pdf

Right now i am out of ideas and would gladly avoid jtag programming, if possible.
Had no luck acquiring info for jtag/debricking from Buffalo, unfortunately, since I flashed dd wrt.(lol!)
How do I proceed? any suggestions/questions are welcome.

[pitfermi]

bump, can somebody give me a hand? any ideas please?

[dc101]

Yes, I would agree with you. If you erased a bunch of flash partitions and flashed a bunch of firmware, and now the serial console is no longer sending data, there is a good chance you took out the bootloader. This is not hard to do if you're following instructions that are not necessarily designed for the exact model device you own, or if the firmware you're flashing is designed for a slightly different model/version. A firmware file that's larger than expected, or flashed at the wrong base address can easily wipe an adjacent flash section. If you're able to locate a suitable bootloader, you might be able to recover your device by removing the nand flash and reflashing the bootloader/firmware.

[pitfermi]

Yes, I would agree with you. If you erased a bunch of flash partitions and flashed a bunch of firmware, and now the serial console is no longer sending data, there is a good chance you took out the bootloader. This is not hard to do if you're following instructions that are not necessarily designed for the exact model device you own, or if the firmware you're flashing is designed for a slightly different model/version. A firmware file that's larger than expected, or flashed at the wrong base address can easily wipe an adjacent flash section. If you're able to locate a suitable bootloader, you might be able to recover your device by removing the nand flash and reflashing the bootloader/firmware.

ugh, remove the  nand flash as in desolder it? i do have a hot air gun with variable temperature and soldering equipment with fine tips, but i would rather use jtag instead? maybe i should grab an old router to practice desoldering smd chips with my hot air gun.

[dc101]

ugh, remove the  nand flash as in desolder it? i do have a hot air gun with variable temperature and soldering equipment with fine tips, but i would rather use jtag instead? maybe i should grab an old router to practice desoldering smd chips with my hot air gun.

I'm not familiar with this device, so someone else feel free to jump in and correct me if I'm wrong... but to my knowledge only MIPS via EJTAG allows you to directly read/write to Flash devices via JTAG. For ARM devices, the most common method of dumping nand is to write flash new firmware for the ARM processor that will dump the nand flash for you. If the MCU is MIPS based, you may be in luck. If that's the case then check out this video

If I recall correctly, your nand is TSOP-48? There are some adapters that will allow you to dump it in place (without desoldering) but I'm not sure the price of everything required to read/reprogram would be worth it. Parallel nand/nor flash is not as simple and straight forward as SPI flash.

[pitfermi]

the cpu is arm based. the jtag looks like ejtag though, based on the pinout i have found. not sure about the flash package.

ugh, remove the  nand flash as in desolder it? i do have a hot air gun with variable temperature and soldering equipment with fine tips, but i would rather use jtag instead? maybe i should grab an old router to practice desoldering smd chips with my hot air gun.

I'm not familiar with this device, so someone else feel free to jump in and correct me if I'm wrong... but to my knowledge only MIPS via EJTAG allows you to directly read/write to Flash devices via JTAG. For ARM devices, the most common method of dumping nand is to write flash new firmware for the ARM processor that will dump the nand flash for you. If the MCU is MIPS based, you may be in luck. If that's the case then check out this video

If I recall correctly, your nand is TSOP-48? There are some adapters that will allow you to dump it in place (without desoldering) but I'm not sure the price of everything required to read/reprogram would be worth it. Parallel nand/nor flash is not as simple and straight forward as SPI flash.
[/quote]

[pitfermi]

here is a closeup of the apparently flash. i pealed off the sticker to check for markings but its blank. could not find any info using the sticker either.

based on the datasheet, flash is tsop 48.
marked as red on the picture? if that is the case, then its pretty doable to attach wires etc. i have managed smaller pins in the past. i was under the impression the flash was located above the cpu just like in the picture!
what is the component marked with yellow then? flash controller? ram?

[dc101]

It's really hard to say without decent pictures of the chips. Maybe try to hold the board at an angle so the light reflects differently? The yellow marked chip is not a nand controller, that job would be done in software using a suitable filesystem such as jffs2, yaffs, squashfs, ubifs etc... since it's near the RF isolated components it's probably related to their functions, could be DDR for buffering packets? 

[pitfermi]

i will check tomorrow under different angle, but im pretty sure theres nothing on it. could you check following reviews and tell me what you think which component is which?
https://www.smallnetbuilder.com/wireless/wireless-reviews/32208-buffalo-wzr-1750dhp-airstation-extreme-ac1750-gigabit-dual-band-wireless-router-reviewed
https://foxnetlab.com/index.php/16-reviews/98-buffalo-wzr-1750dhp

It's really hard to say without decent pictures of the chips. Maybe try hold the bold at an angle so the light reflects differently? The yellow marked chip is not a nand controller, that job would be done in software using a suitable filesystem such as jffs2, yaffs, squashfs, ubifs etc... since it's near the RF isolated components it's probably related to their functions, could be DDR for buffering packets? 

[pitfermi]

well, heres the flash on mine. Now to find the correct bootloader...

[pitfermi]

I have attached the bootloader, which someone on the dd-wrt forum shared. I flashed it at the address 0x0000 using this programmer, https://de.aliexpress.com/item/1005003021538241.html?gatewayAdapt=glo2deu

resoldered it, but all i am getting via serial is what the attached picture shows.. any ideas?

Yes, I would agree with you. If you erased a bunch of flash partitions and flashed a bunch of firmware, and now the serial console is no longer sending data, there is a good chance you took out the bootloader. This is not hard to do if you're following instructions that are not necessarily designed for the exact model device you own, or if the firmware you're flashing is designed for a slightly different model/version. A firmware file that's larger than expected, or flashed at the wrong base address can easily wipe an adjacent flash section. If you're able to locate a suitable bootloader, you might be able to recover your device by removing the nand flash and reflashing the bootloader/firmware.