 Hi, I am Dennis Gieser and welcome to my talk about robots with lasers and cameras, but no security Where we will talk about ways how you can liberate your vacuum from the cloud Before we start here some background information about me I'm a PhD student at Nofisa University, and I'm working with Professor Gewerner Beer. Our research field is wireless and embedded security My particular interest is in the reverse engineering of interesting devices I focus on smart home devices, mostly vacuum cleaning robots My current research is in the security and privacy of smart home speakers In our most recent work, we analyzed the security and privacy of used Amazon Echo devices This paper was published on AC&Y sectors here. Let's talk about the goals of this talk First, I would like to give you an overview over the current development and routing of vacuum cleaning robots In particular, we will focus on Roborock and Dreamy. We will talk about vulnerabilities and backdoors And I will explain new methods which you can use to root your device As a general side note, I have no intention of bashing the companies I like the products and I think we have maintained a very friendly relationship However, obviously our goals are slightly different All right, let's talk about our motivation. So why do we want to root devices? Well, as devices have powerful hardware and a lot of sensors, we can play around with interesting hardware This is especially interesting for people in education Then we want to step devices from constantly phoning home Also, a lot of people have already custom smart home services running, for example, home assistant And here it is interesting to connect the vacuum cleaners to that system And finally, we want to verify the privacy claims of the manufacturers So why don't we trust IoT? Well, IoT in general, they are always connected to the internet and they are on your home network The cloud communication is encrypted and you don't really know what kind of data is transmitted From our experience, we know that developers secure hardware and software is hard And that IoT devices are not always being patched Also, vendors sometimes contradict each other in regard of their privacy claims And as an end user, you have no way to be sure All right, here's an example Roborock claims for the flagship model that nothing is sent to the cloud Especially what is recorded by the camera This claim was also certified by the German TÜV However, on the same website, they show that you can access the camera remotely from your phone For example, you can watch your pets and talk to them Let's talk about the problem of use devices A lot of people order devices on Amazon, try them and return them So use devices are not that rare As a buyer, you have no real information about the past of the device So a malicious person could have installed a rootkit onto it As a new owner, you have no way to verify the software And as a result, you might have a malicious device in your home network So rooting is the only way for you to verify that the device is in fact clean All right, let's take a look into the past, the good old times of rooting My first work with vacuum cleaning robots was back in 2017 Here, I worked with Daniel Weigemann And we were looking at the Xiaomi vacuum cleaning robot and the Roborock S5 We figured out that the firmware images of these devices were unsigned and encrypted with a very weak key And that custom firmware could be pushed from the local network As a result, it was possible to root the devices without disassembly And develop custom software and voice packages for the bin We published our findings on the 34C3 and back in 2017 And also on Defcon, exactly three years ago Here, I would like to give you some short recap about the hardware of the Xiaomi vacuum robot and the S5 Both robots were running an ARM quad-core CPU and have 512 megabit of RAM They had also 4 gigabyte of EMMC flash They had a lot of sensors, and in particular the most important ones are the LiDAR sensor on the top of the robot The infrared sensor and the retrosonic sensor These devices had also some debug ports, for example USB and URT However, USB was kind of protected and we never used it for anything To give you some background information about the software This device is run Ubuntu 14.04, mostly untouched However, the vendor is obviously scheduled to root the password Interestingly, the vacuum cleaners were controlled by the player software Which is basically an open-source robot device interface and server So they used open-source software to run the devices They had a lot of proprietary software on them For example, they used the custom ADB version Which had some authentication and so we couldn't really use it They run a custom watchdog, which made sure that the device didn't crash But on the other side also enforced copy protection And they had the logging tool, which uploaded a lot of data to the cloud They protected the ports on the device with IP tables For example, they blocked the port 22 for SSH and blocked also the player ports However, the interesting thing was that the IP tables' rules only applied to IP version 4 So if the device got an IP version 6 address, it would not buy a watt at all All right, let's look on how the forces dragged back And how they started to lock down the devices Well, the first steps in locking down we saw with newer S5 firmware So here, Roborock did block local firmware updates Improximately, this change was also pushed through other IoT devices from Xiaomi So most devices were basically blocking local firmware updates We saw more changes with the introduction of the Roborock S6, which came out in 2019 For example, the firmware and the voice packages were now signed So we were not able to create our own custom voice packages anymore Each model also used different encryption keys So if we had encryption keys for one model, we were not able to decrypt firmware for a different model They also started to sign the configuration files to enforce region locks As many people bought cheap devices from China and modified them So that we were able to use them outside of mainland China One interesting aspect is that most of the hardware remained mostly the same So most of the changes were basically just done in software All these changes meant that in order to get root access onto the device We needed to disassemble it One thing which we thought back then when the device came out That we might need to keep rooting method secret And so in the first two weeks when I got to Roborock S6 I was able to root it and then develop two different methods One where we extracted root password via UART and the obfuscated it So I could get access to Overseerio for example And the other way was that I booted into a single user mode And modified files there so that I had SSH access Back then I didn't publish the methods for some time As I assumed that Roborock would lock them down as soon as they know about them So this is what you had to do to get root access You had basically to solder wires to the test pads to get in the UART port With rooting we made some observations over time Every time we published a method it got blocked And here are some examples for blocking For example, local updates which we published in 2017 Were blocked in firmware updates 2018 The root password method which I published in 2019 Was blocked in newly produced devices back in 2019 And the UBIT bypass was fixed for new models in 2020 So there was one model which came out at this time And it was already patched This means basically that all current public methods are basically blocked Alright, let's talk about the development of Roborock models over time So we only will talk about global models There are way more models like in Mainland China But in this case I just want to talk about global models On the left side you see the size of the RAM On the right side you see the size of the flash And this becomes more important later In 2016 Xiaomi released the V1 Which was basically an OM product by Roborock Roborock released the S5 under their own name in 2017 In 2019 we saw more devices We saw the Roborock S6 and S6 Pure and the Xiaomi M1S Which was again an OM product In 2020 we saw the S4, S4 Max and S5 Max And their flagship model the S6 Max-V And this year we saw the Roborock S7 If you add the price when you see But higher prices do not really correlate with better hardware Also one thing which we noticed is that Manufacturers are recycling hardware in different models For example the Xiaomi vacuum robot has more or less the same hardware as the Roborock S4 The Roborock S5 and the Roborock S6 are more or less the same And as you can see on the bottom the S6 Pure, the S4 Max, the S5 Max and the S7 Have the same mainboard and more or less the same hardware too However the prices are very different from them As a conclusion one thing which we noticed is that the hardware gets weaker over time Despite the devices getting more expensive Roborock has two vacuum cleaners which are special Both of them contain a camera which is a little bit more critical in regard to privacy The first one is the M1S which was released in 2019 Instead of using an all-winner chip this one uses a rock chip quad core It has 525 megabit of RAM, 4 gigabyte of EMMC It has a LiDAR sensor which we already know from other models But in addition to that it has also an upward-facing black and white camera It does have an ultrasonic distance sensor in the front and infrared sensors To give you a perspective of the camera I record this video on a rooted vacuum cleaner And I use G-streamer for that The second model with the camera is the Roborock S6 Max-V This is currently the flagship model It was released in 2020 and contains a Qualcomm octa core SOC It has 1 gigabyte of RAM, 4 gigabyte of EMMC flash In addition to the LiDAR it has also two color cameras in the front Which are illuminated with infrared And it has the usual infrared sensors In the bottom left you can see the stereo camera of the device In the bottom it has the infrared illumination So this device we'll see in the dark On the right you find screenshots from the app As you can see the vacuum cleaner can actually detect objects and can avoid them This is also quite interesting again for privacy reasons If you look at the software of both devices both of them are very similar They use Android as the operation system And the controlling software for the robot is very similar to the previous models The software access the cameras via the video for Linux subsystem There are a lot of libraries which are used But the more interesting ones are OpenCV, OpenCL and the TensorFlow Lite Roborock learned from the past And added a lot of security measures to their device For example, SecureBoot is enabled And they make use of the replay protected memory block as a downgrade protection The system partition is integrity protected with DM variety So we cannot modify it Also a lot of partitions are encrypted with looks In particular all the application specific programs are stored on an encrypted partition The keys for this partition are stored in OPTIM Which is using ARM trust zone But there are more security features For example Roborock added a kernel-based verification of binaries All binaries before we get executed are checked for a correct signature This means we cannot really put any custom binaries on through the system Also they cited encrypted firmware updates This time each of the firmware versions has a different key The master keys itself are stored in OPTIM Which is using trust zone And interestingly they modified the IP tables binary Traditionally what we did for routing We removed all the firewall routes as soon as we root the device So we could access SSH and other tools However Roborock removed the ability of IP tables to flush or delete routes So as soon as routes are added to IP tables we cannot remove them anymore And they locked also UART So we cannot use UART to get root access All right we had some partitions which are especially interesting On on these devices which we need also later for our route There's the app partition which contains the device credentials and some other configuration files This partition is not protected by loops or dm-varity Then we have two copies of the system partition One of them is the active one, one of them is the passive one Both partitions are protected with dm-varity so we cannot modify them Then we have two application partitions Again one active and one passive copy Which are encrypted with loops However we are not integrity protected We have a reserve partition which contains the calibration data This one is again encrypted And we have the user data partition Which contains the lock files and the maps And it's again encrypted with loops So let's talk about the new routing methods for Roborock Currently there are three models of vacuum cleaners which have no public route This is the Roborock S7 which came out this year The M1S and the Max-V Let's start with the Roborock S7 So the Roborock S7 has more or less the same mainboard as the S5 Max, S6 Pure, etc However the problem is that they patched U-boots So we cannot use UART anymore to route it In addition to that the route of S is a read-only squash of S So even if you have access on a device we cannot modify the partition I developed a new method for this device Which is FEL Routing This method doesn't require any soldering However it requires still that the device is disassembled This method also automatically patches the route of S and enables SS8 And it applies to all current NAND based Roborock models In order to find a new routing method We need to reverse engineer the PCB We knew already where the UART pins were But they are useless after they blocked this functionality However all the all-winner socks have the so-called FEL mode FEL mode is a low-level mode which allows the flashing of the device And it is burnt in the SoC ROM so it cannot be modified The idea is to load a custom OS via FEL There are two typical methods to trigger the FEL mode First we can somehow disable the flash chip For example by grounding the clock However this method might be risky if you don't do it correctly And the second one is that we can pull the boot mode pin or trigger the FEL pin The problem with this is we need to figure out where this pin is So I got myself a spare PCB and did destructively disolder the SoC chip After I did that I probed all the pins And was able to find an incorrect pin For example like JTAG or the boot mode selection And by having this we can use it to trigger the FEL mode So how does this approach actually work? The challenge for all Winner Socks is that the NAND report is proprietary So we cannot use a mainline kernel or mainline uboot So my approach was the following I extracted a kernel configuration from the Roborock kernel I created my own init ramfs with drop here ss8 keys and some tools I compiled a minimal kernel using the nintendo nes classic sources The nintendo nes classic uses the same chip as the roborock vacuums I created my custom uboot version And with an extracted roborock configuration And I triggered the FEL mode by porting the tps17 This is the boot selection pin to ground Then I loaded the uboot kernel and the init ramfs into the ram And executed it After I did that my customer was booted Patched automatically the rootfs and I had root How does the pattern process exactly look like? First we need to boot into the FEL image Then we need to just decompress the squashfs After that we patched this image For example we installed the outerwise keyfile and the custom drop here server We compressed the image again and overroyed the partition with the new image And as a result we have ss8 access and root So what are the advantages of this new method? Well of course we don't need any soldering anymore We just can short the boot pin one time and we're good to go It's a very simple process and it also allows to restore brick devices Which was not possible before And also one important thing is that it can be used for all our winner-based vacuum cleaners So now that we have root for the rubarok s7 Let's take a look at the camera-based models So if you want to root the m1s and the maxb we have some issues First all the ports are closed to firebolt The fire systems are encrypted or integrity protected And the usb interface is also protected with some custom adbd So to get root access we need to have a layered approach First we need to break in via usb Then we need to disable the se linux and then patch the application partition And as an important note while it might be possible to root these devices It might be impossible for many people So don't expect it to be that easy as for previous models All right level one get adb shell If we connect over usb we need to do a challenge response authentication This application is based on a vinder secret Which we don't have So rubarok has it properly somewhere in a database The secret is also device specific Also the adb is controlled over a special configuration file Which we might need to modify All the files are stored under default protection and are thankfully not protected So our idea is the follows First we need to connect to the flash For example via insistent programming or by disordering it Then we need to create or extract the vinder secret And then we use a tool to compute the challenge response So for the m1s we can do insistent programming By soldering small wires on the bottom side of the pcb The pictures which you see here are from my experiments Where I used the sd card as a replacement for the emmc flash But the pinout is more or less the same As an important warning if you don't know what you're doing You likely will break your device So I tried both methods But I figured out isp is can be sometimes tricky So what I did instead is I used an adapter to read out a chip Which requires reflow soldering to remove the chip And reballing and then resoldering it again Okay what are the results of level one? I have a more detailed how to on my website However what I did here is I set the vinder secret to all use After I connected the device via usb I needed to extract the serial number from it So I ran adb devices The serial number is required for the challenge response process In the next step I asked the device for a challenge So as you see here I got like a random string back which is the challenge In the next step I used the tool vinder to generate the response So at this point I want to thank Eric Willman for his support And help to create this tool Before that I was computing the response manually But he extracted in Ghidra the function and just put it in a C program So now we can just run it from the shell The result of this program is basically the response And as soon as we have that we can just Run any commands which we want to do as you see here We have no shell access but as AlienOx is still enforced As AlienOx will prevent us from doing specific things even if we are rude For example the network access is blocked and we don't have any access to the dev directory So we cannot mount partitions or access devices However we can do two things We can do bind mounts and we can issue the kill command So the idea to disable as AlienOx just follows First we copy the MEO directory to a temporary location The MEO directory contains the Xiaomi cloud client Which is launched by the watchdog The watchdog has all privileges And it makes sure that if the MEO client is crashing that it gets restarted In the next step we replace the MEO client with a bash script which disables as AlienOx In the next step we mount this temporary location back to the original location If we now kill the MEO client The watchdog will restart our bash script instead of the real MEO client So hopefully as AlienOx gets disabled Let's take a look if this works also in practice In this case what we need to verify first that as AlienOx is actually enabled So with the get and pause command we get the response that it's enforcing In the next step we check the process ID of the MEO client process So we see the original process is running Now we copy the MEO folder to a temporary location And write our bash script into the client The client is not an alpha anymore instead it's a bash script Now we bind mount this folder to the original location And we kill the MEO client And now hopefully the bash script was executed And we can check it with get and pause And we see it's permitted So now as AlienOx is disabled Let's do level 3 We have now full root access however it's only temporarily So as in the moment when we restart a vacuum cleaner we lose root access So the good thing is the app partition is not integrity protected If you modify information is there then we don't have any issue By modification of a few scripts we can disable as AlienOx And start dropper on a different port The reason why we want to start dropper on a different port is that IP tables still blocks the port 22 As I mentioned before Ruborock modified the IP tables binary so that we cannot delete roots But instead we can just use a different port We are still limited by the ELF binary signature verification However we found a backdoor in this function If you give the binary a particular name then it has a white listed We can even point symbolic links to this binary Many thanks again to Eric Oman at this point which helped me to figure that out Let's do the demo again I want to run Valetudo on my robot Valetudo is a cloud replacement which allows to control your vacuum robot locally As you can see here I downloaded it with VGET into a temporary directory And I tried to launch it however I got a segmentation fault Typically segmentation faults happen if some libraries are broken However when I was looking at the kernel lock I saw that a very far ELF function kicked in and stopped the execution So now let's try a trick with the white list So we renamed the Valetudo binary to the white listed name As soon as we run the white listed name you see Valetudo is starting happily and everything works So now we have full root access and can run our own binaries on the system So some other ideas for this vacuum clears Well we can ask Opti nicely to decrypt firmware updates for us As we have root access and as we have stored a secure system Opti will happily decrypt firmware updates for us Also we can access the cameras directly For people who understand how TensorFlow Lite works You can take a look at the machine learning models of the vacuum cleaner I myself have no idea how this works so I didn't take a look at it And we can take also a look at the error back drawers So there are some hidden functions which wait only to be explored So as a summary about Roborock Well we have an easy method to root the S7 vacuum cleaner and some other models We have also a rooting method to root the M1S and Max-V However this method is dangerous in the likely brickier device It's mostly only feasible if you have decryptment and experience So regard this root as a proof of concept and that the technique can root its devices However I don't think that it will be useful for a lot of people As a general recommendation I think at this point I would say that we should try to avoid new Roborock models if you want to have root Part of the reason is that they lock down their systems And the other reason is that due to the weaker hardware We will run into resource issues if you try to run custom software onto them All right so beneath the new alternative and the great thing is There's a new player in the field of vacuum cleaners which is Dreamy Dreamy is the great alternative for us They released their first model in back in 2019 And they produce OM products also for Xiaomi They have four different kinds of vacuum cleaners which they produce The Xiaomi One C and the Dreamy F9 are V-Slam based models So they have a camera which is looking on the ceiling and they create a map by a bed The Dreamy D9 has a more traditional LiDAR sensor similar to the Roborock devices The Xiaomi One T has a V-Slam and time-of-flat camera So it can scan, it can pretty scan objects which are in front of it And the current flagship model is the Dreamy L10 Pro Which has LiDAR, a line laser and a camera All of these devices are based on various all-winner socks Dreamy uses for their devices a custom Android Which is mostly based on the Tina Linux which is provided by all-winner The company developed their own robotic software which is Ava So let's take a quick look on what kind of sensors you can access on these devices These pictures were recorded on rooted vacuum cleaners As you can see here there's a camera which is looking on to the ceiling And if you root your devices you are able to access these cameras The Xiaomi One T has an additional camera in the front which is a time-of-flat camera With that you get a point plot of objects which are in front of the vacuum cleaner The Dreamy L10 Pro uses line lasers to detect objects in front of it As you can see on the right the device creates two laser beams And if there's any object in front of the device the laser beam gets distorted The camera will pick up this distortion and will determine how far away the object is So let's talk about how we can root Dreamy The rooting of the device is surprisingly easy So I bought my first Dreamy robot when I was in China back in 2019 And it took me only a couple days to root the device The good thing is that all the devices have the same debug connector Which can be accessed without breaking any warranty seals I did do a lot of reverse engineering and I was able to extract the key material and firmware Also I reverse engineered ways to create proper FPL images So with the help of the banana pie tools which are also based on awinners socks I was able to create images which you can use to flag the devices To flag the device you need a portion to use a Windows only software which is phoenix usb There might be also ways to flash it over linux but I didn't investigate that So how does this debug interface look like? The debug interface has two times eight pins and it has a pitch set of two millimeter The two millimeters are way smaller than the typical jumper wires which you get If you plan to connect it with wires then make sure that you connect to the right pins The debug interface gives us a couple of interesting interfaces For example we have usb we have uart and we have the boot selection pin I saw that there's also like another uart there and likely jtech but I didn't investigate further To easily root the device we created custom PCBs which enable you to easily access the usb and uart There's a simple version which just gives you a usb and gives you the uart headers And there's an advanced version which has an onboard serial controller I want to thank at this point Ben Helfrich who created these boards in kycat and At the bottom of the slides you find a link to the gerber files Here are some big examples how you can connect them for example for the pcb you can insert it And you just have to make sure that you have the right orientation that you don't try the board And you can just connect ub and uart if you don't have this board You can also use jumplvirt but you need to be a little bit more careful and make sure that The connection is properly done On the bottom there's a diagram how you need to connect everything Let's talk about some interesting findings which I saw when I reverse engineered the dreamy firmwares So all the devices have an auto ssh backdoor this can be triggered from the cloud What this will do is it will create a reverse ssh shell to run off dreamy servers The interesting thing here is that they hardcoded the credentials to the server which is public facing The bigger problem is that this user which is used to create this reverse ssh has sudo writes on that server And it appears that the server is used for development I don't really know why we did that but this seems like a really really bad idea A scary thing which I found where they start up the bug scripts These scripts were downloaded over ftp from some personal developers nas These scripts are also executed at boot up for some devices The same the bug scripts are also uploading log files onto that nas And the admin credentials are in plain text in that script All of the vacuum cleaners have predictable root passwords For example devices with production firmware you can compute the root password from the serial number For devices with debug firmware there is only one valid password So knowing that it might be a bad idea to connect your vacuum cleaner directly to the internet I found also a lot of chatty functions The cloud api allows the execution of some debug functions for example Someone can trigger the recording in uploads of pictures Or the recording in uploads of camera records for devices with cameras And the device also produces a lot of log files The only way to prevent this uploads is basically rooting I don't know if these functions are used on the regular base by the developers But the fact that these functions exist is kind of scary As a summary about dreamy the devices are cheaper than roborock and they have also performance hardware This makes the devices the perfect target for rooting As I'm working on the rooting for quite a time already I was able to work with the developer valetudo on the support on the devices So I'm happy to announce that all dreamy devices so far are fully supported by valetudo since April 2021 All current models can be rooted without any soldering and this also applies to all devices released before August 2021 There will be some devices in the future. We don't know yet if they are rootable or not, but We will figure out very soon The DustBuilder is a website to build your own custom robot firmware You can create reproducible builds. It's easy to use especially for windows users In the past we had a lot of trouble with windows and mac users where building firmwares were kind of tricky So this tool kind of makes it way easier The DustBuilder works for dreamy roborock and biome devices And it's a perfect alternative to local building. However, if you don't trust it The tools will be still published on github You find the DustBuilder under builder.don'tvacuum.me At the end I want to thank a few people Which supported me in doing this presentation and doing the research I want to thank Ben Halfrich, Carolyn Gross, Cameron Kennedy, Danny Wiggema, Eric Ulman, Gavarno Beer and Zoan Bayer If you have any questions feel free to contact me by email, telegram or twitter Visit my website for any additional information or meet me here at Defcon if you're around If you happen to have a dreamy robot or plan to get a dreamy robot I have a couple spare PCBs with me which you can pick up for free Thank you very much and have a nice con