I want to add my own functionality to a robot vacuum, and also provision it on my own network.
Reverse engineering the Shark RV1001AED series Robot Vacuum
To make the experience fit your profile, pick a username and tell us what interests you.
We found and based on your interests.
I want to add my own functionality to a robot vacuum, and also provision it on my own network.
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.
Create an account to leave a comment. Already have an account? Log In.
yup, fair enough. I got the C&D, took down the material in question. Nevermind the fact that they are using GPLv3 code extensively throught their software. I just want to learn and tinker, not fight lawyers...
Well, that's why I am a proponent for open, self provisioned IOT/Smart Devices.
Those vacuum cleaners are about to takeover the planet. They got ssh, they got cameras, actuators and more. Maybe it is possible to mess with charging control to let battery overheat and explode.
Become a member to follow this project and never miss any updates
Hi Jon,
Just so you know, Hackaday got a DMCA takedown notice from SharkNinja. By the time we reviewed it, it looks like you have already pulled the mentioned copyrighted content, so we're contacting them again to see if they're good with that.
If they come back with more allegations, we are legally required to take your page down, whether the allegations have merit or not. You can issue a conter-claim if you believe that you're not infringing, and we'll put your content up again after 14 days and they will have to sue you to prevent it. Either way, it's between your lawyers and theirs -- Hackaday is out of the loop.
It _does_ appear that reverse engineering software is often granted a fair use exemption from copyright:
https://www.internetlawyer-blog.com/reverse-engineering-fair-use-rights/
https://lawneet.neocities.org/analysis/ReverseEngineering.html
But it may also be expensive and time-consuming to get a court to conclude this for you, and you're going to have to demonstrate that you got the source code "in an unpurloined way". We aren't lawyers, and we're not giving you legal advice.
The DMCA is a weird law, but it's also the law. We just wanted you to know what's up.