Shark Robot Vacuum Reverse Engineering

I had to remove a decent portion of information related to this project due to the threat of legal action by Shark Ninja. I am hoping to maintain the spirit of this project while still satisfying the lawyers at SharkNinja.

In playing around with the **REDACTED**  for android, I found that they left the  **REDACTED** files in the resources directory. I have already verified that some of the base64 MQTT messages I captured in the system log translate accurately. 

I do have a large number of messages that are only partial, and I have yet to figure out the method to identify the message type.

Using Ghidra to look over the files of the OEM partition, it seems the **REDACTED** application is central to the Visual and Odometry navigation. Data from the RVC_Base is piped in to **REDACTED** through /dev/ttyS0. Trying to use a USB to serial adapter connected to the traces on the RVC_Base that I anticipate are the same as ttyS0, I was met with unformatted junk that seemed to have string contained within that also would escape the terminal. Oddly enough, there was occasionally legible ascii string.

Trying to figure out how I can make sense out of that mess, I stumbled across strace, and how to use it to parse serial data within an application.

The information that I collected was inspiring! The problem I have is that I have only the mainboard for this robot vacuum, and the robot vacuum I do have has fewer sensors than what the new board uses. 

This seems to be causing the board to enter an error state soon after boot that just ends up being a loop.

So I have on the way an appropriate fully functional robot of the correct model to experiment further.

Here is a sample of the output from the ....

Sorry, this content has been removed due to the lawyers at SharkNinja...

After wasting too much time with ADB, I decided to move on. Next on the list is to use GDB and Ghidra to RE some of the applications. The main application I am interested in is the **REDACTED**. Initial analysis shows this is where all of the VSLAM calculations are done, and the RVC_Base inputs are polled. 

This will be a fun weekend!

So a problem I have had for some time is getting ADB to work.

I have it setup in init.d for ADB to work, and I can run ADB on my computer to see the device SN, but it says UNAUTHORIZED.

I have tried all I can think of as for the common issues with ADB giving an Unauthorized.

The main culprit I think it there is no mechanism on the Robot to accept the ADB connection request like you would with a phone or tablet.

I can't find anything in the ADC keys or GPIO keys in relation to ADB, but then again I can't find anything about the ADC key I found to get into recovery mode...

Any suggestions?

Wow, this was a quick one! Other than a simple check, there are no major blocks to changing the default sounds.

As of right now, a custom sound has to replace an existing sound, and take its name. In my example I replaced s01_ power_on.mp3 with my own mono mp3. I hade to mount the userdata partition in the tmp directory, and replace the desired mp3 in the /tmp/userdata/music directory. 

It also seemed that I needed to replace the same file in /mnt/udisk/music directory, or else I had issues where it would grab the original, or not play at all.

Here is a video example:

Finally got SSH working, and it was fun!!!

Once the sshd config, and ssh starting script in init.d were modified I tried starting sshd. I was presented with a notification that /var/empty must be owned by root, and cannot be group or world writable.

**REDACTED**

**REDACTED**

Made some progress, but despite the config files, sshd does not want to point to the host keys.... I broke that I bet. Simply grab host keys and put them where sshd thinks they should be... okay, oh wait, the pub keys are in an  invalid format?

**REDACTED**

Ok, SSH to the robot.... YAY!  Now I can easily move files around in the R/W directories, and no more serial cables... the robot is now free of its umbilical!

Next will be playing with the mp3 sound bank... I think it should be pretty easy.

Then I will look at some of the applications in the /res directory... it looks interesting!

Yeah, sorry, I know I don't have any screen shots... I was in the zone.

When looking around the OEM partition, I found an interesting file. I completely forgot where the file was located, and what it was called, but it contained a link to **REDACTED**. The link was for a zipped compressed upgrade firmware. I posted the FW ( Removed due to SharkNinja lawyers) on my github as a multi-part RAR.

This makes things much easier as this is the firmware as a proper update for all parts.

The update.img can be unpacked with the RKDevtool or the imgRepackerRK from RedScorpion on XDA Dev forums. The imgRepackerRK is a great option, but must use the option to not checkchip id. When the image in unpacked with this tool, it creates some config files for repacking the image.

Do not unsquash the rootfs.img on a Windows machine as it breaks the symlinks.

Make the changes in a unix compatible text editor, run a mksquashfs, repack with imgRepackerRK. 

Use RKDevtool to load the update.img with the upgrade tab, and upgrade.

It seems all checks are only done when doing an OTA update, and nothing I have seen is checked at boot time.

Well I decided to play some risky biscuits, and  reading up on rockchip documentation I found I can do an upgrade without over writing the entire firmware... **REDACTED**... used the Rkdevtool to upgrade, and all was good!

Did a wget spider to see what it would do...

Sorry, this content has been removed due to the lawyers at SharkNinja.

next job is to get ssh working, and then I can update the lame voice packs. 

So I got in 2 more sample for a total of 3.

I have all 3 with the emmc dump up to the 32Mb mark due to the loader limitation. 

I can also mount the oem and rootfs partitions to play around.

I copied the shadow file from /etc , and two of them have the same password.

Removed due to SharkNinja lawyers

The ImageType 2 is where I have the shared password hash. Comparing the two, they are identical until the root file system. Since I can't dump the rootfs easily yet, I had to manually compare. It was quickly evident that the rootfs saw some differences.

Trying to crack the hashes has not worked out.... I am guessing that the password is derived from a hash of the kernel, in the area of the dump past the 32Mb limit, or some other method.