Author Topic: Unable to access UART in WAP300N (Read 6635 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 !


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

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

Share me