DEF CON 29- Dennis Giese - Robots with lasers and cameras but no security Liberating your vacuum

00:11 - Before we start, here is some background information about me.

00:14 - I’m a PhD student at Northeastern University, and I’m working with Professor Guevera Noubir.

00:19 - Our research field is wireless and embedded security.

00:21 - My particular interest is in the reverse engineering of interesting devices.

00:26 - I focus on smart home devices, mostly vacuum cleaning robots.

00:29 - My current research is in the security and privacy of smart home speakers.

00:35 - In our most recent work, we analyze the security and privacy of used Amazon Echo devices.

00:39 - This paper was published on ACM WiSec this year.

00:46 - Let’s talk about the goals of this talk. First, I would like to give you an overview of the current development in rooting of vacuum cleaning robots.

00:53 - In particular, we will focus on Roborock and Dreame.

00:56 - We will talk about vulnerabilities and backdoors, and I will explain new methods, which you can use to root your device.

01:03 - As a general side note, I have no intention of bashing the companies.

01:07 - I like the products, and I think we have maintained a very friendly relationship.

01:12 - However, obviously our goals are slightly different.

01:17 - All right, let’s talk about our motivation.

01:20 - 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.

01:28 - This is especially interesting for people in education.

01:32 - Then we want to stop devices from constantly calling home.

01:36 - 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.

01:47 - And finally, you want to verify the privacy claims of the manufacturers.

01:53 - So why don’t we trust IoT? Well, IoT in general, they’re always connected to the internet and then your home network.

02:01 - The cloud communication is encrypted, and you don’t really know what kind of data is transmitted.

02:06 - From our experience we know that developing secure hardware and software is hard and that IoT devices are not always being patched.

02:13 - Also vendors sometimes contradict each other in regards of their privacy claims.

02:19 - And as an end user, you have no way to be sure.

02:23 - All right, here’s an example. Roborock claims for their flagship model that nothing is sent to the cloud, especially what is recorded by the camera.

02:32 - This claim was also certified by the German TUV.

02:35 - However, on the same website, they show that you can access the camera remotely from your phone.

02:39 - For example, you can watch your pets and talk to them.

02:43 - Let’s talk about the problem of used devices.

02:46 - A lot of people order devices on Amazon, try them and return them.

02:49 - So used devices are not that rare. As a buyer, you have no real information about the past of the device.

02:55 - So a malicious person could have installed a rootkit onto it.

02:59 - 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.

03:06 - So rooting is the only way for you to verify that the device is in fact in.

03:12 - All right, let’s take a look into the past, the good old times of rooting.

03:17 - My first work with vacuum cleaning robots was back in 2017.

03:21 - Here I’ve worked with Daniel Wegemer, and we were looking at the Xiaomi Vacuum clean robot and the Roborock S5.

03:28 - We figured out that the firmware images of just 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 a device without disassembly and develop custom software and voice packages for them.

03:45 - We published our findings on the 34C3 and back in 2017 and also on DEF CON exactly three years ago.

03:54 - Here we’d like to give you some short recap about the hardware of the Xiaomi vacuum robot and the S5.

04:01 - Both robots were running on quadcore CPU and have 512 megabytes of RAM.

04:07 - They had also 4gigabyte of eMMC flash. They had a lot of sensors and in particular, the most important ones are the lighter sensor on the top of the robot, the infrared sensor and the ultrasonic center.

04:19 - These devices also have some debug ports, for example, USB and UART, however, a USB was kind of protected and we never used this for anything.

04:28 - To give you some background information about the software.

04:31 - This device is run off Ubuntu 14. 04, mostly untouched.

04:35 - However, the vendors obfuscated a root password.

04:38 - Interestingly, the vacuum cleaners were controlled by the player software, which is basically an opensource robot device interface and server.

04:45 - So they used open-source software to run the devices.

04:48 - But a lot of proprietary software on them, for example, they use the custom adbd version which had some authentication so we couldn’t really use it.

04:57 - They run a custom watchdog, which make sure that the device didn’t crash, but on the other side also enforce copy protection.

05:03 - And they had a logging tool which uploads a lot of data to the cloud.

05:07 - They protected the ports on the device with IP tables, for example, they blocked port 22 for SSH and blocked also the player ports.

05:16 - However, the interesting thing was, that the IP tables rules only apply to IPv4.

05:22 - So if the device got an IPv6 address, it will not firewall at all.

05:27 - Alright, let’s look on how the forces strike back and how they started to lock down devices.

05:34 - Well, the first steps in locking down we saw with newer S5 firmware.

05:38 - So here Roborock did block local firmware updates.

05:43 - Interestingly, this change was also pushed through other IoT devices from Xiaomi so most devices were basically blocking local firm updates.

05:53 - We saw more changes with the introduction of the Roborock S6 which came out in 2019.

05:58 - For example, the firmware and the voice packages were not signed, so we were not able to create our own custom voice packages anymore.

06:03 - Each model also used different encryption keys.

06:06 - So if we had encryption keys for one model, we were not able to depcrypt firmware for a different model.

06:11 - 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 out of mainland China.

06:23 - One interesting aspect is that most of the hardware remained mostly the same so most of the changes were basically just done in software.

06:30 - All these changes meant that in order to get root access onto the device, we need to disassemble it.

06:38 - One thing, which we thought back when this device came out, that they might need to keep rooting method secret.

06:44 - And so in the first two weeks when I got the Roborock S6, I was able to root it and developed two different methods, one where we’re expected to root passwords via UART and they obfuscated it so I could get access to obviously UART for example, And the other way was, I booted into a single user mode and modified files there so that I had SSH access.

07:06 - Back then I didn’t publish the methods for some time, as I assumed that Roborock would lock them down as soon as we know about them.

07:13 - So this is what you had to do to get root access.

07:16 - You had basically to solder a virus to the test patch to get the UART port.

07:21 - With routing we made some observations over time.

07:24 - Every time we publish a method, it got blocked and here are some examples for blocking.

07:28 - For example, local updates, which we published in 2017 were from firmware updates in 2018.

07:33 - The root password method which I published in 2019 was blocked in newly produced devices back in 2019.

07:40 - And U-boot bypass was fixed for new models in 2020.

07:45 - So there was one model which came out at this time and it was already patched.

07:51 - This means basically that all current public methods are basically blocked.

07:57 - All right, let’s talk about the development of Roborock models over time.

08:02 - 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.

08:11 - On the left side, you see the size of the RAM, on the right side you’d see the size of the flash, and this becomes more important later.

08:18 - In 2016, Xiaomi released the V1, which was basically your end product by Roborock.

08:26 - Roborock released the S5 under their own name in 2017.

08:32 - In 2019, we saw more devices, we saw the Roborock S6 and the S6 Pure and the Xiaomi M1S which was again, OM product.

08:41 - In 2020, we saw the S4 Max and S5 Max and their flagship model, the S6 MaxV.

08:50 - And this year we saw the Roborock S7. If you had to price, then you see that higher prices do not really correlate with better hardware.

09:00 - Also one thing which we notice is that manufacturers are recycling hardware in different models.

09:05 - For example, the Xiaomi Vacuum Robot has more or less the same hardware as the Roborock S4.

09:10 - The Roborock S5 and the Roborock S6 are more or less the same.

09:15 - And as you can see on the bottom, the S6 Pure, the S4 Max, the S5 Max and the S7 have the same main board and more or less the same hardware too.

09:24 - However, the prices are very different for them.

09:28 - As a conclusion, one thing which we notice is that the hardware gets weaker over time despite the devices getting more expensive.

09:36 - Roborock has two vacuum cleaners which are special.

09:39 - Both of them contain a camera, which is a little bit more critical in regard to privacy.

09:45 - The first one is the M1S which was released in 2019.

09:49 - Instead of using an alternate chip, this one uses a Rockchip Quadcore, which has five megabytes of RAM, four gigabyte of eMMC.

09:56 - It has a lighter sensor, which we already know from other models, but in addition to that, it has also an upward facing black and white camera.

10:04 - It does have an ultrasonic distance sensor in the front and infrared sensors.

10:10 - To give you a perspective of the camera, I record this video of the room with vacuum cleaner, and I used Gstreamer for that.

10:20 - The second model with a camera is the Roborock S6 MaxV.

10:23 - This is currently the flagship model. It was released in 2020 and contains a Qualcomm Octocore as you will see.

10:29 - It has one gigabyte of RAM, four gigabyte of eMMC flash.

10:33 - In addition to the lighter, it has also two color cameras in the front, which are illuminated with infrared.

10:40 - And attach the usual infrared sensors. In the bottom left, you can see the stereo camera of the device.

10:46 - In the bottom it has the infrared illumination.

10:49 - So this device will see in the dark. On the right you find screenshots from the app.

10:54 - As you can see the vacuum cleaner can accurately detect objects and can avoid them.

10:58 - This is also quite interesting, again, for privacy reasons.

11:03 - If you look at the software of both devices, both of them are very similar.

11:08 - They use Android as the operating system and the controlling software for the robot is very similar to the previous models.

11:14 - The software access the cameras via the video4linux subsystem.

11:19 - There are a lot of libraries which are used, but the more interesting ones are OpenCV, OpenCL and Tensorflow Lite.

11:26 - Roborock learnt from the past and added a lot of security measures to their device.

11:31 - For example, secure boot is enabled and they make use of the replay-protected-memory-block as a downgrade protection.

11:37 - The system partition is integrity protected with DM-Verity so we cannot modify it.

11:42 - Also, a lot of petitions are encrypted with LUKS, in particular all the applications specific programs are stored on an encrypted partition.

11:50 - The keys for these petitions are stored in OPTEE which is using ARM TrustZone, but there are more security features.

11:57 - For example, Roborock added a kernel-based verification of binaries.

12:02 - All binaries before we get executed are checked for the correct signature.

12:06 - This means we cannot really put any custom binaries onto the system.

12:12 - Also the signed and encrypted firmware updates.

12:14 - This time, each of the firmware versions has a different key.

12:17 - The master keys itself are stored in OPTEE and using TrustZone.

12:22 - And interestingly, they modified the IP tables binary.

12:26 - Traditionally, what we did for rooting, we removed all the fiber roots as soon as we root the device so we could access SSH and other tools.

12:33 - However, Roborock removed the ability of IP tables to flush or delete rules so as soon as rules were added to IP tables, we cannot remove them anymore.

12:42 - And they locked also UART, so we cannot use UART to get root access.

12:49 - All right. We had some petitions which are especially interesting on these devices, which we need also later for our root.

12:58 - There’s the app partition which contains the device credentials and some other configuration files.

13:02 - This partition is not protected by LUKS or DM-verity.

13:06 - Then we have two copies of the system partition.

13:09 - One of them is the active one, one of them is the passive one.

13:12 - Both partitions are protective of DM-Verity so we cannot modify them.

13:16 - Then we have two application partitions, again one active and one passive copy, which are encrypted with LUKS, however we are not integrity protected.

13:24 - They have a reserve partition, which contains the calibration data.

13:27 - This one is again encrypted. and they have the user data partition, which contains the log files and the maps, and it’s again it’s encrypted with looks.

13:36 - So let’s talk about the new routing methods for Roborock.

13:40 - Currently they have three models of vacuum cleaners which have no public root.

13:44 - This is the Roborock S7 which came out this year, the M1S and the MaxV.

13:50 - Let’s start wit the Roborock. So the Roborock S7 has more or less the same main board as the S5 Max, S6 Pure etc.

13:58 - However the problem is that they patched U-boot so we cannot use UART anymore to root it.

14:03 - In addition to that, the RootFS is a read only Squash FS so even if you have access on the device, we cannot modify the partition.

14:10 - I developed a new method for this device, which was FEL rooting.

14:16 - This method doesn’t require any soldering, however it requires still that the device is disassembled.

14:21 - This method also automatically patches the root FS and enables SSH.

14:25 - And it applies to all current NAND based Roborock models.

14:31 - In order to find a new rooting method, we need to reverse engineer the PCB.

14:34 - We knew already where the UART pins were, but we are useless after they blocked this functionality.

14:40 - However, all the Allwinner SOCs have the so called FEL mode.

14:44 - FEL mode is a low-level mode which allows the flashing of the device.

14:47 - And it is burnt in the SOC ROM so it cannot be modified.

14:51 - The idea is to load a custom OS via FEL. There are two typical matters to trigger the FEL mode.

14:57 - First, we can somehow disabled the flash chip, for example, by grounding D clock, wherever this method might be risky if you don’t do it correctly.

15:05 - And the second one is, that we can pull the BOOT mode pin or trigger the FEL pin.

15:12 - The problem with this is we need to figure out where this pin is.

15:15 - So I got myself a spare PCB and did destructively de-solder the associate chip.

15:22 - After I did that, I probed all the pins and was able to find the incorrect pin.

15:27 - For example, like J-tech or the boot mode selection.

15:30 - And by having this, we can use it to trigger the FEL mode.

15:35 - So how does this approach actually work? The challenge for Allwinner SOCs is that the NAND support the proprietary.

15:42 - So we cannot use a main line kernel or mainline U-boot.

15:46 - So my approach was the following. I extracted a current configuration from the Roborock kernel.

15:50 - I created my own InitramFS with Dropbear, SSH keys, and some tools.

15:55 - I compiled a minimal kernel using the Nintendo NES classic sources.

15:59 - The Nintendo NES classic uses the same chip as the Roborock vacuums.

16:03 - I created my custom U-boot version and with a different extractor to Roborock configuration.

16:08 - And I triggered the FEL mode by shorting the TPA17, cause it’s the boot selection pin, to ground.

16:14 - Then I loaded U-Boot, kernel and the initramFS into the RAM and executed it.

16:20 - After I did that, my custom has booted, patched automatically the root FS and I had root.

16:27 - How does the patching process exactly look like? First we need to boot into the FEL image, then we need to just decompress the Squash FS.

16:35 - After that, we patched this image. For example, we installed the authorized key file and the custom Dropbear server.

16:41 - We compressed the image again, and overwrote the partition with the new image.

16:45 - And as a result we have SSH access and root.

16:49 - So what are the advantages of this new method? Well, first we don’t need any soldering anymore.

16:53 - We just can short the mode pin one time and we were able to go.

16:57 - It’s a very simple process, and it also allows to restore bricked devices, which was not possible before.

17:03 - And also one important thing is that it can be used for Allwinner based vacuum cleaners.

17:08 - So now that we have root for the Roborock S7, let’s take a look at the camera based models.

17:15 - So if you want to root the M1S and the MaxV, we have some issues.

17:21 - First, all the ports are closed or firewalled.

17:24 - The file systems are encrypted or integrity protected, and the USB interface is protected with some custom ADPD.

17:30 - So to get root access, we need to have a layered approach.

17:34 - First, we need to break in by USB, then we need you to disable the SElinux and then patch the application partition.

17:42 - And as an important note, while it might be possible to root these devices, it might be impossible for many people.

17:48 - So don’t expect it to be that easy as for previous models.

17:55 - All right, level one, get ADB shell. If we connect over USB, we need to do a challenge response authentication.

18:02 - This authentication is based on the VINDA secret, which we don’t have.

18:06 - So Roborock has it probably somewhere in a database.

18:10 - The secret is also device specific. Also the ADB is controlled over a special configuration file, which we might need to modify.

18:19 - All the files are stored on a default position and are thankfully not protected.

18:24 - So our idea is to follows. First, we need to connect to the flash, for example, via in system programming or by de-soldering it, then we need to create or extract VINDA secret.

18:35 - And then we use a tool to compute the challenge response.

18:39 - So for the M1S we can do in system programming by soldering small virus on the bottom side of the PCP.

18:46 - The pictures which you see here are from my experiments where I use the SD card as a replacement for the eMMC flash.

18:54 - But the pin on this model is the same. As an important warning, if you don’t know what you’re doing, you likely will break your device.

19:02 - So I tried both methods, but I figured out ISP access can be sometimes tricky.

19:07 - So what I did instead was I used an adapter to read out the chip, which requires reflow soldering to remove the chip and re-balling and then re-soldering it again.

19:19 - Okay, what are the results of level one? I have a more detailed how to on my website.

19:26 - However what I did here is I set the VINDA secret to or use.

19:30 - After I connected the device via USB, I needed to extract the serial number from it.

19:34 - So I ran ADB devices, the serial numbers required for the challenge response process.

19:39 - In the next step I asked the device for a challenge.

19:43 - So as you see here, I got like a random string back, which is the challenge.

19:47 - In the next step I used the tool VINDA to generate a response.

19:53 - So at this point, I want to thank Erik Uhlmann for his support and help to create this tool.

19:58 - Before that I was computing the response manually, but he extracted and got the function and just put it in a C program so now we can just run it from the shell.

20:12 - The result of this program is basically the response.

20:16 - And as soon as we have that, we can just run any commands which we want to do, as you see here.

20:25 - We have no shell access, but SELinux is still enforced.

20:29 - SELinux will prevent us from doing specific things.

20:31 - Even if we are root. 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.

20:39 - However, we can do two things. We can do bind mounts and we can issue the kill command.

20:45 - So the idea to disable SELinux is as follows.

20:49 - First we copied a miio directory to a temporary location.

20:52 - The miio directory contains the Xiaomi cloud client, which is launched by the watchdog.

20:57 - The watchdog has all privileges, and it makes sure that if the new client is crashing, that it gets restarted.

21:05 - In the next step we replaced the miio client with a bash script, which disables SELinux.

21:10 - In the next step, we mount this temporary location back to the original location.

21:15 - If we now kill the miio client, the watchdog will restart our bash script instead of the real miio client.

21:22 - So hopefully SELinux gets disabled. Let’s take a look if this works also in practice.

21:31 - In this case, what we need to verify first, is that is SELinux is actually enabled.

21:34 - So with the getenforce command, we get the response that it’s enforcing.

21:40 - In the next step we check the process ID of the miio client process.

21:43 - So we see the regular processes running. Now, we copy the miio folder to a temporary location and write our bash script into the client.

21:53 - The client is not an alpha anymore. Instead, it’s a beta script.

21:56 - Now, we bind mount this folder to the original location and we kill the miio client.

22:03 - And now hopefully the bash group has executed and we can check it with getenforce, and we see it’s permitted as SELinux is disabled.

22:12 - Let’s do level three. We have no full root access, however, it’s only temporarily.

22:17 - So as in the moment when we restart the vacuum cleaner, we lose root access.

22:22 - So the good thing is the app partition is not integrity protected.

22:26 - If you modify information there then we don’t have any issue.

22:30 - By modification of acute scripts, we can disable SELinux and start Dropbear on different port.

22:36 - The reason why we want to start Dropbear on a different port is that IP tables still blocks the port 22.

22:43 - As I mentioned before, Roborock modified the IP tables binary so that we cannot delete rules, but instead we can just use a different port.

22:51 - We are still limited by the ELF binary signature verification.

22:54 - However, we found a backdoor in this function.

22:56 - If you give a binary a particular name, then it is whitelisted.

23:00 - We can even point symbolic links to this binary.

23:03 - Many thanks again to Erik Uhlmann at this point, which helped me to figure that out.

23:10 - Let’s do the demo again. I want you to run Valetudo on my robot.

23:14 - Valetudo is a cloud replacement, which allows to control your vacuum robot locally.

23:19 - As you can see here, I downloaded it with we get into a temporary directory and I try to launch it.

23:25 - However, I got a segmentation fault. Typically segmentation faults happen if some libraries are broken.

23:31 - However, when I was looking at a kernel lock, I saw that the verify elf function kicked in and stopped the execution.

23:38 - So now let’s try a trick with the whitelist.

23:41 - So we renamed the Valetudo to the binary to the whitelisted name.

23:46 - As soon as we run the whitelisted name, you see Valetudo is starting happily and everything works.

23:51 - So now we have full root access and can run our own binaries on the system.

23:58 - So some other ideas for these vacuum cleaners, well, we can ask OPTEE nicely to decrypt firmware updates for us as we have root access and as we have still a secure system, OPTEE will happily decrypt firmware updates for us.

24:13 - Also, we can access to the cameras directly.

24:16 - For people who understand how TensorFlow light works, you can take a look at the machine learning models of the vacuum cleaner.

24:22 - I myself have no idea how this works so I didn’t take a look at it.

24:26 - And we can take also a look at the other backdoor.

24:28 - So there is some hidden functions which wait only to be explored.

24:33 - So as a summary about Roborock, well they have an easy method to root the S7 vacuum cleaner and some other models.

24:40 - We have also a rooting method to root the M1S and MaxV.

24:44 - However, this method is dangerous and will likely break your device.

24:48 - It’s mostly only feasible if you have the equipment and experience.

24:52 - So regard this root as a proof of concept and that we technically can root these devices.

24:58 - However, I don’t think that it will be useful for a lot of people.

25:02 - 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.

25:12 - Part of the reason is they lock down the systems.

25:14 - 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.

25:25 - All right. So we need a new alternative, and the great thing is there’s a new player in the field of vacuum cleaners, which is Dreame.

25:35 - Dreame is a great alternative for us. They released their first model back in 2019, and they produce OEM products also for Xiaomi.

25:43 - They have four different kinds of vacuum cleaners which they produce.

25:48 - The Xiaomi 1C and the Dreame F9 are VSLAM based models, so we have a camera which was looking on the ceiling and we create a map via that.

25:57 - The Dreame D9 has a more traditional, lighter sensor, similar to the Roborock devices.

26:04 - The Xiaomi 1C has a VSLAM and ToF camera so it can scan produce scan objects which are in front of it.

26:12 - And the current flagship model is the Dreame L10 Pro which has LiDAR and Line laser and a camera.

26:18 - All of these devices are based on various Allwinner SoCs Dreame uses for their device, a custom Android, which is mostly based on the Linux which has provided Allwinner.

26:29 - The company developed their own robotics software which is Ava.

26:35 - So let’s take a quick look on what kind of sensors you can access on these devices.

26:42 - These pictures were recorded on rooted vacuum cleaners.

26:45 - As you can see here, there’s a camera which was looking onto the ceiling.

26:49 - And if you root your devices, you’re able to access these cameras.

26:52 - The Xiaomi 1T has an additional camera in the front, which is a time of flood camera.

26:56 - With that you get a point note of objects which are in front of the vacuum cleaner.

27:01 - The Dreame L10 pro uses line lasers to detect objects in front of it.

27:07 - 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.

27:16 - The camera will pick up this distortion and will determine how far away the object is.

27:22 - So let’s talk about how we can root Dreame.

27:29 - The routing of the device is surprisingly easy.

27:31 - So I bought my first Dreame robot when I was in China back in 2019.

27:38 - And it took me only a couple of days to root the device.

27:42 - The good thing is with all the devices have the same debug connector, which can be accessed without breaking any warranty seals.

27:50 - I did do a lot of reverse engineering and I was able to extract the key material and firmware.

27:54 - Also I reverse engineered ways to create proper FEL with this.

27:59 - So with the help of the Banana Pi tools, which are also based on Allwinners SoCs, I was able to create those images which you can use to flag to devices.

28:08 - To flag the device you need unfortunately to use a Windows only software, which was Phoenix USB.

28:13 - There might be also ways to flash it over Linux, but I didn’t investigate that.

28:19 - So how does this debug interface look like? The debug interface has 2x8 pins, and it has a pitch set of two millimeter.

28:27 - The two millimeters are way smaller than the typical jumper wires which you get.

28:31 - If you plan to connect it with (indistinct) then make sure to connect to the right pins.

28:35 - The debug interface gives us a couple of interesting interfaces.

28:39 - For example, we have USB, we have UART and we have the boot selection pin.

28:44 - I saw that there’s also like another UART there and likely J tech, but I didn’t investigate further.

28:50 - To easily root a device, we created custom PCBs which enable you to easily access the USB and UART.

28:57 - 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.

29:06 - I want to thank at this point, Ben Helfrich who created these boards in (indistinct) and at the bottom of the slides, you find a link to the Gerber files.

29:16 - Here are some examples how you can connect them.

29:18 - 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 fry the board and you can just connect USB and UART.

29:29 - If you don’t have this board, you can also use jumper wires, but you need to be a little bit more careful and make sure that the connection is properly done.

29:38 - On the bottom there’s a diagram how you need to connect everything.

29:41 - Let’s talk about some interesting findings which I saw when I reverse engineered the Dreame firmwares.

29:49 - So all the devices have an ultra SSH backdoor.

29:52 - This can be triggered from the cloud. What this will do is it will create a reverse SSH shell to one of Dreame’s servers.

29:59 - The interesting thing here is that they hard-coded the credentials to the server, which is public facing.

30:04 - The bigger problem is that this user, which is used to create this reverse SSH has sudo rights on that server.

30:11 - And it appears that the server is used for development.

30:14 - I don’t really know why they did that, but this seems like a really, really bad idea.

30:21 - Scary thing which I found were the startup debug scripts.

30:25 - These scripts were downloaded over FTP from some personal developers NAS.

30:30 - These scripts are also executed at boot up for some devices.

30:33 - The same debug scripts are also uploading lock files onto that NAS and the admin credentials are implanted in that script.

30:46 - All of the vacuum cleaners have predictable root passwords.

30:50 - For example, devices with a production firmware, you can compute the root password from the serial number.

30:56 - For devices with debug firmwares, there’s only one valid password.

31:00 - So knowing that, it might be a bad idea to connect your vacuum cleaner directly to the internet.

31:06 - I found also a lot of chatty functions. The cloud IP allows the execution of some of the debug functions.

31:13 - For example, someone can trigger the recording and uploads of pictures or the recording uploads of camera records for devices with cameras.

31:22 - And the device also produces a lot of loc files.

31:25 - The only way to prevent these uploads is basically rooting.

31:29 - I don’t know if these functions are used on the regular basis by the developers, but the fact that these functions exist is kind of scary.

31:38 - As a summary about Dreame, the devices are cheaper than Roborock and they have also performance hardware.

31:45 - This makes the device as the perfect target for rooting.

31:48 - As I’m working on the rooting for quite quite a time already, I was able to work with the developer for Valetudo on the support on the device.

31:58 - So I’m happy to announce that all Dreame devices so far are fully supported by the Valetudo since April, 2021.

32:06 - All current models can be rooted without any soldering and this also applies to all devices released before August, 2021.

32:14 - There will be some devices in the future, we don’t know yet if they are routable or not, but we will figure out very soon.

32:22 - The Dustbuilder is a website to build your own custom robot firmwares.

32:25 - You can create reproducible builds. It’s easy to use, especially for Windows users.

32:30 - In the past, we had a lot of trouble with Windows and Mac users where building firmwares were kind of tricky.

32:37 - So this tool kind of makes it way easier. The Dustbuilder works for Dreame, Roborock and Viomi devices and it’s a perfect alternative to local building.

32:48 - Wherever if you don’t trust it, the tools will be still published on GitHub.

32:52 - You find Dustbuilder under a builder. dontvacuume.

32:58 - At the end I want to thank a few people which supported me in doing this presentation and doing the research.

33:04 - I want to thank Ben Helfrich, Carolin Gross, Cameron Kennedy, Daniel Wegemer, Erik Uhlmann, Guevara Noubir, and Soren Beye.

33:12 - If you have any questions, feel free to contact me via email, telegram or Twitter.

33:17 - Visit my website for any additional information or meet me here at Defcon if you’re around, if you happen to have a Dreame robot or plan to get a Dreame robot, I have a couple of spare PCBs with me which you can pick up for free.

33:30 - Thank you very much and have a nice Con. .