Ralink Uboot

[Catherine Nicolo]

HiI own a MT7688AN 128mb ram, with 16mb nor flash BY25Q128AS router like device that I managed to install openWRT on it (It's the ceality wifi box). However, after a failed sysupgrade it is now in a semi-bricked state, it is on a constant bootloop. While on serial connection I am able to see the u-boot banner and 5 options; option 4 being for entering u-boot CLI but I cannot access it no matter how fast I try to choose option 4 (I guess it's disabled buy the manufacturer). It boots right into openwrt but after a while it starts giving some errors then it panics and reboots.

I'm thinking to buy a ch341a programmer with soic 8 clip, read the chip, dump it, edit it to enable delay then write it back. After that use tftp to install a working openwrt bin file. I don't have a working full flash dump and this device is not at all documented on the internet.

I did how you told me: hold the reset button while booting and it started to countdown. Still I was not able to choose option 4 but instead of booting to flash it defaulted to an option 5 which was looking for a root_uImage on usb storage.

It might be worth it to check if Hardware Flow Control is on. I've had a few devices where U-boot wouldn't respond to commands over serial until I turned that off. So certainly worth checking next time you need serial.

I disabled that as well and still no feedback. I was able to enter failsafe though. But this happens after Linux booted so I guess the u-boot is somehow locked to receive input?

I guess only way left is to edit the hex flash dump if I really want uboot access?

Thanks!

I picked up an iReceiver, a cheap WiFi audio receiver that supports AirPlay and DNLA. It works with the stock firmware, but I want to get OpenWRT running on it so I can take care of some stupidity in the networking configuration, and so I can use shairport-sync, instead of a dated version of shairport.

Using the serial headers I found, I've obtained access to the UBoot console, and, once linux boots, gained access to a root shell, which led me to a telnet server and a hidden webpage that I can use to fire it up.

From here on, I'm going to proceed cautiously because the device doesn't have an ethernet port, making recovery from a botched firmware more difficult. I am planning on building firmware that enables WiFi by default.

It includes the loadb command to load an immage over serial using kermit, which I think should let me recover from a bad firmware version by loading a known-good version into over kermit and booting it. Unfortunately, it looks like loadb is/was broken in Ralink's u-boot.

both repos contains uboot 5.*.*.* and can build rt5350 image

but be careful with build settings, flashing wrong uboot image or image built with mistakes can cause bricking, only programmer will helps

With OpenWRT embedded systems like the LinkIt, there is almost always a serial port console allowing access to the bootloader and the root system. This allows developers to upgrade the firmware from a physical connection with the least amount of software. This is the starting point for all of my embedded system hacking, get the console and see what the system does.

I like to roll my own OpenWRT firmware, that way I have full control and I know what is installed in the system (no NSA or botnet backdoors!). Before getting in to building a custom OpenWRT image I like know that I can go back to the stock image if I really mess something up. Mediatek has a lot of information on how to upgrade the firmware on their Mediatek Labs website, so after some reading here is how you can flash a new image:

The uBoot USB based upgrade path is a little better. First you copy your image file to a FAT formatted USB drive and name it lks7688.img. Then you plug the drive in to an USB OTG cable connected to the USB data port. Hold the wifi button on the LinkIt and reset the device with the reset button. With the serial console connected you can see that uBoot detects the wifi button held down, and after 5 seconds it starts searching for a USB drive. What is interesting is that the console outputs:

If you look at the boot menu there is no option for 5, it jumps from 4 to 7. Rebooting without the wifi button pressed, and entering 5 into the uboot menu and the system drops in to the same USB update routine, so there are a few ways to start this upgrade.

Overall, I am quite impressed with the LinkIt Smart 7688, it is powerful, open, well documented, and cheap embedded system. The next steps are to create a footprint in Eagle PCB, make a few adapter boards for some hardware I have here, and then build a custom OpenWRT image. In a later post I will go over how to build and download OpenWRT, with support for the WiFi hardware on the LinkIt, to make a truly custom embedded Linux platform!

Apparently there are multiple revisions of MPR-A1 around, and mine was a bit different from the others I've been able to find on the internet. Mine had a layer of copper foil covering the PCB, I pealed it away to locate the RX/TX uart connections. Sadly, on my revision (2.2), the pads are covered with solder mask - I do not know if they are made this way now, or if mine was from a weird batch.

I sanded down the solder mask to reveal the copper pads, and soldered RX, TX and GND to a UART usb adapter (from an old nokia connector in my case). Be careful not to sand too much, the copper is pretty thin.

Next, make a serial connection, screen is pretty nice for this on a mac: screen /dev/tty.usbserial 57600 .. Power up the router and hold down '2' .. (uboot will give you some boot options, 2 = flash from tftp). Connect via ethernet to the router and follow the tftp instructions.

This device only has 16 mb of ram and would probably need a ram upgrade to be useful with openwrt. Running luci is insanely slow, so slow that it will drive most people mad. I would rather recommend the TP-Link TL-MR10U. It's a similar device in the same price range, basically a wr703n with battery - meaning atheros based and 32 mb ram. I didn't know about the TP-Link at the time when I bought this.

You can build your own SPI flash reader/writer with a Teensy and a chip clip. I am using the work of Trammell Hudson who gave an awesome talk at 31C3 on manipulating UEFI on MacBook Pros for fun and profit.

You can find a copy of the SPI dump of my device (firmware 1.05) here. You cannot flash this image without hardware tools as described above. If you flash this dump, your device will have the same MAC address as mine. This dump should be used only as an option of last resort.

Using dd, we can extract both Squashfs images from the firmware file. I used my dump, but actually I would recommend you just head over to D-Link's website and download the 1.06 firmware image [ZIP] and dump that instead. However, D-Link's firmware is missing the second Squashfs filesystem.

Run the 'ol unsquashfs on squashfs1.bin and squashfs2.bin, and you'll have the extracted filesystems of the squashfs images in my dump the firmware. Remember to rename the directory squashfs-root between runs, or specify unsquashfs -d with a different directory name to decompress the images into respective directories.

The second squashfs image is the D-Link recovery OS. This OS will boot if the first kernel fails the integrity check performed in uboot. Hilariously, it won't boot into the recovery environment if you flash a bad kernel to the device in Image 1 as I found out.

I must say that the inclusion of a recovery OS is an interesting move on D-Link's part. Since I don't buy their products normally, I'm not sure if other D-Link devices also have this recovery OS on them. It seems like a good idea to include on this device, since if a firmware update fails, since there are no Ethernet ports on the device it's not possible to recover via TFTP, as it would be on a normal router. The firmware update from D-Link's website only updates Image 1 squashfs and kernel. Image 2 on my device is firmware version 1.00, and the squashfs filesystem is smaller than the Image 1 OS.

If you do some maths on the mtd blocks, you will see that with the stock D-Link layout, the Image 1 kernel can only be 983040 bytes (0xF0000) large. Any larger, and the kernel will not fit in flash. The recovery kernel has to be even smaller, maximum 851968 bytes (0xD0000).

Since this device lacks Ethernet ports, it doesn't include some of the features one would consider necessary on a home router, such as port forwarding, firewall configuration, and the like. I suspect that not needing to include these features gave D-Link the space on flash to store a recovery OS. As you can see though, they did have to make some compromises in the allocation of flash to fit the main and recovery OS within 8MB. The device does not function as a WiFi repeater in the recovery OS, only allowing you to reflash a firmware.

Stay tuned for part 2 where I compile the D-Link GPL firmware from source and backdoor the device to allow shell access without a login (infosec is hard). If you've heard horror stories about GPL firmwares before, they're all true...

3a8082e126