Author Topic: Unable to access UART in WAP300N (Read 5819 times)

poncho7788 · « **on:** May 27, 2018, 12:47:27 pm »

I have a Linksys WAP300N access point that has been bricked just by changing the configuration to work in 5GHz. Apparently this is a known issue for a specific firmware version (https://community.linksys.com/t5/Access-Points/WAP300N-becomes-unresponsive-after-switch-to-5GHz/td-p/692471/page/5). As the device is out of warranty, the vendor does not provide any solution.
I would like to try to access the console of the device to check if there is any possibility of recovery, so I opened it and found what could be 4 UART pins in the PCB (see image).

I have used a multimeter to try to identify the pins with the following results:
Pin 1 (leftmost, the squared one), gives consistently a measure of 3.3v so it will probably be the Vcc
Pin 2 gives 0v so GND
Pin 3, gives a measure of about 3.29v for 25 seconds after the device is switched on, then drops to 1.01v
Pin 4, is always close to 0 (0.10v)

I thin that Pin 3 could be Tx giving some information during the boot sequence, but I have not been able to extract any information. The serial connection using a USB adaptor does not provide any data (nor even garbage), I have tried with the typical serial speeds.
I have also used a logical analyzer, but without results. I am stuck here, but I would like to keep trying, so any suggestion would be appreciated.

LateLesley · « **Reply #1 on:** May 27, 2018, 01:15:11 pm »

Can you take a picture, showing where the traces go? sometimes they lead to empty pads, which need resistors fitted before it'll communicate. I think they may be pull up resistors, but may be wrong. Sometimes they are in line with the signal, so probably protection of some sort.

tsman · « **Reply #2 on:** May 27, 2018, 04:55:45 pm »

What USB adapter did you use?

The two empty resistor pads nearby, are they connected to your UART header?

poncho7788 · « **Reply #3 on:** May 29, 2018, 07:34:28 am »

Thank you for your answers.

The traces from the suspected Tx and Rx pin seem to go to a bunch of pads (some used, some empty) with labels R375 and R120 (see picture). As you would have already imagined, I dont know a lot about this, could you please provide more info about why the pullups would be required?

I have used an Arduino UNO as explained in https://forum.arduino.cc/index.php?topic=138832.0 with a terminal emulator in my PC. Nothing. I have also connected directly the pins to the Tx and Rx of the Arduino getting always the same value (equivalent to a constant voltage I guess).

LateLesley · « **Reply #4 on:** May 29, 2018, 01:29:39 pm »

Many digital signal lines, work by pulling a line low via a transistor. Some chips have internal pull up resistors, but some require you to fit the resistor externally. I learned recently that it actually can take up a lot of die space on ICs to have internal resistors, so the chances are that ICs with more complex functions will use this space for it's different functions, and expect the circuit builder to fit external pull up resistors. For logic high signals, the voltage needs to come from somewhere! :-)

Anyway, I'm finding it quite hard from the picture to figure out where those tracks go, unfortunately the silkscreen seems to be hiding it a little, and they also seem to disappear into via's. Thats making it hard to see where they go. Sometimes they have pull ups, sometimes they have in-line resistors (I think for protection or current limiting. ) Untill we tell what type of resistors (or empty pads in this case) those lines are connected to, it's hard to give you a value to try. But a rough standard for pull up would be 10K, and in line maybe 1K. that would be 104 and 103 marked SMD resistors respectively.

I tried to find a datasheet to give us a clue, but I was unsuccessful in finding one.

Edit : I did find a datasheet for a Ralink RT3050, and it does seem on that at least that the uart wouldn't need a pullup. They also seem to be 5V tolerant, so I don't see the need for pull up resistors. SO it may have in line resistors, just to stop folk like us tapping into production models.

mrmuzzio · « **Reply #5 on:** May 04, 2021, 04:10:31 pm »

Hi !!! Did you managed to get some output from this device ?
I'm stuck with a bricked one, just like you... I've contacted Linksys support also...
Thank you !!!

dc101 · « **Reply #6 on:** May 04, 2021, 05:33:19 pm »

There's some good info here regarding your specific router: https://openwrt.org/toh/linksys/wap300n

The photo included lists pin 4 as TX and pin 3 as RX. If you've already tried that, it could be your Arduino that is causing issues. I use an Adafruit usb-uart adapter for 3.3V UART and the jim.sh Micro1v8 for 1.8V UART systems.

Also, in general you should check for ground using continuity mode and not by measuring voltage. On this board, I would probably check that there was continuity between the two RF connector housings, and then used one of those as a known ground point. On most 4 pin UART connectors the inner two pins are TX and RX, and the outer pins are VCC and GND.

Cheers
-Tim

mrmuzzio · « **Reply #7 on:** May 14, 2021, 01:00:36 pm »

I'm using a ttl to usb adapter, set for 3v. The adapter is working fine because I've tried it with other device.

I've also checked the ground connection and tried the 2 pins that seems to be tx and rx with no output.

I'm wondering if some pull-up or pull-down resistor may be needed for this uart to work.

As poncho7788 said before, it seems some resistors are missing in the board, the ones labeled R375 and R120. Each one have a pad going to ground and the other to RX or TX in the UART connector. From this I can guess they may be pull-down connections but i'm not shure.

Any help is welcome, thanks again !!!

dc101 · « **Reply #8 on:** May 14, 2021, 07:43:01 pm »

If you look at that link I listed in my previous post, there's a pretty good photo of the board. https://openwrt.org/_media/media/linksys/wap300n_serial.jpg?cache=

Those resistors are missing on that board as well, but the author did not seem to have trouble accessing the uart, so it would seem there is something else going on here. Also, UART is normally high during idle as you've seen on the RX pin, which I believe would be done with a pull-up resistor as opposed to a pull-down resistor.

If pin 4 is not being pulled high after powering on the AP, then you may have to resort to checking JTAG. It's possible the 1st or 2nd state bootloader was somehow corrupted and the device isn't even getting to the stage where it's outputting any data?

mrmuzzio · « **Reply #9 on:** May 14, 2021, 09:58:42 pm »

Thanks again !!!

I've looked at tha picture and you're right, those resistors are also missing.

That board is slightly different than mine, has a power switch and the product number is different, but I believe that the UART part should be the same.

I don't have a JTAG connector and I can't find the pinout for this board... I'll keep looking and will let you know.

Do you know where I can find the pinout ? Thanks in advance

dc101 · « **Reply #10 on:** May 14, 2021, 11:44:43 pm »

I would say J6, but usually MIPS is 14 pin so it's hard to say. You don't need all 14 for mips, but since there's only 10 pins it makes determining the pinout challenging. https://openwrt.org/docs/techref/hardware/port.jtag

You could try using a jtagulator, but they are pretty pricey and might as well just buy a new AP at that point, unless you really just want to have a go at repairing it.

Anything on the bottom of the board?

Cheers
-Tim

mrmuzzio · « **Reply #11 on:** May 16, 2021, 12:31:57 am »

Hi !

The bottom of the board has no labels, except for the board model.

Checking for continuity with a multimeter, I've mapped 4 of the pins to the nearby uart connector:

pin connection
2 + 3.3v
5 GND
7 uart TX
9 uart RX

I've tried this program : https://github.com/cyphunk/JTAGenum with a generic esp8266 esp12 board I had lying around.

I've connected the 6 unindentified pins to the esp8266 and run all the scans, trying different options: pulldown on/off, delays on/off

But I had no luck, the only thing that changed is that when I run the tests, the power led on the board stops flashing and the ethernet led flashes when the test is running. It's like the tests interrupts the power on and reboot loop that runs when it powers up.

I may run some more tests tomorrow but I'm starting to lose hope for this board.

Thanks a lot !

dc101 · « **Reply #12 on:** May 16, 2021, 01:12:28 am »

Unfortunately there just isn't a lot of information available for this board, it's possible the JTAG pins are not routed to anything on the board, or they are routed to various nondescript pads, or as you mentioned earlier some resistors are missing preventing JTAG from working.

On one device I looked at for work, we had downloaded a schematic that showed the JTAG pins were routed to pads on the board, but we could not find them. After putting the board in a 3D x-ray machine we finally discovered they were routed to the edge of the pcb. We believe these JTAG traces routed to a small stub PCB that was snapped off from the main PCB after programming and testing.

If this was something where money was no object and perhaps being done as part of a security assessment, the most likely next step would be to buy another device of the same type and remove the main processor. From there you would try to find a datasheet for the processor to identify the JTAG pins, once you've determined what pads on the board are connected to JTAG, you would begin probing the board in an attempt to discover where they route to. If you want to see what this process looks like I would recommend this series of videos on reverse engineering power meters I believe there's 4 videos in total. In one of his videos he demonstrates where he removed every component from the pcb just to get an understanding of where all the pads connected. It's a lot of effort and it's worth it certain cases. But if you're just trying to save $100 on a new WiFi AP, then it's probably overkill.

In theory it would be possible to remove the flash memory from the board, reprogram it and reinstall it, but unless you have a known good image to reprogram the flash with then that is not a realistic option.

LateLesley · « **Reply #13 on:** May 16, 2021, 01:17:41 am »

I've been trying to find a datasheet for that chip without success, I was hoping to see how the UART lines were wired up. In that hunt though, I did fall across this article, which may or may not be of help. So I thought I'd drop it in here for you to peruse.

https://www.cyberark.com/resources/threat-research-blog/accessing-and-dumping-firmware-through-uart

I also came across software for the RALINK AP chips, called RALINK AP SDK, it is worth googling.

Here, in this manual, you can find some settings for the UART ports, on page 101.

https://www.electrodragon.com/w/images/d/d0/MTK_APSoC_SDK_User_Manual.pdf

dc101 · « **Reply #14 on:** May 16, 2021, 01:38:16 am »

Yes, sadly it's still hard/impossible to get datasheets from vendors. Qualcomm/Atheros, Ambarella, Broadcom, Realtek etc...

Interesting, this is essentially what I had to do to fix my multimeter, except in my case it was u-boot.

Quote from: LateLesley on May 16, 2021, 01:17:41 am

I've been trying to find a datasheet for that chip without success, I was hoping to see how the UART lines were wired up. In that hunt though, I did fall across this article, which may or may not be of help. So I thought I'd drop it in here for you to peruse.

https://www.cyberark.com/resources/threat-research-blog/accessing-and-dumping-firmware-through-uart

I also came across software for the RALINK AP chips, called RALINK AP SDK, it is worth googling.

Here, in this manual, you can find some settings for the UART ports, on page 101.

https://www.electrodragon.com/w/images/d/d0/MTK_APSoC_SDK_User_Manual.pdf

mrmuzzio · « **Reply #15 on:** May 16, 2021, 02:55:05 pm »

Thank you both for the information, I've read that and from the SDK PDF I can see the uart defaults are 57600,8,n,1,n.

So I've tried that configuration, swapping rx-tx just in case and got nothing. I've also tried sending some data to the board to "wake up" the connection but that didn't work.

For me it's a personal challenge to see if I could rescue this board, but its starting to be harder of what I tought

I did found a firmware image for this at https://downloads.linksys.com/downloads/firmware/1224696816113/FW_WAP300N_v1.0.03.001_20141222.bin

But I don't know if its in the right format to directly write over the flash chip (datasheet: https://www.alldatasheet.com/datasheet-pdf/pdf/575487/MCNIX/MX25L6406EM2I12G.html)

This board has a 8-pin sop format with 8 pins so I think I could desolder it, solder over a protoboard and try to read it and then orverwrite it with the file downloaded from the linksys web.

I don't have a flash programmer but i've found this project https://github.com/ricardojlrufino/SerialFlashSPI that might work with my esp8266 e-12 wich runs at 3.3v

I'll give it a try and let you know !

Thanks !

dc101 · « **Reply #16 on:** May 16, 2021, 04:13:47 pm »

Sounds like a good plan. Take care that you write the firmware to the correct part of the flash. Usually the flash contains several different sections and not all are updated during the firmware update process (not included in the firmware image).

Here is an example of the firmware layout for an Hi3559 (a SoC designed for cameras)

1: flash part table 1.1 debug version | uboot | uImage | liteos | rootfs | paramfs | rawparam | paramdef | | 1M | 4M | 12M | 14M | 832K | 128K | 64K |

dc101 · « **Reply #17 on:** May 16, 2021, 04:28:34 pm »

It looks like the file just contains a Linux kernel with the u-boot header (uImage). The datasize of the kernel is 4488417 bytes, if you add in 64 bytes for the header then that comes out to the size of the entire file.

user@femto:~/re_projs/linksys$ mkimage -l FW_WAP300N_v1.0.03.001_20141222.bin
Image Name: Linux Kernel Image
Created: Mon Dec 22 01:23:12 2014
Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 4488417 Bytes = 4383.22 KiB = 4.28 MiB
Load Address: 80020000
Entry Point: 80023f30

user@femto:~/re_projs/linksys$ binwalk FW_WAP300N_v1.0.03.001_20141222.bin

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 uImage header, header size: 64 bytes, header CRC: 0x97CD3343, created: 2014-12-22 06:23:12, image size: 4488417 bytes, Data Address: 0x80020000, Entry Point: 0x80023F30, data CRC: 0xF9349363, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
64 0x40 LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 6740728 bytes
2703497 0x294089 LANCOM WWAN firmware

Quote from: mrmuzzio on May 16, 2021, 02:55:05 pm

Thank you both for the information, I've read that and from the SDK PDF I can see the uart defaults are 57600,8,n,1,n.

So I've tried that configuration, swapping rx-tx just in case and got nothing. I've also tried sending some data to the board to "wake up" the connection but that didn't work.

For me it's a personal challenge to see if I could rescue this board, but its starting to be harder of what I tought

I did found a firmware image for this at https://downloads.linksys.com/downloads/firmware/1224696816113/FW_WAP300N_v1.0.03.001_20141222.bin

But I don't know if its in the right format to directly write over the flash chip (datasheet: https://www.alldatasheet.com/datasheet-pdf/pdf/575487/MCNIX/MX25L6406EM2I12G.html)

This board has a 8-pin sop format with 8 pins so I think I could desolder it, solder over a protoboard and try to read it and then orverwrite it with the file downloaded from the linksys web.

I don't have a flash programmer but i've found this project https://github.com/ricardojlrufino/SerialFlashSPI that might work with my esp8266 e-12 wich runs at 3.3v

I'll give it a try and let you know !

Thanks !

mrmuzzio · « **Reply #18 on:** May 17, 2021, 07:25:26 pm »

Hi !!!

I've managed to desolder the chip, build a really nasty adapter board with things I had at hand, and read the chip contents.

It took almost a day to fix the reading circuit: some troubles with the power supply and the wiring. I got inconsistent reads at first, until i've found you have to keep the HOLD pin high for reading, at lest with this kind of chip.

And... this software flashser doesn't work with all arduino nanos, luckyly it worked with one of the lasts I've had for trying.

I've made 3 dumps of the file, binary compare them, and they are identical so I believe the dump this time is right.

I've also managed to get an older copy of the firmware from a driver site.

I'm attaching to this post some photos of my hardware setup for anyone that might find it of use, and the binwalk descriptions of the chip firmware and the ones I've downloaded.

I'm looking for clues of how to compare and analyze the 3 firmwares, and maybe make a new image to flash to the chip.

Any clues you may have would be great !!!

dc101 · « **Reply #19 on:** May 17, 2021, 10:17:59 pm »

That's pretty amazing! Awesome job!

Code: [Select]

binwalk chipfirmware2.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
84160         0x148C0         U-Boot version string, "U-Boot 1.1.3 (Nov 23 2012 - 12:00:39)"
327680        0x50000         uImage header, header size: 64 bytes, header CRC: 0x97CD3343, created: 2014-12-22 06:23:12, image size: 4488417 bytes, Data Address: 0x80020000, Entry Point: 0x80023F30, data CRC: 0xF9349363, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"

Based on your binwalk output, it appears that the firmware image from the website doesn't start until 0x50000 in the flash chip. You should be able to start writing the firmware to the flash chip at that offset. It's worth a shot.

What is concerning though is the possibility that something in the first 0x50000 bytes has been corrupted. Since the factory firmware image doesn't contain this data, the only way to fix it would be to find a copy of known good flash image, or by dumping the flash of a known good device.

mrmuzzio · « **Reply #20 on:** May 18, 2021, 02:37:12 am »

Thanks !!!!

I'll try to analyze the image further, maybe try to decompress the lzma section and compare it to some of the firmware versions I've found around.

I also found some nice strings linke ip addresses, SSID, user name, etc. at position 32000 of the image....

But since I got no uart output at boot I suspect the uboot section may be corrupted... and finding the full chip image it's been imposible...

Buying another device seems too pricey (in ebay around USD 25 plus another USD 50-60 for deliverying to my country)

I'll keep looking for a way to flash the uboot area or maybe fix it....

Thanks a lot for your help !!!

dc101 · « **Reply #21 on:** May 18, 2021, 09:22:20 am »

The lzma portions are just the compressed Linux kernel (zImage). You can uncompress them to check out the kernel, but they should be compressed in the flash as well.

You should check out vbindiff for Linux, it's a great binary comparison tool. It will highlight binary differences in red, but I think it's coolest feature is that you can adjust the top and bottom sections separately to "realign" the file if needed. Say a single byte was added to the file, in a normal diff tool that would throw everything off after that byte, but in vbindiff you can simply move the second file position by one byte and then continue the comparison.

mrmuzzio · « **Reply #22 on:** May 18, 2021, 11:24:49 am »

Yes ! you are right! But I must be looking for is an squashfs or something like that with the FS if it has one....

I'll look into vbindiff and let you know if I manage to work something out,

Thank you !

darkspr1te · « **Reply #23 on:** May 18, 2021, 11:37:34 am »

Quote from: mrmuzzio on May 18, 2021, 02:37:12 am

Thanks !!!!

I'll try to analyze the image further, maybe try to decompress the lzma section and compare it to some of the firmware versions I've found around.

I also found some nice strings linke ip addresses, SSID, user name, etc. at position 32000 of the image....

But since I got no uart output at boot I suspect the uboot section may be corrupted... and finding the full chip image it's been imposible...

Buying another device seems too pricey (in ebay around USD 25 plus another USD 50-60 for deliverying to my country)

I'll keep looking for a way to flash the uboot area or maybe fix it....

Thanks a lot for your help !!!

Are you able to share the dump please, i have built uboot for the rt68xx chips before and have a copy of the uboot for another similar device, i could compare the code and see whats damaged and possibly repair it.

darkspr1te

mrmuzzio · « **Reply #24 on:** May 18, 2021, 04:04:11 pm »

Hello !!!! Wow, that would be great...

I attaching to this post the dump I made. It's a ZIP flie splited un 3MB so it could fit in the attach limits.

Also, I have uploaded a copy to https://we.tl/t-cybuFVBIUD

Please let me know if you can decompresses it or if you need something else ! Thanks a lot !

dc101 · « **Reply #25 on:** May 18, 2021, 10:17:11 pm »

I wasn't able to get the multi-part zip to work, but I was able to check out the first 3MB.

It looks like the version of firmware on your flash matches FW_WAP300N_v1.0.03.001_20141222.bin, up until 0x344547 in the flash memory when everything in your flash dump is all 0xFF's. Not sure if that's an error in dumping the flash, or part of the problem.

mrmuzzio · « **Reply #26 on:** May 18, 2021, 11:46:01 pm »

Thank you for looking at the files !

Maybe you could try the link I posted... it will onlye last for a few days, but it has the whole file as a single ZIP, if you want to download it.

For the splited zip files you may need to remove the last ".zip" extension, and unzip with 7z.

Back to the firmware... I tryed the same comparison as you with the firmware "FW_WAP300N_v1.0.03.001_20141222.bin" and it matched 100% of the bytes, at least that part of the image is the same, and thats why I believe the problem may be at uboot or other part of the image.

I believe the difference you area seeying is related to the fact that the downloaded file is missing some bytes at the end.

I'm attaching my screen of the comparisson and a draft of my findings about the layout.

Thanks a loooooot !!!

Monkeh · « **Reply #27 on:** May 19, 2021, 02:03:42 am »

Quote from: dc101 on May 18, 2021, 10:17:11 pm

I was able to check out the first 3MB.

Quote

up until 0x344547 in the flash memory when everything in your flash dump is all 0xFF's.

Ahem. Yes, you ran out of file.

Quote from: mrmuzzio on May 18, 2021, 11:46:01 pm

a draft of my findings about the layout.

0x0 - 0x30000 is indeed uboot. 0x30000-0x40000 is some sort of simple config store, whether it holds default values or is updated in operation is hard to say. 0x40000 to 0x50000 contains factory cal for the radio - 0x4e000 is the ethernet MAC. The wifi MAC is at 0x48004. 0x4a0000 is likely a config store but I don't recognise the header. Blanking that would be an interesting experiment.

I'm wholly untalented in MIPS machine code so determining if u-boot is damaged is well beyond my pay grade - and, no offence, motivation for trying to recover such a badly abandoned piece of hardware.

dc101 · « **Reply #28 on:** May 19, 2021, 02:40:28 am »

It looks you like are correct, I expected a multi-part zip failure to just cause an abrupt end of file and not have it padded with 0xFF's, but perhaps that's an artifact of the way zip works?

I downloaded it from the other link you sent and it matches what you see, I will look closer at it tomorrow.

Quote from: mrmuzzio on May 18, 2021, 11:46:01 pm

I believe the difference you area seeying is related to the fact that the downloaded file is missing some bytes at the end.

I'm attaching my screen of the comparisson and a draft of my findings about the layout.

Thanks a loooooot !!!

mrmuzzio · « **Reply #29 on:** May 21, 2021, 07:58:39 pm »

Hi ! Thanks a lot for your input, I can confirm that the posittion 4e000 is the mac address, as it matches the label on the case... The other mac address seems to be right also, but it's not printed on the label.

For addresses 0x40000 to 0x50000.. what you mean by radio cal? is callibration data ?

The data at 4a0000 also got my attention, I'll try to overwrite that with FF to see what happens and I'll let you know.

I know this old hardarware is not worth the effort but I'll give it a try...

Thanks again!

dc101 · « **Reply #30 on:** May 22, 2021, 01:08:35 am »

Quote from: mrmuzzio on May 21, 2021, 07:58:39 pm

The data at 4a0000 also got my attention, I'll try to overwrite that with FF to see what happens and I'll let you know.

If there isn't code that is telling the processor to read instructions from that section of code, then there's no harm in leaving it there.

I looked at the u-boot code in a disassembler. It looks ok for the most part, although I was surprised to see it's little endian. Most MIPS processors are usually big endian, although there are a few notable exceptions like PIC and the (now defunct) MIPS Creator boards.

There were a few sections of the u-boot image that didn't look right though, it's hard to say without really looking into it if it's supposed to be data, or if it's actually garbage. I'm going to try and compile u-boot for an architecture that is hopefully close to the RT6856F processor and see what that looks like in the disassembler.

dc101 · « **Reply #31 on:** May 23, 2021, 03:02:50 am »

Well after a bit of searching I was able to find a Ralink fork of u-boot very close to what you dumped from your flash: https://github.com/swiftgeek/ralink-uboot

I'm not sure if this version is compatible with your board though, perhaps that is why your device is not working? It's for an RT6855A, not an RT6856. You would think it would be compatible, but perhaps something changed in the 56? After compiling the Ralink u-boot fork and learning of the base address, I was able to properly look at the file in IDA Pro and the image looks fine, everything looks intact and I didn't find any sections that were corrupt.

Do you have an oscilloscope or can you borrow one to check uart tx pin? It's possible the baud rate is different and it's only displaying one or two lines of text, which might be to quick for a meter to register any voltage. I saw a comment in u-boot that implied the default baud rate was 57600, have you tried that speed previously?

mrmuzzio · « **Reply #32 on:** May 23, 2021, 04:22:28 pm »

Hi! thanks a lot for your efforts!

I've made an adapter and solder it to the board so I could plug and unplug the flash chip easy.

Since the chip had the "v3" of the firmware, I tried flashing over the "v2" and "v4" and the same address ( 0x50000). The v2 behiaved the same as the v3, the same flashing pattern for the power led.

The v4 had more flashes, but after a few flashes, the ethernet led flashes for a split second and the pattern starts over.

I've tried the serial port again at 57600, no flow control with "putty" and also reversed the Tx and Rx pins just to be sure... tryed sending some keys like the enter key, but I had no output from the board.

I do have a "usbee AX pro" clone and I will plug it to try to capture data from the serial port and let you know. I'll try with this software: https://sigrok.org/wiki/PulseView

I will also make a video of the flashing leds to share and since the pattern changed, I'm thinking of connecting it again to a PC and use Wireshark to try to capture some packets....

Thanks again for your hard work with uboot! If that is ok... and changing the linux image firmware does not recover it... What else could be wrong? Some configuration that is not reset with a 30-30-30 reset ? ....

dc101 · « **Reply #33 on:** May 23, 2021, 06:05:03 pm »

Quote from: mrmuzzio on May 23, 2021, 04:22:28 pm

I will also make a video of the flashing leds to share and since the pattern changed, I'm thinking of connecting it again to a PC and use Wireshark to try to capture some packets....

Do you mean that the lights turn on and flash in different ways depending on which version of the firmware is written to 0x50000?

If that's the case, I would suspect u-boot is working.

Quote

The v4 had more flashes, but after a few flashes, the ethernet led flashes for a split second and the pattern starts over.
I will also make a video of the flashing leds to share and since the pattern changed, I'm thinking of connecting it again to a PC and use Wireshark to try to capture some packets....

Yes, that's an excellent idea. The ethernet port makes me wonder if u-boot is failing to load the image and then trying to load it via tftp.

This is from your u-boot:
bootcmd=tftp bootdelay=5 baudrate=57600 ethaddr="00:AA:BB:CC:DD:10" ipaddr=10.10.10.123 serverip=10.10.10.3

So if it is trying to load the image via tftp, you might see something coming from 10.10.10.123. Usually there is a user env that overrides the compiled defaults, but I haven't seen that in your flash dump

bootcmd=tftp

dc101 · « **Reply #34 on:** May 23, 2021, 06:54:18 pm »

Quote from: mrmuzzio on May 23, 2021, 04:22:28 pm

Thanks again for your hard work with uboot! If that is ok... and changing the linux image firmware does not recover it... What else could be wrong? Some configuration that is not reset with a 30-30-30 reset ? ....

If u-boot is actually loading the kernel and the device is still not working then I would say yes, most likely some sort of invalid configuration was set, or the drivers in that firmware version are buggy. When the device stopped working, how exactly did it happen? We're you upgrading the firmware, or just changed a setting in the menu?

On a related note, after looking closer at the Ralink APSoC SDK that LateLesley posted, it would seem that data you were mentioning at 0x4a0000 is most likely the compressed root filesystem. Although I haven't figured out how to decompress it yet.

Monkeh · « **Reply #35 on:** May 23, 2021, 07:11:47 pm »

That's too small to be the rootfs.

Considering the age of this device, the 'kernel' is way too huge to be just a kernel.

mrmuzzio · « **Reply #36 on:** May 23, 2021, 07:16:43 pm »

Thanks again !!!

My nephew tried to update the firmware, and after the update he lost access to the device... it seems he was updating from v2 to v3... from the files in his PC...

Looking at the memory layout you posted the config starts at 0x30000 but in my dump it starts at 0x32000... Maybe is out of place ?

I've tried the serial capture with no results other that my key presses (enter -> 0x0d) . At the start of the device it seems to send a "FE" packet. I'm attaching a zip file with the capture and some screenshots.

Serial.zip

Also, I did some tests with my notebook and wireshark.

1st Test : no protocols configured, router sends some ipv6 "router solicitation" from the MAC address printed on the label of the device.

2nd Test : ipv4, ipv6 configured with dhcp, with pings being sent to the ipv6 address of the router, wich the router replied some times !!!

Wich is really wierd, its seems that only ipv6 is working on this device !

And I'm attaching another zip with wireshark data...

Wireshark.zip

Finally, the video of the device leds with the v4 of the firmware... wich is the version I have now...

video of leds.zip

I'm really confused with this device... no Uart, no Jtag working, no ipv4 and now onlye some ipv6 packets ...

Do you think there is anything else to try ? maybe moving the config block from 0x32000 to 0x3000 to match the layout from the SDK ?

Thanks a lot for your help !!!

Monkeh · « **Reply #37 on:** May 23, 2021, 07:18:22 pm »

Don't take the SDK as gospel, you have no idea what version this firmware was developed from or what changes were made to it.

dc101 · « **Reply #38 on:** May 23, 2021, 08:27:02 pm »

I don't think ~4.5MB for a kernel is way too big, especially if initramfs included.

If you're seeing DHCP6 and can ping it, I would say it's at least getting u-boot. But that doesn't really solve the serial port issue.

If you were seeing your key presses in your serial log, then you were probing RX and not TX. You need to capture on pin 4 TX.

Without any console access it's hard to say what's happening. U-boot may be trying to load the Kernel from an incorrect address, or not even trying to load the Kernel, or the Kernel could be booting and then going into a panic for any number of reasons.

Curious to see what happens if you try setting your IP address to 10.10.10.3 and connect to the ethernet port on your device. Can you try that along with some wireshark captures?

It's possible the root filesystem was destroyed during the firmware update process. If the 3.5MB of flash space after the kernel really is supposed to be for the filesystem, then something is definitely not correct because there's only 11K of data in that entire area. Also, I would expect to see a signature for at least some form of compression, gzip, lzma, squashfs, but there's nothing there. Unfortunately the stock firmware updates only seem to include the kernel itself. I suppose the root filesystem could be stored someplace else, ie on a different flash device, but that's not very common.

I don't think the offset's are incorrect. Looking at the flash layout and comparing it to your flash dump it looks like a match. The problem I see is that you're missing u-boot parameters. 0x0 - 0x1000 should be uboot parameters, the environmental config I was talking about earlier. If these aren't present then uboot should fall back to whatever it was compiled with as far as I know. 0x1000-0x2000 is reserved, and 0x2000-0x6000 is the WLAN0 config, which looks like a match for what is in your flash dump.

The RF config looks like a match as well, however your flash dump seems to be missing RF 1 parameter, could that be part of the problem too?

True, things might not match the SDK exactly. We are looking at the manual for 4.3.0.0 and the u-boot version from your flash dump is from 4.0.1.0 so there have most likely been changes, but so far things seem to mostly correlate to what is in the SDK user's manual. It is true though that we are ignorant of any changes that Linksys might have made (patches, mods etc...) to the SDK when the firmware was built.

mrmuzzio · « **Reply #39 on:** May 23, 2021, 09:29:44 pm »

Thanks for the info...

About that serial monitoring, I'm seeing the keypresses because I'm capturing both RX (row 2) and TX (row 3). The RX goes from 0 to 1 when I power on the board, and stays that way.

Looking at the settings at 0x32000, seaching for some ipv4/ipv6 config I've found at 0x33247 an attribute "um_kernel_md5" that pointed to the md5 of the old bin file for the kernel... I've updated with the md5 of the v4 wich is the last I flashed.... and IT WORKED !!!!!

Fixing that parameter, out of pure luck, made this crap work again !!! It started flashing the power led as usual, but... it turned on the wifi led, and stayed that way... I plugged the ethernet cable with dhcp, got an IP and the web portal was running at 10.100.1.1 !!!

Thanks a lot to everyone who helped to solve this, I've learned a lot, and I got this board running again !!!

Serial port and Jtag still not working... but... the rest seems to be OK !!!

mrmuzzio · « **Reply #40 on:** May 23, 2021, 09:56:42 pm »

I'm attaching the photos of the "UGLY flash adapter board" and how its fits in the case....

mrmuzzio · « **Reply #41 on:** May 23, 2021, 10:07:38 pm »

And here I'm attaching the full dump of my flash, with firmware v 04.

It's zipped with 7z, just remove the last ".zip" extension from each file.

Thanks again to everyone who helped solving this !!!

dc101 · « **Reply #42 on:** May 23, 2021, 10:14:58 pm »

Awesome, that MD5 hash was a good find, nice job!

You can see now as Monkeh mentioned, that not everything will match the SDK. There are still so many questions, like where is the uboot config? Where's the root filesystem? It doesn't check according to the SDK documentation, yet your device still works. This is what makes reverse engineering challenging, and why I like it so much. It's the ultimate puzzle.

mrmuzzio · « **Reply #43 on:** May 23, 2021, 10:17:23 pm »

Second part of the firmware...

Monkeh · « **Reply #44 on:** May 23, 2021, 10:20:54 pm »

Quote from: dc101 on May 23, 2021, 08:27:02 pm

I don't think ~4.5MB for a kernel is way too big, especially if initramfs included.

The initramfs is the rootfs, that's my point. Kernel alone would never be that big for a 2.6 series. Any additional filesystem would be an overlay (which this could be, although it seems rather small and the header means nothing to me) or a custom config store.

I am also concerned there appears to be no u-boot environment. It's possible the block was erased during upgrade and never rewritten due to a firmware bug or a power failure.

Pre-post edit: Nice catch, I hadn't thought to check that checksum. Ahh, Linksys, you so special.

dc101 · « **Reply #45 on:** May 23, 2021, 10:29:58 pm »

These are cheap on eBay in the states ~$25 or so, so I placed an order for one.

Regarding the serial port, it's entirely possible Linksys just decided to compile uboot and the kernel without serial support?

That seems easier than spinning a new rev of the board with the uart lines disconnected/modified.

I will do some probing with my scope when the AP I ordered arrives.

dc101 · « **Reply #46 on:** May 23, 2021, 10:34:47 pm »

Quote from: mrmuzzio on May 23, 2021, 09:56:42 pm

I'm attaching the photos of the "UGLY flash adapter board" and how its fits in the case....

I hold on to a huge stash of old IDE cables for all my home stuff for this exact reason. If it's for work though, I use very small (30/32AWG) wire-wrap wire since they're paying for it

mrmuzzio · « **Reply #47 on:** May 23, 2021, 10:42:07 pm »

Yes !!! they are cheap and some time ago you could get a batch of 10 bricked devices for the same price. But, the shipping costs to my country are about 50-60 USD for one device....

I keep a bin of old IDE cables, pieces of CAT5 and some USB cables for this kind of ""quick prototyping"" ... the are indeed really useful...

mrmuzzio · « **Reply #48 on:** May 24, 2021, 12:34:24 am »

Just a tip... if you configure the operation mode to "Wireless Media Connector mode" the device will stop responding, even if you do first a "factory reset"

I've tried this with firmwares v4 and v6 and both have the same problem, the device will enter a boot-loop and will no start wifi....

Luckly I can take the flash chip out of the board and overwrite the settings at 0x32000 with the backup....

dc101 · « **Reply #49 on:** May 24, 2021, 12:58:14 am »

Quote from: mrmuzzio on May 24, 2021, 12:34:24 am

Just a tip... if you configure the operation mode to "Wireless Media Connector mode" the device will stop responding, even if you do first a "factory reset"

I've tried this with firmwares v4 and v6 and both have the same problem, the device will enter a boot-loop and will no start wifi....

Luckly I can take the flash chip out of the board and overwrite the settings at 0x32000 with the backup....

Do you know what the differences are? Can you post the config when it's in wireless media connector mode?

Luckily there are enough for sale in the US that most offer free shipping, so $25 total isn't a huge amount of money for a weekend of entertainment.

mrmuzzio · « **Reply #50 on:** May 24, 2021, 02:38:18 pm »

Hi... I'm attaching the settings in "readble format" in txt. You'll see there are some changes between the "factory settings" and "media connector mode"...

Another interesting thing is that the configuration block at 0x32000 starts with some binary data that looks like a CRC32... But I could not reproduce the values from the data.

madires · « **Reply #51 on:** May 24, 2021, 02:48:55 pm »

Some hints: https://openwrt.org/toh/linksys/wap300n

dc101 · « **Reply #52 on:** May 24, 2021, 03:48:32 pm »

Quote from: mrmuzzio on May 24, 2021, 02:38:18 pm

Hi... I'm attaching the settings in "readble format" in txt. You'll see there are some changes between the "factory settings" and "media connector mode"...

Another interesting thing is that the configuration block at 0x32000 starts with some binary data that looks like a CRC32... But I could not reproduce the values from the data.

It's the crc32 value in little endian for the wlan0 config section (0x2000-0x6000)

mrmuzzio · « **Reply #53 on:** May 24, 2021, 05:58:39 pm »

I can't get the same results as you... wich file did you take for input at the dd command ?

I mean, address 0x2000 is from the start of the whole flash dump or a subsection ?

Thanks a lot !

dc101 · « **Reply #54 on:** May 24, 2021, 07:43:18 pm »

I split up the main firmware image into their respective sections according to the SDK, with the exception of the kernel. For that I ended the section based on the size indicated by the uimage header + 64 bytes for the uimage header. And that size to the end of file made up the last section, whatever it actually is.

Code: [Select]

dd if=chipfirmware.bin bs=1 count=196608 of=1_bootloader.bin
dd if=chipfirmware.bin bs=1 skip=196608 count=65536 of=2_config.bin
dd if=chipfirmware.bin bs=1 skip=262144 count=65536 of=3_factory.bin
dd if=chipfirmware.bin bs=1 skip=327680 count=4488481 of=4_kernel.bin
dd if=chipfirmware.bin bs=1 skip=4816161 bs=1 of=5_rootfs.bin

-rw-rw-r--  1 user user  196608 May 23 13:47 1_bootloader.bin
-rw-rw-r--  1 user user   65536 May 23 13:48 2_config.bin
-rw-rw-r--  1 user user   65536 May 23 13:49 3_factory.bin
-rw-rw-r--  1 user user 4488481 May 23 14:45 4_kernel.bin
-rw-rw-r--  1 user user 3572447 May 23 14:27 5_rootfs.bin

Then I extracted the wlan0 config section minus 4 bytes for the crc (0x2004 - 0x6000) from the config data, and that is what i ran crc32 against.

Code: [Select]

dd if=2_config.bin bs=1 skip=8196 count=16380 of=config_blob.bin

mrmuzzio · « **Reply #55 on:** May 24, 2021, 09:53:05 pm »

Thanks ! I was missing the free space in my calcs...

mrmuzzio · « **Reply #56 on:** May 26, 2021, 09:22:00 pm »

Despite the device seems ok, of the four modes it has, only the AP mode is working.

With the other 3, when I change the mode and hit "save" the AP restarts and I can't go on with the configuration.

Been reading the user guide (https://downloads.linksys.com/downloads/userguide/WAP300N_UG_EN_3425-01640A_Web,0.pdf) and trying different settings but none seems to work...

Luckly the reset button is still functional, so you can return easy to the Factory Settings...

dc101 · « **Reply #57 on:** May 28, 2021, 01:04:48 am »

Well my WAP300N showed up today, it has firmware version 1.0.01. I hooked my scope up to pins 3 and 4 of the UART connector, both rise to 3.3V after powering on, but I didn't see any data going across either pin. I starting to lead towards they just compiled out terminal support in later revs of the board, which would be easier than modifying the board layout. This board is a different revision than the image on the openwrt wiki, my board number ends in a 2 as opposed to a 1. So far I've only noticed the power switch is missing in rev 2.

mrmuzzio · « **Reply #58 on:** May 28, 2021, 12:21:58 pm »

Hi! great news !!! my board is also missing the power switch, and I saw the same behaviour with the UART lines but my board does not have a revision number....

I'll be looking forward for your findings...

mrmuzzio · « **Reply #59 on:** May 28, 2021, 09:19:38 pm »

I was wondering if you tried the other modes of the router, besides AP ... since in my unit is the only one working...

Thanks!

dc101 · « **Reply #60 on:** May 28, 2021, 09:41:05 pm »

Quote from: mrmuzzio on May 28, 2021, 09:19:38 pm

I was wondering if you tried the other modes of the router, besides AP ... since in my unit is the only one working...

Thanks!

I tried access point, and media connector mode last night and both worked fine. I didn't try the other modes.

mrmuzzio · « **Reply #61 on:** May 28, 2021, 10:27:28 pm »

I've tried all modes, but the only one working is AP.

When I try the Media Connector mode, I factory-reset, set the mode and save.
Then I can not longer connect to the web interface to do the wireless survery...
It seems some settings are saved wrong .... I'll look into it again.

Thanks!

darkspr1te · « **Reply #62 on:** May 30, 2021, 07:21:48 am »

Quote from: mrmuzzio on May 26, 2021, 09:22:00 pm

Despite the device seems ok, of the four modes it has, only the AP mode is working.

With the other 3, when I change the mode and hit "save" the AP restarts and I can't go on with the configuration.

Been reading the user guide (https://downloads.linksys.com/downloads/userguide/WAP300N_UG_EN_3425-01640A_Web,0.pdf) and trying different settings but none seems to work...

Luckly the reset button is still functional, so you can return easy to the Factory Settings...

I see this often with random chinese wall wart repeaters, often you have to make sure you are on manual ip for you and the router via cable, then switch modes (media mode, repeater etc) , you should still be able to ping the unit.
as for uart, yes it could be disabled in uboot, how ever if you have ssh access you should be able to output to the uart if it's seen in /dev/
also hackaday has many router hacking articles from uart attacks to patching initrd and initramfs to patch in features and tools.

https://hackaday.com/2020/10/07/hacking-a-netgear-router/
https://hackaday.com/2011/10/20/ram-upgrade-for-wrt300n-router/

darkspr1te

dc101 · « **Reply #63 on:** May 30, 2021, 08:31:48 am »

That's a good point, I believe the IP scheme changes depending on what configuration you're in.

As far as SSH, no such luck. I ran an nmap scan as soon as I hooked up the AP and the only services I discovered was http and upnp. No ftp, telnet or ssh


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: Unable to access UART in WAP300N (Read 5819 times)

Share me