geekman
[QUESTION] does the script also work for Redmi AX5 and Xiaomi AX1800?
If yes, I would like to do it on my AX5
root@XiaoQiang:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00180000 00020000 "0:SBL1"
mtd1: 00100000 00020000 "0:MIBIB"
mtd2: 00380000 00020000 "0:QSEE"
mtd3: 00080000 00020000 "0:DEVCFG"
mtd4: 00080000 00020000 "0:RPM"
mtd5: 00080000 00020000 "0:CDT"
mtd6: 00080000 00020000 "0:APPSBLENV"
mtd7: 00180000 00020000 "0:APPSBL"
mtd8: 00080000 00020000 "0:ART"
mtd9: 00080000 00020000 "bdata"
mtd10: 00080000 00020000 "crash"
mtd11: 00080000 00020000 "crash_syslog"
mtd12: 00080000 00020000 "0:BOOTCONFIG"
mtd13: 00080000 00020000 "0:BOOTCONFIG1"
mtd14: 00380000 00020000 "0:QSEE_1"
mtd15: 00080000 00020000 "0:DEVCFG_1"
mtd16: 00080000 00020000 "0:RPM_1"
mtd17: 00080000 00020000 "0:CDT_1"
mtd18: 02400000 00020000 "rootfs"
mtd19: 02400000 00020000 "rootfs_1"
mtd20: 024a0000 00020000 "overlay"
mtd21: 00080000 00020000 "cfg_bak"
mtd22: 003a2000 0001f000 "kernel"
mtd23: 01341000 0001f000 "ubi_rootfs"
mtd24: 00915000 0001f000 "rootfs_data"
mtd25: 02093000 0001f000 "data"
root@XiaoQiang:~# nvram get flag_boot_rootfs
1
I took a quick look at the AX5 and RM1800 firmwares. It looks like the way the update is performed is very similar to the R3600, but the UBI volumes on the AX5 and RM1800 have an additional rootfs_data volume. I have added an option to ubinize.sh to mimick this extra volume in 00b1974.
The instructions are similar to the R3600, except that during the ubinize.sh step, you will need to append a --data arg to emit this volume, and you also need to use the correct mtdX names when flashing, which looks like mtd18 and mtd19 in your case. I can't guarantee for sure it will work, but if you are brave enough, you can give it a try and report back.
Note that the latest firmware for the AX5 (1.0.26) seem to also contain an update to U-Boot, which is not flashed via this procedure. It could just be a bugfix and you could ignore it, but I can't be sure.
I took a quick look at the AX5 and RM1800 firmwares. It looks like the way the update is performed is very similar to the R3600, but the UBI volumes on the AX5 and RM1800 have an additional
rootfs_datavolume. I have added an option toubinize.shto mimick this extra volume in 00b1974.The instructions are similar to the R3600, except that during the
ubinize.shstep, you will need to append a--dataarg to emit this volume, and you also need to use the correctmtdXnames when flashing, which looks likemtd18andmtd19in your case. I can't guarantee for sure it will work, but if you are brave enough, you can give it a try and report back.Note that the latest firmware for the AX5 (1.0.26) seem to also contain an update to U-Boot, which is not flashed via this procedure. It could just be a bugfix and you could ignore it, but I can't be sure.
Okay, I'll try it out. Just to confirm, is this the expected output?
matheus@matheus-CL341:/firmware$ ubireader_extract_images -w miwifi_ra67_all_f3fac_1.0.26.bin
read Error: Block ends at 25783896 which is greater than file size 25653096
extract_blocks Error: PEB: 191: Bad Read Offset Request
matheus@matheus-CL341:/firmware$ fakeroot -- ./repack-squashfs.sh ubifs-root/miwifi_ra67_all_f3fac_1.0.26.bin/img-1145051904_vol-ubi_rootfs.ubifs
/usr/bin/unsquashfs
unpacking squashfs...
Parallel unsquashfs: Using 4 processors
3656 inodes (3754 blocks) to write
[======================================================================================================================================================/] 3754/3754 100%
created 3264 files
created 241 directories
created 391 symlinks
created 1 devices
created 0 fifos
patching squashfs...
repacking squashfs...
Parallel mksquashfs: Using 4 processors
Creating 4.0 filesystem on ubifs-root/miwifi_ra67_all_f3fac_1.0.26.bin/img-1145051904_vol-ubi_rootfs.ubifs.new, block size 262144.
[======================================================================================================================================================/] 3356/3356 100%
Exportable Squashfs 4.0 filesystem, xz compressed, data block size 262144
compressed data, compressed metadata, compressed fragments,
no xattrs, compressed ids
duplicates are removed
Filesystem size 20220.91 Kbytes (19.75 Mbytes)
30.60% of uncompressed filesystem size (66079.64 Kbytes)
Inode table size 27192 bytes (26.55 Kbytes)
21.22% of uncompressed inode table size (128131 bytes)
Directory table size 36958 bytes (36.09 Kbytes)
41.68% of uncompressed directory table size (88668 bytes)
Number of duplicate files found 487
Number of inodes 3886
Number of files 3263
Number of fragments 123
Number of symbolic links 381
Number of device nodes 1
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 241
Number of ids (unique uids + gids) 1
Number of uids 1
root (0)
Number of gids 1
root (0)
matheus@matheus-CL341:/firmware$ ./ubinize.sh ubifs-root/miwifi_ra67_all_f3fac_1.0.26.bin/img-1145051904_vol-kernel.ubifs ubifs-root/miwifi_ra67_all_f3fac_1.0.26.bin/img-1145051904_vol-ubi_rootfs.ubifs.new --data
ubinize: volume size was not specified in section "kernel", assume minimum to fit image "ubifs-root/miwifi_ra67_all_f3fac_1.0.26.bin/img-1145051904_vol-kernel.ubifs"3809280 bytes (3.6 MiB)
ubinize: volume size was not specified in section "rootfs", assume minimum to fit image "ubifs-root/miwifi_ra67_all_f3fac_1.0.26.bin/img-1145051904_vol-ubi_rootfs.ubifs.new"20709376 bytes (19.7 MiB)
done.
Okay, I'll try it out. Just to confirm, is this the expected output?
That looks about right.
Okay, I'll try it out. Just to confirm, is this the expected output?
That looks about right.
The patched firmware flash worked fine
root@XiaoQiang:~# ubiformat /dev/mtd18 -f /tmp/r3600-raw-img.bin -s 2048 -O 2048
ubiformat: mtd18 (nand), size 37748736 bytes (36.0 MiB), 288 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 287 -- 100 % complete
ubiformat: 288 eraseblocks have valid erase counter, mean value is 1
ubiformat: flashing eraseblock 195 -- 100 % complete
ubiformat: formatting eraseblock 287 -- 100 % complete
root@XiaoQiang:~# nvram set flag_ota_reboot=1
root@XiaoQiang:~# nvram commit
root@XiaoQiang:~# reboot
The ssh password remains the same as my previous one (admin), I believe it is because I did not reset the router. The nvram show command returns that boot_wait and uart_en are disabled, is this expected? Also, should I flash again in the other slot (which was in use at the beginning) so that both slots are patched? I would also like to know if the patch should be done on all new firmware manually or if installing the stock firmware via the web ui on an already patched system will keep the patches after the upgrade. Thank you very much for your time and great work!
root@XiaoQiang:~# nvram get flag_boot_rootfs
0
root@XiaoQiang:~# ls -sh /usr/sbin/otapredownload
0 /usr/sbin/otapredownload
root@XiaoQiang:~# cat /usr/share/xiaoqiang/xiaoqiang-defaults.txt
bootcmd=tftp
bootdelay=5
ethaddr="00:AA:BB:CC:DD:10"
ipaddr=192.168.31.1
serverip=192.168.31.100
stdin=serial
stdout=serial
stderr=serial
telnet_en=0
restore_defaults=0
wl0_ssid=Redmi_5G
wl1_ssid=Redmi
wl0_radio=1
wl1_radio=1
model=RA67
flag_boot_type=2
mode=Router
no_wifi_dev_times=0
uart_en=1
ssh_en=1
boot_wait=on
root@XiaoQiang:~# nvram show
CountryCode=EU
Router_unconfigured=0
SN=censored
boot_wait=off
bootargs=ubi.mtd=rootfs root=mtd:ubi_rootfs rootfstype=squashfs rootwait
bootcmd=tftp
bootdelay=5
color=100
dload_dis=1
eth1addr=28:d1:27:80:2b:8
eth2addr=28:d1:27:80:2b:8
eth3addr=28:d1:27:80:2b:8
eth4addr=28:d1:27:71:bc:8
eth5addr=28:d1:27:71:bc:8
ethaddr=b6:fe:ef:d3:6f:27
fdt_high=0x48500000
fdtcontroladdr=4a473aa0
flag_boot_rootfs=0
flag_boot_success=1
flag_boot_type=2
flag_last_success=0
flag_ota_reboot=0
flag_try_sys1_failed=0
flag_try_sys2_failed=0
flash_type=2
fsbootargs=ubi.mtd=rootfs root=mtd:ubi_rootfs rootfstype=squashfs
ipaddr=192.168.31.1
machid=8030200
miot_did=censored
miot_key=censored
mode=Router
model=RA67
mtddevname=fs
mtddevnum=0
mtdids=nand0=nand0
mtdparts=mtdparts=nand0:0x2400000@0x1180000(fs),
no_wifi_dev_times=0
nv_channel_secret=censored
nv_device_id=censored
nv_sys_pwd=censored
nv_wan_type=dhcp
nv_wifi_enc=mixed-psk
nv_wifi_enc1=psk2
nv_wifi_pwd=censored
nv_wifi_pwd1=censored
nv_wifi_ssid=casa
nv_wifi_ssid1=casa_5G
partition=nand0,0
restore_defaults=0
serverip=192.168.31.100
soc_version_major=1
soc_version_minor=0
ssh_en=1
stderr=serial@78B1000
stdin=serial@78B1000
stdout=serial@78B1000
telnet_en=0
uart_en=0
wl0_radio=1
wl0_ssid=Redmi_BC08_43F7_5G
wl1_radio=1
wl1_ssid=Redmi_BC08_43F7
The patched firmware flash worked fine
That's great news! Thanks for helping to test this!
The ssh password remains the same as my previous one (admin), I believe it is because I did not reset the router. The nvram show command returns that boot_wait and uart_en are disabled, is this expected?
I thought one of the tasks in pre-boot was to re-populate /etc with files from the new firmware, but I may have been wrong about that. The nvram should not have changed through the flashing, so it might be your boot_wait and uart_en were already in this state before the upgrade?
Technically, resetting the router should restore defaults from the patched firmware, which should have ssh_en and uart_en set to 1.
Also, should I flash again in the other slot (which was in use at the beginning) so that both slots are patched?
This is up to you, but I would leave an official firmware on one of the slots in case something goes wrong.
I would also like to know if the patch should be done on all new firmware manually or if installing the stock firmware via the web ui on an already patched system will keep the patches after the upgrade.
You will need to patch and flash every new version manually, like you're doing now. But the web UI can still be used if you want to flash an official firmware.
@geekman
Ax6 is also very similar to AX3600 (same chipset). Can you maybe take a look at the firmware if your tool can work with that too?
Hi, Want to confirm that it works on AX1800, the latest official firmware (1.0.385) blocks the ssh exploit, so I had to downgrade to the previous vulnerable firmware (1.0.378) and flashed the repacked 1.0.385. I have SSH access again.
@cliobrando You just followed all the steps and the only difference is that you had called the ubinize.sh Script with the following?
ubinize.sh --data
thanks in advance as I would like to do it with my AX1800
@cliobrando You just followed all the steps and the only difference is that you had called the ubinize.sh Script with the following?
ubinize.sh --data
thanks in advance as I would like to do it with my AX1800
Yes, you must append the flag "--data" to the ubinize.sh step, and check that the partitions numbers are correct.
This procedure just touches the data partition so if you do something wrong you can always use the MIWIFIRepairTool.x86.exe to restore the router to its original state. It's almost impossible to completely brick this router following this procedure because you don't touch the bootloader.