Important Notice
I’m writing this post to give a lens into robot hacking and the work being done by the community. This is not aimed to sell the idea of hacking your robot. That said you might find this an interesting read and after heavy research may consider to hack your own robot vacuum.
Please do your research and understand the goals and risks of hacking your robot before you try.
Introduction
This is a long post on things I wish I knew earlier about hacking robot vacuums. This is not a replacement for existing documentation or help guides. If you only care about rooting your robot and freeing it for the cloud and don’t care about how the robot works, chances are this post won’t be that helpful to you.
Earlier this month, I installed custom firmware and a cloud replacement on a second Dreame L10s Ultra robot vacuum. Also released this month (2024-June) was root and cloud-replacement support for the new Dreame X40 Ultra and Dreame L10s Pro Ultra Heat, so it’s certainly still an exciting time to get into robot hacking!
I’ll quickly cover about my views on robot vacuums, the robot hardware, the hacking community, the software, and write briefly about my experiences. Feel free to skip over my preamble into robot vacuums if you’re not interested.
Why am I crazy about robot vacuums?
Robot vacuums are a great purchase as you can only vacuum and mop your home so much. Dust builds up very quickly and unless you’re regularly vacuuming your home daily, you’ll find that dust will travel across the house onto more surfaces.
Modern robots have advanced mop heads which spin at fast speeds to get your floors clean. They can take in clean water from a water tank in the dock, use detergent, self-clean & dry the mop, and empty the dirty water into a secondary dirty water tank for you to empty into your drain.
The mop means my hardwood floors are shiny which makes me happy. I find mopping tiring so it helps relieve some physical hardship.
I also got a robot for my elderly parents which helps reduce physical effort needed by them to maintain a tidy house. It’s a great piece of luxury hardware if you can justify spending the money on one.
Why am I also unhappy with robot vacuums?
One of the main factors is privacy. As a consumer you place a lot of trust on the vendor. You don’t have any control of the software running on the robot. It requires internet access, has cameras, sensors, and local AI models equipped.
These aren’t crazy concerns to have. If you watch Dennis Giese & braelynn’s talk at 37C3, they showcase that robots made by a specific vendor have user data which is publicly accessible, remains on cloud servers past account deletion, and remains on the robot past factory reset. The same vendors robots software avoids TLS checks as they have shell scripts with wget --no-check-certificate
in the firmware. Additionally they showcased an exploit where the live video feed for a robot is accessible under certain conditions as a pin check is enforced client side in the application.
Other than privacy, you may not want a robot due to high cost, messy or uneven flooring, or carpet, which in recent years is less of an issue due to detachable mop vacuums.
Update: Dennis Giese published a zero-touch RCE via BLE for the same vendors robot. An article is available here showcasing the exploit: https://www.abc.net.au/news/2024-10-04/robot-vacuum-hacked-photos-camera-audio/104414020
Robot hardware breakdown
Below is a hardware breakdown diagram from the same talk mentioned earlier.
The SoC
The system on a chip (SoC) is the application processor which handles navigation, mapping and networking. It typically runs Linux.
Custom vendor software runs on the robot as a daemon and does most of the heavy lifting handling cloud communication, OTA, robot control, mapping, and other user facing functions. On Dreame this software is called ava, and on Ecovacs it’s called medusa.
Some interesting things I found:
- Some vendors have a lot of shell scripts with poor bash/shell scripting practices which get called on the SoC. These scripts may interact with the OS, handle WiFi (e.g. interact with
wpa_supplicant
), or interact with the custom vendor software. - As the camera is part of the SoC, on some devices it can be accessed as a video device on
/dev/videoX
. - Newer robots can be seen having 4 core SoCs, 1-2GB of RAM, 4-8GB of flash storage, and getting more powerful overtime.
- My robot, the Dreame L10s Ultra runs Athena Linux ARM64 on the SoC
Linux r2228_release 4.9.191 #1 SMP PREEMPT Wed Sep 13 15:19:31 CST 2023 aarch64 GNU/Linux
The MCU
The micro-controller unit (MCU) handles real-time operations such as motors and sensors. This has it’s own firmware separate to the SoC’s firmware/OS. Information on the MCU firmware for the Dreame Z10 is available here if you’d like to learn about what lives in the MCU for a robot.
MCU interest is not as popular. It requires a different set of skills. There’s a lot of secret sauce baked into the MCU, so vendors make it difficult for people to understand what’s happening. Most people are interested in the SoC and the cloud integration. I’d suggest only learning more if you’re interested in hardware or MCUs.
Finding hardware information
Dennis Giese has done research on a large number of robots and published information here. Information on the hardware used as well as software & firmware versions, links to rooting methods and custom firmware downloads are available for many robots.
There are sometimes breakdowns of the robot boards themselves. It’s an extremely valuable resource to understand what builds up a robot.
The robot hacking community
The community seems to be broken down to the following groups of people:
- People interested in removing the cloud from their robot
- This is the average hacker and makes a large portion of the community
- Mixed level of skills
- Many sadly incapable of reading documentation/FAQs or following instructions and complain on Telegram or GitHub
- It’s disappointing to see in the chats as it makes approaching the community as an outsider more difficult as such
- People interested in the hardware
- People interested in the firmware/software on the SoC
- Gaining root
- Building custom cloud implementations
- Research
- People interested in the firmware on the MCU
There are many people who contribute greatly in the community, but it boils down to these two people (who are the most public):
- Dennis Giese, an IoT researcher
- Dennis maintains Dustbuilder, a website which allows you to create custom rooted firmware for robot vacuums
- Dennis also maintains the Robot Info website (mentioned earlier)
- Dennis and others discover root methods, gain persistence, and verify vendor claims
- Sören Beye (known as Hypfer) who is the maintainer of Valetudo, a cloud replacement software for robot vacuums
- Hypfer is very vocal about his views and vocalising the strug of maintaining a popular open-source project and providing support. See the “On not burning out” section in this release: https://github.com/Hypfer/Valetudo/releases/tag/2024.06.2. It’s a good read. Don’t be like these people if you visit the Telegram chat.
- FWIW: I found that the Valetudo/rooting how-to guides and surrounding documentation are simple enough to follow and answer enough questions that you shouldn’t need additional support in Telegram.
Dustbuilder
Once a root method is discovered and published, a Dustbuilder page for a robot is generally created sometime later.
Dustbuilder creates a patched firmware to run on your SoC, and gives you an MCU firmware image. It saves you from dumping and patching the firmware yourself (which may not be possible), and saves you from doing it incorrectly.
It has several patches to allow you to gain persistence on the robot, and disable cloud connectivity, calling home features like telemetry, video recordings. It allows you to use Valetudo, and much more. You can see the diff from the original firmware image which is really helpful in understanding what it does.
If a vendor updates the firmware, it’s likely the Dustbuilder firmware will also be updated (once determined stable). This means you can continue to receive vendor updates to the MCU/SoC even when rooting.
Valetudo
What is it? (tech wise)
As a preface, I’d suggest reading the Valetudo Newcomer Guide and come back here. I’m going to write mostly about my observations about tech itself rather than what the software offers and it’s goals. Please read the official documentation to understand the project.
As mentioned, Valetudo is a cloud replacement for robot vacuums. It has a frontend written in React + TypeScript, and a backend written in Node.js.
Valetudo is an interesting piece of software as it will run an API, serve a frontend, act as an MQTT client, and implement the robots cloud all as a single binary on your robot.
It’s not a firmware replacement unlike other articles on the internet mention. Instead it sits alongside existing firmware on the robot, typically a patched firmware from Dustbuilder. As it does not replace the firmware, you shouldn’t lose functionality of the original robot.
Before installing Valetudo I was expecting that I’d have to host it on another machine as it’s a cloud replacement, but this is not the case. It has no dependencies on other infrastructure like a server, except for NTP, and has no dependency on a mobile app interface like stock firmware robot vacuums.
Cause of it’s architecture, Valetudo won’t face any issues due to infrastructure being down or having a conflicting version. It will simply operate as expected as long as it can continue to run on the robot. If you have multiple robots, then they will each run their own instance of Valetudo.
This has the con that the robot has to be powerful enough to run Valetudo as well as its original firmware, however the maintainer has taken a lot of efforts to ensure Valetudo runs with a low hardware footprint.
Valetudo officially supports 35 different robots across different vendors. Officially supported means each robot has been tested by Hypfer, with the root method documented for each robot. It’s insane that a single piece of software not only works with so many robots, but that the developer has also tested it themselves and continue to hold the software to this standard.
Valetudo has well documented releases every few months with breaking changes documented, and can also update itself in the UI. Newer versions may have UI updates, bug fixes, but more importantly support for newer robots.
Using it
To use Valetudo, you simply go to it’s web UI, which is accessible via your robots private IP, or by port forwarding to the web server on the machine via SSH. The web UI offers you control of your robot like you would in a native app.
Of course it can integrate with systems like Home Assistant via it’s MQTT client, which will then allow you to control it via Home Assistant with various integrations. At the moment, I use this card to control my robot in Home Assistant.
Why/why not
I’m not going to write about why or why not to use Valetudo. If this got your interest, read the below pages, and the surrounding documentation on the Valetudo website:
My rooting journey
I followed the Dreame fastboot instructions for both my Dreame L10s Ultra’s. The robot is slowly approaching end of life so I was lucky to get it on sale. I couldn’t easily obtain the Valetudo rooting PCB board so I used some dupont cables and an old USB mouse with a USB 2.0 cable (rip mouse). It worked OK minus some USB 2.0 shenanigans. If I could do it again, I would put the effort in to obtain the PCB board as I probably wasted 2 hours getting the USB connection to work correctly.
I previously had a Roborock S6 MaxV which I couldn’t root and faced many issues getting the Home Assistant integration working. Occasionally the vendor would rate limit my Home Assistant integration or change their API, meaning I’d have to wait for the maintainer of the integration to address the issue. I’ve not faced any issues with my L10s Ultra and Valetudo due to its native MQTT client and Home Assistant support. The robot has not skipped a beat and is far more responsive than my previous vendor cloud locked Roborock. I also have no internet calls coming out of my robot (using a NTP server on my LAN), so I’m super pleased with that.
What’s upcoming in the community?
In Dennis Giese’s recent talk he covered Ecovacs vacuums. The root method for many models is now public, however there is no Valetudo support for them right now. Please do not ask the maintainers when they will supported. We can only hope there’ll be Valetudo support in the future or a cloud replacement for these robots.
Update
I spent a month hacking my Ecovacs X1 Omni. I published some notes and a forked version of Valetudo which works on my robot.
See the links below:
See also
The resources below helped me understand the things I wrote about:
- Dennis Giese’s talks (these are a must watch):
- Valetudo’s website and documentation
- Dennis Giese’s website
- alufers/dreame_mcu_protocol
Thank you for reading
Thank you so much for reading my post. If you have any feedback or queries, please reach out to me. My details are on the home page.