Add OpenWrt support for Xiaomi "Redmi AX6000"

Wow, after nearly 3 weeks mine seems to have made its way out of customs! It’ll be here later today.

2 Likes

Alright, we got open ports on:
53 - DNS
80 - Web GUI (nginx)
443 - Web GUI (nginx)
784 - Unknown
8080 - Web GUI (nginx)
8098 - Web GUI (nginx)
8883 - Unknown (looks like mqtt for their app)

No SSH or telnet.

Mind you I'm new to Xiaomi devices so I don't really know what they look like historically.

For anyone else trying to open the device, after you remove the 4 rubber feet and screws beneath, stick a tiny flat head in between the bottom part of the case near the antenna and the whole bottom will pop out very easily.

I also left my serial adapter at work so will have to wait until tomorrow to hook up UART. Oops!

3 Likes

I believe they also sync configuration to mesh nodes here, if I recall.

That's their ubus listener for trafficd I think. I recall I've already tried to fuzz the few string inputs in there... Or I was trying to add non-existent lightbulbs as some other convoluted thing I was testing...

Here's the entire bootlog (in one place) https://gist.github.com/soxrok2212/03e08ec1879c33fc85c753a72f9a64c0

@EUA is right, UART RX is disable on the board.

Looks like serial is disabled before u-boot, right after ATF finishes loading.

Pulled up the spec sheet for the onboard WSON flash chip (https://www.esmt.com.tw/upload/pdf/ESMT/datasheets/F50L1G41LB(2M).pdf) and tried shorting SO during boot. Here's what I found. Shorting the pin:

  1. Before giving power halts the system immediately.
  2. During various stages seems to halt the boot "eventually", at some random point.
  3. Too late and it'll proceed to boot.

Looking at extracted firmware:
/etc/openwrt.config

#
# ATF
#
CONFIG_PACKAGE_atf-mtk=y

#
# atf-mtk settings
#
# CONFIG_ATF_MTK_USE_VERSION_2_5 is not set
CONFIG_ATF_MTK_USE_VERSION_2_7=y
CONFIG_ATF_MTK_VERSION="2.7"
CONFIG_ATF_MTK_VERSION_2_7=y

#
# Boot Loaders
#
CONFIG_PACKAGE_uboot-mtk=y

#
# uboot-mtk settings
#
# CONFIG_UBOOT_MTK_USE_VERSION_6_0_4 is not set
# CONFIG_UBOOT_MTK_USE_VERSION_1_2_1 is not set
CONFIG_UBOOT_MTK_USE_VERSION_2022_01_rc4=y
CONFIG_UBOOT_MTK_VERSION="2022.01-rc4"
CONFIG_UBOOT_MTK_VERSION_2022_01_rc4=y

So yes, ATF is used as well as u-boot. It's likely BL33, which is not missing from the bootlog, it's just not present.

1 Like

Upload some firmwares(no ssh enabled) collected from their QQ group. looks like a full firmware upgrade contains 4 files: preloader.bin, fip.bin, crash.bin, firmware_ubi.bin

https://drive.google.com/drive/folders/1RusLHTwnZwROpnUXyJi0AvEdSN9vrnNb?usp=sharing

3 Likes

Great resource! Thank you!

@namidairo if you have any suggestions as to what to try next, let me (us) know. Device is sitting here on my desk waiting for some action. I'll try looking through the firmwares @xhcnb posted for the Lua injection @LonGDikE discovered here: Adding OpenWrt support for Xiaomi AX3600 - #63 by LonGDikE

I did try a quick copy paste and got error 1523 (which is referenced in the code as invalid parameter).

FYI - It appears they block downgrading software versions. I'd recommend anyone who gets one, don't upgrade like I did :frowning:

1 Like

when the webpage says no downgrade, change the url last word from 0 to 1, and try again

3 Likes

Great tip! Appreciate the help as, again, I have no Xiaomi experience.

I attempted the Lua/SSH trick documented for the AX9000 (and AX3600) here: https://openwrt.org/inbox/toh/xiaomi/ax9000

Set it up on a spare Belkin E8450 I have running OpenWrt 22.03-rc4. I verified with wget that it pulled the right config when loading up http://169.254.31.1/cgi-bin/luci/api/xqsystem/token from my laptop. All checked out normally. When attempting this on the RedMi AX6000 (using the correct stok), I'll either get a internal server error or a 502 Bad Gateway. I can see on the E8450 that it has joined as a client, but for whatever reason it fails.

2 Likes

That particular exploit was patched even before the previous model (RB03) was released.

I suggest diffing the lua between the newest and the oldest versions. They'll still be byte-identical with the same input into their obfuscator, so comparison should still show which ones have changed. (They in theory could shuffle opcodes or add no-op junk everywhere, but I believe the primary purpose is mostly to discourage IP theft.)

Changes in their binaries will be harder to track, but I imagine bindiff or similar should work. (I'm not sure of the workflow to do it in batch though)

Bummer that it’s patched. Lua is not my strong suit so I may not be the best fitted for this particular part of the problem.

I'm thinking more about this device and how it uses ATF. I'm wondering if there's a System Control Processor (SCP) on the board and the exposed UART header we have is UART0 and that is connected to the SCP. This means there's likely another UART1 connected to the SoC somewhere else (and this is exactly as I've seen in other devices before). Once the SCP finishes the ATF boot process, it hands off to the application processor and to the other UART interface. This explains why we don't see U-Boot (or the linux kernel booting) on the console, as that is booted on the application processor.

This is all speculation and I'm not familiar with the platform. See https://support.xilinx.com/s/question/0D52E00007C8sznSAB/uboot-not-starting-after-atf?language=en_US for reference.

Also see https://www.reddit.com/r/embedded/comments/t6e30j/atf_uboot_experience/ U-Boot is likely printed to some other console. I took my AX6000 apart completely late last night (really late so might've been tired and missed it) but didn't see anything that looked like a UART console.

The dts seems to reference 3 UART consoles https://gist.github.com/soxrok2212/f922c93ec8a09738cb8bd64d6eb0cb3f#file-xiaomi-redmi-ax6000-rb06-dts-L230-L262

Strange... They still have it pointing at ttys0 in the bootargs too...

It's obviously not HW flow control since uart0 does not support it (The other two channels do), but maybe they did a funny and enabled software flow control after initial boot? They'd need a way to debug returns somehow, surely? Either that or there's a sneaky 6 pads on there for the other uart channel or jtag. I can't seem to find the jtag enable/disable strap in the BPi reference materials like on the 7622 though.

On another note, that Xiaomi HomeWifi product I noticed in the firmware a few months ago was announced finally...


Here’s 2 high(er) res images than the acwifi teardown. Perhaps you’ll spot something.

There's actually those 6 pads underneath the 2.4G radio that I don't recall if I checked...

I don't understand why they disable onboard UART to avoid install custom ROMs.
We paid for device and it became ours.
Why companies try to avoid our access to our paid hardware unit.
They could sell more HW units if they are friendly with consumers.

I reached out to them asking for the source for the open source components. Unfortunately for us, ATF (and SCP-firmware, if used) are BSD-3 - meaning they don't have to disclose those components to us. However, they do have to disclose U-Boot and OpenWrt sources to us due to GPLv2 licenses there. I'll see what they say.

I did have to go through their Chinese site as they don't sell this model outside of China (yet?) so I tacked on a Google Translate Chinese version of my request. Hopefully it doesn't just get thrown out.

5 Likes

Hi, very nice of you to share! Which of these versions do you recommend?

The oldest is typically the "most vulnerable" but AFAIK there's no recommended version right now.

Could we upload OpenWRT firmware using TFTP debricking procedures? :roll_eyes:
Does router checks it at start? Might be, with a help of a reset button at start... If it starts TFTP detection etc... I am not really good on TFTP protocols. It just came into my mind. There should be a debrick procedure for it...

Well, I just picked the router too quick by guessing that if consumers are allowed to root it as older (Mi 3G) routers.