I dont think factory mode is enabled:
{"telnet":true,"init":true,"wl0_ssid":"xxx","ssh":false,"version":"1.0.35","facmode":false,"4kblock":false,"secboot":false,"wl1_ssid":"xxx","uart":false}
So you have telnet_en=1 in the Bdata partition.
To view the contents of the Bdata partition, you need to run the query: http://192.168.31.1/cgi-bin/luci/api/xqsystem/bdata
Who can help me or give me some instructions? I disassembled ax6s and tried to modify the firmware with ch341a programmer. I found the NVRAM partition, but I didn't modify it, but I verified the original firmware. The check codes of 0x0 ~ 0x3 didn't match, so I didn't dare to change UART at will_ en=1γ
Perhaps you have a random flip somewhere. Or you're calculating the CRC32 for 0x4-0x10000, when I really meant 0x4-0xFFFF. Or you've done it all correctly and are looking at the checksum with the wrong endian-ness. Or BBT has shifted the data. Or you've accidentally pulled the OOB data into your dump as well. So many options.
I also hope you verified your CH341A is actually outputting 3.3v instead of 5v over the logic lines as well, otherwise you will be pushing the SPI-NAND out of specified limits. Mine required some minor modifications to the programmer board to output the correct voltage.
There'll be much easier install instructions in the future.
3 Likes
I'm assuming you've found an exploitable bug and reported it to the manufacturer?
Are you now waiting for permission to publish this information?
I'm glad to see your reply. In fact, what I checked was also 0x4~0xFFFF data. My problem now is that the firmware dumped by the programmer always inserts a row of data at a fixed offset, which prevents effective verification. I'm not sure if this is ecc or oob data.
like that:
Atlast,I look forward to your simpler installation instructions.
I did the same two days ago.
This is OOB data for the page. For some reason, they are read in any mode. Therefore, I had to read everything in raw mode (used SNANDer tool).
Dump correctly only tool SNANDer in raw copy mode (flag -d without ECC checks).
Modifying this partition is useless. You need to change the bdata partition.
I modified bdata partition with the help of the CH341A programmer and activated the telnet.
How is the Wi-Fi range of this router?
I am wondering if it is better than the Belkin rt3200 which is quite shit�
2 Likes
Gratthanks,raw mode? H can i enter raw copy mode? What commands are used?
any news in terms of an exploit to get ssh access?
My device arrived today 
Did you check? Mine got telnet enabled by default. Actually I would like to try some builds.
fantastic! I will try tomorrow.
diD you manage to enable ssh and boot_wait?
The question is also how we can flash? via ubimount similar to AX6/AX3600?
I didn't want to bother with that kind of nightmare so I just ended up tftpbooting the initramfs image via u-boot console, scp'ing over the images and mtd writing them to firmware, firmware1, and ubi. I didn't want to bother with filesystem locks or rebooting to flash one image over the other.
So in essence (Assuming one has UART):
tftpboot initramfs.bin
scp the images over to /tmp
mtd write factory.bin firmware
mtd write factory.bin firmware1
mtd write rootfs.bin ubi
reboot
In theory since we're overwriting both of the firmware images and we handle the A/B firmware command line with mtdsplit, you shouldn't have to touch the u-boot env boot flags like on the other devices.
I would note that the available space is fairly limited compared to the other 128mb layouts though. Only about half of it is usable for packages.
Realistically, I'd have the stock u-boot and ATF replaced in the same manner as the E8450, in order to have more efficient and resilient storage layout, but I'm focusing on getting initial support out the door first before having to worry about that.
You can build your own images from what I submitted, it should spit out the various images I mentioned above.
In theory you should be able to flash the images without the use of uart console in the stock firmware, in a similar manner to the older ramips Xiaomi devices, but I haven't tested it, or it may require the setting of the boot flags.
I think that if you end up needing to use tftp recovery, it may end up resetting the various u-boot flags as part of the boot process on the stock rom, which is why I was using the uart during development.
On a slightly off topic note, I saw some random forks pull in very early and unfinished versions of the commits, removing the big 'work in progress' label as well... So I guess they'll just have unusable images. Not that anyone would notice, since hobbyist soldering is required for majority of users.
4 Likes
No need to change bootloader. It is enough to simply abandon the Dual Boot functionality.
This is not possible, since after uploading the firmware image into memory, its RSA signature is checked.
printf("CRC verify success!\n");
v8 = rsa_verify(.....);
if ( v8 )
{
printf("RSA signature verify failed! Err code = 0x%x\n", v8);
printf("Image verify failed!\n");
return -1;
}
printf("RSA signature verify success!\n");
There is no need to solder anything, because using the bootloader it is very easy to flash the stock firmware.
You kind of could get away with just setting the first one as failed and setting the second kernel as boot forever on the old ramips layouts, but here the kernel/firmware partitions are much larger since they combined the rootfs and kernel.
I considered doing the same (rootfs with kernel and the ubi as overlay), but figured it might end up messy in the long term for endurance for those flashing updates on a semi-regular basis.
I'm talking about the use of mtd write from within the terminal on a stock image. At no point is the stock firmware image used here apart from tftp recovery or reverting to stock.
It was in the context of initial installation for most users right now.
All this was done in vain. And custom bootloaders (breed, pandora box) loaded the kernel exactly from the first partition (kernel0).
The stock bootloader code contains this:
if ( check_factory_mode((int)v19, v20, v21) )
{
sprintf(&asc_41E4FCC8[(_DWORD)v18], " factory_mode=%s", "1");
setenv("uart_en", "1");
setenv("boot_wait", "on");
}
Therefore, to activate uart, it is enough to make the first 4 bytes in the crash partition (addr: 0x240000, raw addr: 0x252000) like this: A5 5A 00 00
Flashing via SNANDer:
SNANDer.exe -d -e -a 0x252000 -l 0x21000
SNANDer.exe -d -w crash.bin -a 0x252000 -l 0x200
After that, the bootloader will add the factory_mode=1 parameter to the kernel cmdline, which activates the factory mode.
And in the factory mode, you can change the parameters of the bdata partition: bdata set telnet_en=1; bdata commit;.
3 Likes
Unfortunately on my router there is no telnet activated β¦
I get this:
{"telnet":false,"init":false,"wl0_ssid":"xxx5G","ssh":false,"version":"1.0.28","facmode":false,"4kblock":false,"secboot":false,"wl1_ssid":"xxx","uart":false}
You have some kind of unusual firmware installed. It is simply not possible to download it.
I would take a look at the syslog received on your device:
http://192.168.31.1/cgi-bin/luci/;stok=XXXXXXXXXX/api/misystem/sys_log