In the past I have worked with the first generation of Shark Robot vacuum, but I ran in to limitations due to the hardware being locked down. You can find the information on that project Snark Iun Robot .

With the model I am currently working on, I gained a lot of knowledge that corelates directly by attempting to RE the Shark RV1000AE. This model used the Rockchip RV1108 SOC to provide navigation using VSLAM in combination with odometry data from the Robot Vacuum Cleaner base (RVCbase).

This system proved to be difficult to extract information since the V1 Nav board (L01) had all debug interfaces turned off, and utilized a protected flash. I don't know if I did something wrong, but it might also have had a failsafe function in case of glitching the flash to get to a mode to dump. After trying to glitch the flash, it seems the user data section was corrupted, and pointers to get the L01 to boot to main was broken. The good news is that the RVCbase debug interfaces were intact, so I was able to dump the STM32 firmware.

Although I was not successful in extracting firmware, I gained a wealth of info since the connection between the RVCbase and L01 is the same as the V3 Nav board (L02). The debug header is also the same between the two. The debug header is on the RVCbase PCB, and is used for the SWDIO for the RVCbase STM32 MCU. The debug header also has USB I/O and **REDACTED** connections that route to the L01/L02.

Both Nav boards have Debug UART test pads that when connected to at 1500000,8,N,1 provide a boot console. The L01 boot console crashes on inputs form the keyboard, but the L02 will allow a boot to the uboot console if **REDACTED** pressed while booting. If left to boot normal, eventually a login prompt will be presented... no luck in getting logged in as non of the "normal" defaults work.

Playing with the **REDACTED** input on the L02, I found that I could boot to the recovery console if I provided the **REDACTED** at boot.  In this mode the system boots to a minimal configured busybox console with only basic partitions mounted. I found in the **REDACTED** partition the mount **REDACTED** aliases for the rootfs and oem partitions. I was able to manually mount these, and had full read access to both of them. Sadly the rootfs partition being squashfs, was read only.

If I booted using the **REDACTED** with USB connected to my PC, I was able to enter Maskrom mode. Here I was able to read the flash and SOC info. I was also able to dump the first 32Mb of the 4Gb emmc, but I was not able to dump more than that. This dump limitation is due to what seems to be an error with how the length checking function is implemented in the loader firmware. It seems that it is using an unsigned short integer instead of a unsigned 32bit integer. Since 0xFFFF is dec 65,535, and each block is 512Kb, this ends up where only 32Mb is the height limit.

In trying to dump to external memory, I borked the board. Now I am waiting for another to come.

You can also check out my github related to this project (REMOVED) GitHub_Project. Hopefully soon I can get a full FW dump, and I can create a map that will make it easy to modify the FW (rootfs in rw) and re-pack the image to a format that can be flashed to the SOC.