As part of my ongoing exploration of the internals of the Xiaomi vacuum robot, I took a more thorough look at the boot process of the Allwinner SoC today. It turns out they use a slightly patched version of Allwinner’s U-Boot tree. When disassembling the U-Boot present on the device and checking the source in parallel to spot any differences, I came across this gem. What this means is that by sending “s” characters on the UART interface while U-Boot is going through its early initialization, one can force it to enter a shell, even if bootdelay is 0 (which is a common way to prevent end users from accessing U-Boot) or similar.

This means that the process described in an earlier post can be drastically simplified: Instead of glitching the eMMC access and pushing a custom U-Boot image into RAM and using that to access the filesystem, one can simply use the U-Boot already present on the device (soldering cables to the UART pins on the back of the PCB is required, but this might be less of a hassle than getting the eMMC glitching right) . Note that it seems to number devices differently, so the ext4load command that worked for me ended up being ext4load mmc 2:6 0x43200000 vinda.

As I figure that most other Allwinner-based devices also use (a derivative of) Allwinner’s U-Boot tree, this backdoor should be present in quite a number of devices. I guess this will be useful in other places and also serves as a reminder of the kind of “features” you might accidentally gain from using shady vendor-patched trees of open source software…