Mi Router 4A Gigabit Edition stuck in initramfs mode

Model: R4A

Well, I took the file that was on my Desktop because I (successfully) flashed another Xiaomi 4A Gigabit Edition some weeks ago but I renamed it openwrt.bin at that time so maybe there was my fault. From the filesize I recon it was not the squashfs file and then the trouble began. (trying to fix it the whole day)

The good thing is, whatever I tried for the last 12h it didn't get worse at least. OpenWrt starts every time but in recovery mode only. The device connects properly to the internet as soon as I connect the WAN cable. Sure it has forgotten all the settings I made after a boot.
I tried via WebUI-Flash-image and via sysupgrade when connected via ssh without any visible effect, so I am stuck on OpenWrt 22.03.2 (initramfs) I just have no idea what else I could try ...

An initramfs implies booting from RAM, that needs to be fed to the device in some way. It sounds like your device is just getting stuck in cold boot, which would suggest it's not finding the rootfs?

Can you pastebin dmesg output? If you can SSH in you can copy things over.

Sure thing, here you go: https://pastebin.com/uzEbuYYG

1 Like

:thinking:

[    4.307592] spi-mt7621 1e000b00.spi: sys_freq: 220000000
[    4.314423] spi-nor spi0.0: unrecognized JEDEC id bytes: 1c 71 18 1c 71 18
[    4.321311] spi-nor: probe of spi0.0 failed with error -2

You should thank yourself that you flashed the initramfs version of OpenWrt, so you can login after boot instead a bootloop! :upside_down_face:

By the way, you are hit by issue 9442:

Which was fixed on master then backported to 22.03 (released as 22.03.3) and to 21.02 but the latter isn't released yet, so you have to use 21.02-SNAPSHOT builds if you need to stick to that oldstable release!

1 Like

I see two solution only:

  1. serial access to your router, and
    • boot an OpenWrt SNAPSHOT or 22.03.03 of initramfs.bin through TFTP
    • do a simple sysupgrade with the same version of OpenWrt but now with a sysupgrade.bin
    • changing bootloader to a third party bootloader (at least for temporary)
    • flashing the correct version of OpenWrt
    • (optional) rollback to current bootloader
    • (if you mess up something you only way is #2)
  2. reprogramming your flash with an SPI programmer

Ok, there could be a third solution, but it depends on the bootloader your device has:
If it does support your CF EON flash chip you could use it's recovery function:

  • OEM booloader (an U-Boot) supports TFTP recovery, but accepts only stock firmwares
    • I have no access to a stock firmware which contains an U-Boot which supports this new chip and it's TFTP recovery isn't bugged! :see_no_evil:
  • BREED bootloader (third party BL, use the breed-mt7621-pbr-m1.bin edition) has nice HTTP GUI for recovery
    • newer versions support your flash chip
  • updated U-Boot by @db260179 (you should self-build it for now), it also has a nice HTTP GUI for recovery
    • the support was committed to the repository but no new release was made

Oh no ... I was hoping not to climb down so deep into the rabbit hole, but what the heck, it's fun right? So I have a serial adapter at hand, but no spi programmer. (which I am willing to order if neccessary)
Even though the device is brand new and I could just send it back, but nope thats not me ... I won't give up that easy! Btw. thanks everbody for all your help, really apprecite it. :slight_smile:

Given my USB zu TTL Seriell Adapter is there anything usefull I could try before ordering an spi programmer? How do I convince my device to boot the initramfs.bin you mentioned? Usefull tools (Linux/Windows doen't matter) for that task? Does the present bootloader give me an option to do that? Sorry for asking basic stuff, but I do consider myself in the group of beginners ...

Before attempting the flashing bootloader, connect the serial adaptor to your router board.

Get a serial program running like putty, then connect up, turn on router and if u can capture the putty output to a log file for us to see.

If you did the openwrt invasion part correctly, u should be able to hit enter to set u-boot commands, if not - 1. reflash the oem firmware back or 2. spi programmer read the flash chip (sometimes works, sometimes doesnt without removing the chip from the board)

My gitlab https://gitlab.com/db260179/openwrt-base/-/tree/openwrt-22.03-mt7621 has folder called docker, in there is a docker container that can boot images as its a TFTP,dhcp and dns all in one server. You will need to get your own oem firmware as your board has the new EON chips my example firmware has only support for the GIGA flash chips.

Did you do this part when doing the openwrtinvasion part?

nvram set uart_en=1
nvram set boot_wait=on
nvram set boot_delay=5
nvram commit

if not, you will need reflash to oem firmware and do the hack again, making sure you do the above part so you can enter the u-boot command line from the serial console aka putty

1 Like

Use the wiki to learn how to open the case, but you need to peel off the product label to unhide the screws.

Okay, device opened an here is a picture and the pastebin link: https://pastebin.com/N8GJm94u

Do I have to order the spi programmer yay or nay?

Press (and hold) 4 when / before the menu shows up:

Please choose the operation:
   1: Load system code to SDRAM via TFTP.
   2: Load system code then write to Flash via TFTP.
   3: Boot system code via Flash (default).
   4: Entr boot command line interface.
   7: Load Boot Loader code then write to Flash via Serial.
   9: Load Boot Loader code then write to Flash via TFTP.

If you are able to enter the U-Boot prompt, then help or ? to get help.
If you are unable to enter the U-Boot prompt, then you missed the serial access parameters setup, see below:

You could set those params from OpenWrt too with fw_setenv. Ahhh!!! fw_setenv won't work as the flash is unkown currently. :frowning:

1 Like

Hm ... not sure. I am at the console (root@OpenWrt:/#) after 10 seconds or so.
You are right: /bin/ash: fw_setenv: not found

I executed that script: remote_command_execution_vulnerability.py
during the process 2 days ago. That did not set those variables, right?

If you have previously modified the bootloader to have a bootdelay, then recovery by serial is possible.

It can't be modified now since the OpenWrt that is loaded can't access the flash chip at all.

As shipped from Xiaomi, the serial bootloader menu is inaccessible since bootdelay is set to zero. The only way to recover that is by writing direct to the flash chip with a SPI programmer.

Arriving tomorrow ... That should do the trick, right?

3 Likes

Yup! :+1:

Read the flash multiple times, do checksums and continue if they are the same!
Then take a copy of it and copy the sysupgrade.bin into it, skipping the first 0x00180000 bytes, e.g. with dd:

cp full16MBdump.bin full16MBdump-copy01.bin
dd if=openwrt-22.03.3-sysupgrade.bin bs=1536k skip=1 conv=notrunc of=full16MBdump-copy01.bin`
1 Like

Oh ha ... the adventure continues and even more to learn here. :slight_smile: I will definitely need help on this because this is the first time for me to practise things like that. I'm more familiar with programming ESP32s and stuff, so new territory here ... Anyway, I will let you all know as soon as I have the SPI. This thread could be helpful for many users btw.

Okay, Jeff B. has delivered. :slight_smile: Connected after watching numerous yt-videos. First, second and third readout are all identical files. Everything done under Windows10. Now trying to insert sysupgrade.bin (22.03.3) with HxD. Stay tuned ...

1 Like

IT WORKED GUYS IT WORKED!!! I'am not stuck anymore. Good job everbody, for coaching me through all this. What a journey. Looking back it was easy, but some sidenotes here:

  • Windows 10: no driver neccessary for the CH341A SPI programmer, just plug it in. First I tried to detect the chip without connecting to it, just to see what NeoProgrammer will tell me. At this point I got the message: CH341A not detected, so I thought maybe I need a driver? But as soon I put the clamp on it found a chip, so obviously no driver needed.

  • As you can see on my picture above the chip is labeled QX128A but NeoProgrammer detected a QF128 chip. Then I readout the chip using different settings (F or N whatever) but the result was always an identical file so it obviously doesn't make a big difference there, or the X is just a placeholder for any letter you find on your chip, idk.

  • HxD under Windows did a fantastic job inserting (Paste insert) the sysupgrade.bin. Just open it, select all, copy it and then in the file I got from the SPI programmer insert it at the hex position @xabolcs mentioned above. (0x00180000) overwriting whatever there was.

  • I saved the new file and tried to write it back, but forgot to erase the chip first. Yeah, you have to do that, then a verify and I was done.

Again, thanks everbody for all the help. So, whatelse could I flash now? :slight_smile:

3 Likes

You do this in the openwrtinvastion shell the part where you have initially cracked with the exploit, you will have to use the 0.1 version and not the latest!

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.