 All right, thank you very much for being here at 10 a.m. in the morning on a Sunday. Everyone who talked to me over the last past days, I always say, like, hey, don't go to the talks, just watch a live recording, but unfortunately, I need to be here. But great that you're here, so thank you very much. Yeah, so today I will do another vacuum robot talk, and this time we take a look at robots which have cameras. And I know this is like every two years, it's more or less sounds like the same talk, but sadly there's always a lot of development and the vendors are not the smartest ones, always. So C is just an update. All right, so some information about me, so that you have some idea what the heck I'm doing. I'm a PhD student in Boston at Northeastern University, and I primarily do research in wireless and embedded devices, so I'm interested in security and privacy. I think I call myself now also a vacuum robot collector because I have many, many, many of them. So some people collect stamps, I collect vacuum robots, and I'm interested in reverse engineering interesting devices, robots obviously, but right now I'm also looking at smart speakers, flash memory, everything which is kinda interesting, has internet and can do interesting things. Some of my past projects to give you some idea why I'm doing things, how I do them. Had like a paper some time ago about Amazon IQ devices where I did forensics, about like 87 or 86 use devices from eBay and was doing forensics on them. Let's say the outcome was not very good for Amazon. Some other things which I do right now is like flash forensics, so I look at embedded devices and see what kind of information I can extract from them. But I'm looking also at flash firmware itself, so flash memory has sometimes firmware onto it, and I'm looking if I can use it for something interesting. Another project which I run primarily is robotinfo.dev. This is like a website where you have like a systematic list of robots which I have, sorted by operation system sensors, vulnerabilities. My primary focus here is like security and privacy, and one of the things which I also do with that is also tracking of firmware changes. We will see later that tracking of firmware changes can be very, very useful and can save you a lot of time. Yeah, one of the source how I get my information is, I mean I have the devices myself and then as soon as it is connected from the cloud, I basically emulate them in the cloud, so the vendor thinks that they store online but I just use it to scrape the data. And this is also like a base for further research. As you can see in the picture, by the way, this is like one of my two or three shelves which I have, so I have from each of the robots which I route, I have like a reference model. If I need to test something, just go to my shelf, just grab one, test whatever I want and just put it back on the shelf. Which means I have no idea which robot cleans the best because I'm rude to them but I don't actually use them for cleaning, so. I get this question quite often, I have no idea. I have one which cleans, it's fine, so no idea about that. All right, so what's the goal of this talk? I want to give you some overview of the development of vacuum robot hacking over the last five years. I want to give you also some insight of vulnerabilities and vectors and I want to give you an idea about the current routing methods for current robots. The ultimate goal which we have typically is that we have root access at some point on a robot without disassembling it because disassembly is always warranty seals and stuff. One quick notice, we don't necessarily hate the robot companies, I mean, it's more like a competition. Sometimes I visited them and had a nice chat and next week I routed the devices. It's kinda nice, so it's a nice kind of thing. So what kind of devices were covered today in the talk? And there's a kinda long list, technically there's even a longer list but primarily we have the companies Roborock, we have Dreamy, a lot of things which I do today apply also to many, many, many other devices, not only vacuum robots, but lawnmowers, smart speakers and other things. All the devices which are underlined are ones which have cameras and the ones which are indirectly is like technically have it but it doesn't make sense for me to actually route it and develop tooling so if you want to port it, you can do it but yeah, just as information. So let's talk about this talk. So this talk is more or less the result of like 15 months of research and experiments so I do that for a very long time and it's a little bit annoying to sit on things for a very long time so if you know like, okay I can get access on this device but I can't tell anyone how. Which is very annoying. And also this talk is a collaborative effort between me and Zeran Bayer and Zeran is one of the, is the developer of Valetudo which is the cloud replacement for robots. So he plays a very, very important role in this endeavor. The other thing is all this work wouldn't be possible if you wouldn't have the community so we have thousands of people who are making robots and who are tinkering around with them. I cannot have every device so far and thankfully people are testing things and this is kind of great. As a general information in this talk, you learn about vulnerabilities the same time as the vendors do so right now I know that some companies in China are watching this talk live and I will get some emails afterwards but expect some patches coming in the next days so they don't know what we do so just this information. All right so what's the motivation for this talk? Well, why do we route devices in the first place and a lot of people think like okay I mean I can just use it, why the heck do I need to route it? Well, these devices are very, very cool hardware. Think of a Raspberry Pi on Tyres which has Tyres like cool sensors and can drive around to your apartment. It's a very compact nice unit which you can do a lot of experiments with. The other thing is we obviously want to stop devices from constantly phoning home and you will be surprised how much they phone home so it's like one device can produce hundreds of megabytes of lock files, maps, whatever every month which is like getting uploaded. So if you have some internet tariff which has limitations of like volume you might think about that. The other thing is a lot of people like to have some custom smart home solutions so like Home Assistant is one of the examples. It makes it way easier to obviously connect the device if you have a router device. A thing which becomes more and more important also with the right to repair. By routing devices or having the tools at least to be able to do so we can diagnose broken devices. Especially in US there's a problem that you have a warranty of one year and these robots tend to break after one year so it's very useful that we can figure out okay what's going on with devices. And we want to verify our privacy claims. Companies can say a lot of things if the day is long and marketing people can do that too but we want to actually know if it's true or not. So why don't we trust the nice companies and why don't we trust IoT? Well imagine this device is connected to your home network and has access to everything which is in your home if it's in the same network and it has its own internet connection basically to back to the cloud. Which means in most of the time the communication is encrypted and you have no idea what's sending back. It has cameras, it might have microphones it has a map of your home it can drive around on its own and you have no idea what's running on it. Also even if the vendor is not malicious developing secure hardware and software is really hard and if you remember the Mariah botnet where basically a lot of IP cameras got hacked and millions of basically botnets were created this is kind of like a thing where we want to just make sure that there's nothing which the vendor accidentally left in there and forgot about. And one of the things is also that a lot of vendor claims contradict each other and I have one perfect example for that. Which I always use so it's like if you were here two years ago you probably know it just for the newcomers. Roborock, I mean I shamed a little bit Roborock but all the companies do that by the way. They claim for their robots with cameras nothing is ever sent to the cloud. We will never duplicate data the data is not stored on the device and we don't send camera pictures to the cloud so you will say if the camera is just used to kind of detect objects. But if you scroll down on a page back then you find like oh by the way you can also access the camera remotely to watch your pets. So okay so you're not sending it to the cloud but I can still access it remotely so how does it work? Another thing which came out a couple months ago and there was also like a little bit involved in that. iRobot got caught that they basically upload pictures of cameras of robots to the cloud and then giga workers or gig workers in Venezuela kind of labeling them. So there's an interesting article I linked it also like in the foot line and so what happened is basically this were the development devices so people got free devices and had to sign some terms of service where we kind of agreed to that but no one actually knew that they agreed to that and so people started to kind of so this device has started to upload pictures and for whatever reason iRobot was very interested that you had like a fan and like lights and whatever in your apartment for whatever reason we wanted to have it labeled. A fun fact of that is as soon as the article came out or shortly before that a lot of vendors started to panic and I saw a lot of firmware changes and I saw a lot of changes in like privacy policies for all the companies. So they got really really spooked by that. Not that it actually changes a lot but I mean some of the firm has actually started to doing pictures because we got scared they get also caught like iRobot. The other interesting thing which we see nowadays is devices get more and more sensors and I have an example here from Echovox which we don't talk about this talk today but just as an example they have cameras but they started also to introduce microphones. We made like five years ago with Daniel Vigema who was starting this research with a joke like oh we can maybe try to use the ultrasonic sensor as a microphone so we can spy on people or we can use some other sensors to you know get like some audio information or like you know visual information. Nowadays we are here basically like oh we have cameras and microphones already on board so we don't need to kind of think of like sketchy ways to kind of get to the audio stream. Right, another thing which we need to talk about is what are the risks of devices with cameras. A lot of devices might store pictures indefinitely and basically both in the cloud and locally and from what I can tell so far is many do so so basically I have like a research project running where we look at you know what kind of data is like stored where and a lot of pictures are staying basically forever. The other thing which might be problematic is if you are a shopper at Amazon Marketplace and you get like used devices. I'm not sure if it's a good idea partially because whoever had the device before could have installed a root kit and you as a new owner you have no idea what's going on there so even if you do a factory set the malicious firmware might still be on with the result that you have a malicious firmware sorry malicious device in your network which has you know all the access. By the way if you learn today how to root devices done by Amazon devices root them and send them back that's evil that's bad that's hopefully I think that's illegal so don't do that very bad all right. So which means rooting is more or less the only way how you can verify that the device is clean so there's literally no other way to kind of know that. By the way the vendors are kind of aware that people and cybersecurity people are kind of scared of cameras so they try to avoid the word camera so instead you know they say like oh this device doesn't have a camera we have optical sensor and I have an article from like a German thing but a German page but there's also English speaking pages which have like you know marketing material from Roborock and I kind of said like well we don't have a camera in the actual sense we have an optical sensor which attacks a couple things. Well on the right you see an output of this optical sensor. This looks kind of to me like a picture but I mean it must be an optical sensor so yeah this is from a Roborock S8 Pro Ultra from the optical sensor so yeah don't believe marketing material. The other thing is everyone loves certifications so all the devices we're talking about today have some sort of certification by my favorite company in Germany TÜV which is certifying a lot of things of the days long and all of the devices are certified by the European cybersecurity standards for IoT products so I think because we're certified we can stop the talk here because we're secure I assume. Yeah so the takeaway lesson at some point just to kind of give you already like a spoiler is don't trust certifications we don't necessarily mean anything. All right so what happened so far in the past over the last five years? Well one of the general observations which I did was every time a routing method is presented or released the vendors react in one way or the other. Sometimes we even break things in the process so we saw in the past like a vendor which kind of panicked a little bit when we released the routing method and they created a firmware update which started to break hundreds of vacuum robots which we are not recoverable anymore so yeah. The best case for us if they fix things is that the routing method just fails that the device says like hey it's invalid I don't boot the worst case which is and some vendors do that actually they the routing succeeds but the device breaks randomly so you let it run it will stop randomly after five minutes or 10 minutes or whatever. We will show an example in the next slides where we saw that or the device might also destroy it themselves. So some we saw in one case where basically if the device attacks what it has been routed it will destroy itself which is bad. All right let's look in the past. So the first work of the vacuum cleaning which I was doing was in 2017 and this was together with Danny Wiggum who was by the way talk at 11 a.m. So if you're interested in I think he does ship sets like ridership sets then he has to talk in track three. And the robot which we were back when analyzing was the first generation of Xiaomi robots and the first generation of Roborock robots. Some of the things which we figured out is that the firmware updates are unsigned and encrypted with a very weak key which was I think the company name Roborock which wouldn't itself be an issue on its own. I mean that's kind of like not great but I mean the bigger problem was that you could push a custom firmware from the local network onto the device. And because the thing was kind of clear so the password was kind of known people could do that maliciously. You cannot only do that from the local network but you can do it also for unprovisioned devices. And I was telling the story like two days ago in my demo lab where I was in Germany and I saw one of the neighbors had a Roborock robot which was unprovisioned so it had an open Wi-Fi access point and I was like, I didn't do it. I just wanna say I didn't do it but you can do that. So make sure that your device is provisioned because otherwise someone else can provision it for you. Just a side note. Right, so what was the result? We could easily route devices because we could just push firmware updates and it was great for the development of like custom software and voice packages, right. And we published that at the CCC Congress in 2017 and I was giving a talk exactly five years ago on the day here at DEF CON. So it's a very long run of research. So after that Roborock was let's say not directly happy where he started to do a couple of things. For example, we blocked the local updates which was not necessary bad. I mean, I think from security perspective this was good. Then they started to introduce with newer models, firmware signatures and assigned also the voice packages and they used different keys for different devices. So we couldn't decrypt devices, firmware for different devices anymore with one key. One thing which we didn't like they started to assign files for a region lock. So if you buy a device from China you couldn't run it in US, they crack down on that. On the other side all the hardware remained the same. So if you buy a device like from five years ago and you buy a device from like two years ago they have more or less the same board, the same hardware. That's kind of a business model of generating revenue. The bad news after we fixed that was that we had to basically disassemble the devices and this is a little bit of a problem. So we developed a new routing method which worked for Rework S7, S5 Max, S7 and others. And the initial idea was, okay, we can just connect over UART and can do the UBOT shell thing so which you can do for many, many devices to get root access. However, we blocked that at some point and instead we developed a method where you can basically bring the device in bootloader mode and just start to patch the system from there. The disadvantage here was obviously we need to disassemble or potentially sort of things, so it's kind of a problem. One of the interesting facts is this method still works today for many, many devices which are based on the all winner R16 chip set. So even if you buy today newer RoboRock like the Q7 or something, it still works for whatever reason. So that's a good thing. After that, they started to react, obviously. One of the things is they removed the UBOT shell so that you couldn't do that. And for their flagship models, they started to introduce a lot of mean things. CQ boot, as Ali knows, the M variety, they put that in the firmware. And even newer models started to use encrypted file systems where the user data application was encrypted so you couldn't access machine learning models, you couldn't access anything which is on the device. And they started to put these keys into trust zone. So you need to boot in secure boot mode so that you can access the key. So they put a lot of effort in securing that. One thing which was very mean is they started to put like custom stuff in the kernel. For example, they added an elf binary signature check in the kernel so you couldn't run any unsigned binaries. Which is a little bit annoying if you got some way in and tried to run something you have and it's just like, yeah, it's not signed, so screw you. All right, so in 2021, again here at Defcon, I figured out a way how to bypass all this stuff. The initial idea was basically, I need to disassemble the device and modify the configuration partition which requires either EMMC disordering or ISP access so which is very, very complicated. So it's a thing which, you know, a very small percentage of people can do but it's very tricky. Also back in 2021, because we got a little bit tired with Roborock and their counter measurements, we figured out that there's a new vendor which is Dreamy. And their devices were kind of powerful because we had cameras and other things. They were easy to root just by a connector, by USB. But the problem was a little bit that the devices got soft break from time to time but we kind of fixed that. So what was the Roborock's reaction? Exactly one day after the Defcon talk, I got a nice email from the Roborock CEO. Thanks for the talk. Our engineers were watching the talk live so I assume they're watching it right now and they're fixing right now the vulnerabilities and pushing out the updates. So now what we do is like auto partitions are encrypted except for the system partition which they can't do for a particular reasons. They started the obfuscating of binary check verification. So it costs us more time to figure out what we do. And they added custom code to detect that we root devices and to bypass our traffic. So typically what we do is like we, when we disconnect the device from the cloud we reroute the traffic so that it ends up in our custom software. They figure out a way to detect that and basically still send out the traffic to the real Roborock servers. Which was very mean, I mean we figured it out but it was kind of like a little bit weird like, wait, rerouted the device? Why is it still sending stuff back home? So they basically put hooks, like obfuscated hooks in the libcurl library. So every time HTTP requests happening they match for, is it the Roborock URL? If it is, then do like a silent DNS check themselves and kind of send it like silently. And they are big fans of XOR. So they are XORed like everything out of like all the strings from all the binary. So they really want to make it hard for us but we don't use strings on the, you know, thing. As an example for their creativity, so they, like I mentioned before they added elf signature checks in the kernel and what they do is typically they map the, do mmmap function which creates I think the memory area for like a binary if you execute it. So if you execute like a unsigned binary you get just a secfault at the signatures in valid. And they got very creative with names. So I have an example here so they, this security function can be called like clock set rate DSP, clock get rate DSP and all the other names, right? So it's kind of like if you look at that you think like, oh yeah, I mean that's, you know, that needs to be there but in reality we try just to kind of be sneaky and obfuscate things. They get really, really creative with the names. But not creative enough. If you Google for these functions you don't find anything except for Roborock. So, well, maybe you should be a little bit more creative. Dreamy panicked also at this time. They were kind of new. They did a lot of changes to the firmware. So they pushed like one firmware update after another. They removed our U at lock-in show and they patched the Uboot show. And some of the changes apparently did break a lot of robots. There was like some kind of thing which we didn't test it properly. They pushed a firmware update and a lot of robots were kind of very sad afterwards. A fun fact is their patches revealed a way easier meta-to-rooted devices which we actually knew. So one thing which we do is typically we, you know compare all the firmware updates and see like, okay, what did they change? This happens fully automatic. And one thing which we noticed like, oh, they changed this thing. So typically we would kind of do like a sketchy way to like of flashing the robot by USB and the USB cable is kind of janky. It might break the robot so it's very, very dangerous. Then we saw that they patched a function out which basically if you press the reset button for like one second it will pop your shell. And we saw that and we were like, great, this is way safer because you are, I mean, you kind of break things that easily. So thanks, Dreamy, for telling us about this thing. So we weren't even aware of that. I mean, I didn't have any idea that this exists in there. In 2022 when we started to kind of more focus on Dreamy robots and root-based devices, they introduced more and more counter-measurements. One of them was that obviously they enabled secure boot and set if uses which was kind of to be expected. They started to sign the system partition in a weird way and verify it in a bootloader. And they started to pair the kernel with a particular version of file system which on itself is not a problem but the next step is kind of the annoying part. They introduced judge, we call it like that, counter-measure into the software. What was this, what is this judge doing? Well, they introduced it in all the firmwares in 2022 and it will randomly crash the robot whilst cleaning if it attacks the manipulation of the firmware. So what it does is it has like an expected char of 256 value and it baked into the kernel and the process, as soon as you start to run it, it will basically compute a hash of the system partition and compare them. If it doesn't match, it will basically create a thread which will allocate lots of, lots of memories. So after a random time, it's not even so that it's like three minutes, it can be 15 minutes, it can be anything, the robot will just stop and crash and reboot. And imagine how difficult it is to figure that out. It took us like weeks to figure out like wait, is this like a thing which is, we messed up something? Is it, what is it? Because there's no lock files, it's not reproducible like in a very efficient manner. Until on some point we figured out like, oh wait, this thing is happening and so we patch it out nowadays for like firmware which we kind of release. But this is extremely mean. This is like one of the cases where I'm saying like, okay, just tell us that we messed up, it's fine. Don't be sneaky and kind of annoy us with that. Okay, so what is the current state of robot security today? And have an example here which is probably one of the most or best protected robots so far in the market which is the Roborock S8 Pro Ultra which is I think the top on the stack. It's the current flagship model that came out a couple months ago. It has a quad core all-winner SOC and multiple MCUs. They got a little bit cheap so the initial models came out of one gigabit of RAM but at some point they figured out like, oh hey, we can get away with 512 so newer releases have like 512 megabit of RAM. They have four gigabit of flash, we have two cameras, lighter sensor and two lasers. Security-wise we kind of booked, checked everything in the book basically. Secure boot, the M variety, protected boot of S, looks and partitions as alien looks of signatures so the standard stuff what they have. Let me give you a quick intro how the booting process looks like and this is a very simplified version. I know at the end of the day it will look very, very complicated but just for you to understand, okay, what are we doing, what is our leverage. If the device boots up, it boots from a boot run which is baked into the SOC. It will then verify the first stage boot loader which initializes also RAM and the first stage boot loader will then check the signature of like a thing which is called talk one. This is just a technical term, ignore that for now. The talk one, what it will do is it will start the trust in components opti in this particular case which will then verify U-boot and launch the actual U-boot boot loader. The U-boot boot loader gets its configuration and basically for example which partition to boot and will launch and verify the Linux kernel. The Linux kernel itself will then verify the root file system and check if it's correctly signed and will start all the software which it will also check if it's correctly signed. So the software itself, the Elf binaries are signed. Then they use opti again to retrieve the keys for the system partitions and for the data partition and then we'll decrypt the software partition and user data partition. So there's a lot of stuff in there and it's like, all right, everything checks everything so what the heck are we doing here, right? Well, does it actually? There's one thing which is maybe not checked in a way it should be checked. Let's talk about the boot loader. So the U-boot boot loader is more or less the factor standard thing for embedded devices. It's a very powerful software. It set up some hardware at the boot up process. It sends the command line arguments for the kernel. It verifies the kernel in this particular case and boots it and it uses environment partition or configuration to configure itself. For example, it's used for if you want to update like a partition, you have typically two copies of a partition. If you want to update copy B, you can control it over U-boot. On the other side, U-boot has a very powerful command set. It can do a lot of things. For example, allowing to load partitions, access memory, changing memory because sometimes you need that to set up hardware. The thing which I was wondering about was like, huh, okay, it can access and change memory. I wonder if we can use that for something. So the idea was, can we ask U-boot nicely to modify itself? So the theory is if you have memory reads and writes, we might be able to overwrite instructions in the U-boot itself, which for example, checks verifies like the kernel signature. So we had to do a little bit of math. So we have to figure out like basically where is the actual signature function, which was a little bit tricky to figure out if you don't have the source code. Then we have to figure out the U-boot relocation offset because we, you know, there's some technical reason behind that. And so we need to figure out where is this function in the memory. And then at the end of the day, we figured out where it is and then we patched basically, we set two bytes in one particular memory location and the same as all the verifications forward after U-boot. The interesting thing is the device is still in secure boot mode. Nothing notices that something is going wrong. Everything is fine. So what's the consequence of that? And if we go back into our original example, if we have a malicious U-boot configuration, well, U-boot patches itself. So U-boot is compromised because we have U-boot compromised, we compromised the verification check, then we can compromise the kernel because nothing is checking it anymore. If you compromise the kernel, then the kernel doesn't check any more the root file system or the software. And because Opti never learns that anything bad happened, it will happily give us the keys which we need to do competitions and everything works. So this system is more or less crude. So what did we achieve of this small one line thing? We bypassed the secure boot process, we modified the kernel, which means we removed the deamvarity checks, we removed the alphbinary checks and we disabled SE Linux. And this allows us to modify the root file system. So we're back in the game, basically. And with that, we can also install custom software and get SSH access. The interesting thing is when we were playing around with this model, with this approach, I mean, it's kind of known that the environment positions is kind of like a problem, but most of the time people use it to kind of boot like their own shell scripts. But in this particular case, we can just patch the U-boot persistently and not only on raking robots, but we tested it also for smart speakers, media devices and many, many other devices. So if you happen to have a device which uses U-boot and which is kind of locked and you might want to try that, it's a little bit of effort in getting it to run initially, but it's definitely worth it. So we still have a problem. Well, how do we modify the environment? Because I mean, it's like on a flash, so we don't have access. Well, without root access, we can modify it directly. We cannot also modify the root file system, so we cannot put our custom software onto it. And we don't want to disorder the flash. So the good news is we found for the typical models different methods. For the older dreamy raking robots, we found the USB stick method, which again, they left us thankfully. For newer models, which came out very, very recently, we have like an FL root, like it's bootloader root. And for the Roborock models, we have the scary FL root, I will explain why we call it scary. So as a quick recap, if you have been here two years ago, dreamy thankfully has debug pins which are reachable from outside, so you can just move like a cover. It sounds a little bit scary if you kind of pull on it the first time, but it's very easily removable. It gives you UR, it gives you like USB, it gives you everything. The same as the case, I mean, we've never changed it. So even for the new models, for the R models, which are the ones which are came out after 2022, they still use the same thing. So again, a thing which we kind of figured out by looking at firmware updates, dreamy left us a nice back door. Basically, if you connect the USB stick, an empty USB stick, it doesn't matter what USB stick it is, to the USB port, it will pop a shell. And at some point, I think they plan to have some actual verification there, but as you see is, if the verification fails, it still gets your shell. So I think this was a work in progress and someone forgot about that. So that way we, as you see, it doesn't matter if it's doing anything or not, you will always get a shell. So after you get access basically to the shell, you can just patch environment and you're good to go. The sad news is for whatever reason, we have two branches and for the newer R models in 2022, they have like a more better check and so it doesn't work there. Instead, we developed this method where we basically bring the bootloader, so the device into a particular bootloader mode and then we have a weird sketchy firmware package which we install with a very sketchy software and it doesn't actually install any firmware, but it gives you like an interface to the flash and to some other system functions, which surprisingly, if you connect over USB in the bootloader mode, you don't need to have signed firmware. So you can execute unsigned codes over USB. You don't have access to trust zone, but that's fine for us. We just wanna have access to the flash and from there we could just modify the flash. So I have a whole two here. The technical process is a little bit complicated, but we did like lots of pictures and so don't worry. I mean, many people did that already, and tested it thankfully and didn't break their devices. Well, one did, but we fixed it so. It should be safe. At this time, it should be safe, I kinda promise. If you wanna get an adapter, I have some adapters with me. You can just grab one. Sadly, I got rid of 100 adapters two days ago in my demo session, but I still have some left. Otherwise, you find the Gerber Files on this website. Let's talk about this scary FAL route. The problem with Roborock is they didn't give us any exposed debug pins. We have only like USB available from outside, which we cannot really use. So the first approach which I typically do is, all right, I buy the device, I spend $1,000 and disassemble it and analyze it. I remove the SoC, which is like hundreds of pins and try to track down where which pin is. I remove also obviously the EMMC and read the EMMC out to kinda figure out what's going on. And then I start to map all the pins visually. So I use my favorite hacking software MS Paint and kinda overlay the pictures and rotate one so that I can basically trace down like, okay, this is the data line from the EMMC. It goes in this via and it comes out on the other side. As you can see, the picture is a little bit weird. It comes out from the other side and so you can basically connect these pictures. One thing that you figured out and Roborock was very, very great with layouting it. You can access all the EMMC data pins from the whole, from the button, which is you just remove the cover. There's just some rubber thing. You don't need to disassemble the robot. No warranty seals are broken. You can access the data pins from outside, which is great for us. So as you see, we have data zero, data one, and all the other pins, the clock, we have everything, which is very nice. So now we come to the scary part. We can use a needle to basically ground the data zero pin to connect the data zero pin to ground and that will bring the device into the bootloader mode and then we can just flash it from USB. So without disassembling, without touching any single screw, you can just scratch off a little bit of soda mask. You connect like a wire to it, just hold it and power it on and then it should be in the bootloader mode. So it's more of the same approach for the dreamy, so it's like just in this particular case, you need to be a little bit more scary. Why is it scary? Well, it requires removal of soda mask and you just scratch a little bit. If you're comfortable with that, you still need to tear it down, but if you're unsure, ask other users, there's a lot of people who do that. If you have a different robot from Roborock like a G10S, which is very often used in Russia right now, I heard, it's more or less the same process as for the other robots, but you need to disassemble it because we don't have any access from outside. I checked all the possibilities of like burning holes into the board, but sadly that doesn't work. So check also my website robot info for the pinouts and ask for help in the community. Right, what do we do with fruit access? So we have fruit access now in some way, so what do we do now? We defeated secure boot, we can run custom software, but what kind of software can we run and can we build our own software which kind of does everything? Well, we are a little bit lazy, so we actually, our main idea as well, we just wanna disconnect the cloud but keep all the vendor cleaning logic in place because I mean, we are not software engineers, so we just hackers, so we, you know, after what works, then you know, it's so fine. So if you get rid of the cloud, the robot should still work, but the problem is like, well, we don't have live maps, we don't have advanced features like map editing, so why did we even route it if we just cut the internet? So, and what happens if we need to redirect traffic? So the problem is like we use obviously secrets or keys and so we need to extract them from the robot and point it like to like a cloud emulation. So it's a little bit tricky, right? But we can do that. So the initial approach which we had was quite naive, so we just redirect DNS to our own software and you know, we just use IP tables, but Xiaomi kind of figured out that people do that, so they kind of introduce like hard coded IP addresses in their binaries. Our solution was basically to just, you know, replace their hard coded IP addresses with our hard coded IP addresses. So it just, just another step. So as you see, we're kind of aware of what we do and then we do the same things basically in reverse. Which means we can run our own software and we can redirect the traffic. And there's a great software which is Volaturo, which is a developer zone. It's a complete replacement of the cloud applications and the app itself. So you can run your vacuum robot completely offline with all the functionalities which the cloud and the app, so the smartphone app offers you. You can see live maps, you can edit the maps, you can change the robot configuration. It's a very responsive app interface. Gives you the API for a REST and it gives you MQTT functionality. For example, for Home Assistant. The problem is, I mean, that's not a problem. I thought it's not my personal thing, is zero in lives to write it in JavaScript and so no JS. I am not sure if it's the most performant thing is, but it works, so it's fine with me. Some screen shows just to give you like information on how it looks like. So you get actually the maps, you can do a lot of interesting things with that. The question is now, how do you get the custom firmware? I made something very, very easy which is called DustBirder. It's basically a website where you can let the website build the custom firmware for you. You just upload SSH key and do some other stuff and it will give you like a custom firmware which you can use when you push on your robot. The discurbs are technically public on your GitHub so you can just, you know, if you want to reproduce that, you can do that. So, last couple of minutes, that's the reason why I'm getting a little bit faster. What else did we find on the robots while we're doing this research? Well, all the cameras are, I mean, it's a Linux operation system on all the robots. So all the devices use the video for Linux subsystem and you can access the cameras through their device file basically. And some of the vendors were even nice enough to let some debugging tools to, you know, debug the camera on the device. And I just want to give you some examples here. This is a G10S from Roborock. I made self, so it's self-aware, it makes the selfie of itself and you see kind of like the quality again from the optical sensors. For the G10S Ultra, they gave it a RGB camera which is also nice. So you see again a selfie of a robot with the Defconn flag. And on the right, you see like what it typically sees with the camera if it kind of starts to detect AI with the AI objects in your house. And this is the same example for the Roborock S8. It has an infrared camera, so the sad thing is on the right as you see there, this looks a little bit bland. This is the blue elephant, so you cannot see the blue in the picture which is kind of sad, but it's okay. I mean, you still see that's the optical sensor see something, right? So something about the Dreamy, the good news is this year, we didn't find any SSH credentials to the backend in the firmware, so that's good. They made a lot of improvements of the software, but the bad news is they started to introduce a lot of telemetry and calling home functions which is a little bit sad. And they started to enforce geo-blocking by IP address. So if you buy a device from China again, you cannot use it anywhere outside of China. You need to kind of do some hacking, I guess. We were a couple problems. So all the vacuum robots, what they do for legal reasons is if you access the camera remotely, the robot will say like, oh, live view is in effect, so be careful or whatever. Which is kind of like a legal requirement. The problem is these audio files are kind of part of an audio packages and the audio packages are not signed or encrypted. So one thing you can do technically and don't do that because it's probably illegal in your jurisdiction. You can just overwrite this prompt, this warning prompt which the robot will kind of blare out every three minutes by an empty file and then you can access the camera without anyone noticing. But it's super illegal, don't do it. You can do it also for non-routed devices which might be a problem. One interesting thing is Dreamy kind of messed up by the way the firmware signatures. So we didn't really use that, but I mean, it's kind of interesting. So we use encryption and signing and the way how we do that is very interesting. The auto zip archive is encrypted with a static password. Then they created a random file which was signed with a private key and then they used the random file as a password for another zip archive inside of the whole thing which is basically the firmware. The problem is the actual firmware is not signed. The password is signed but not a firmware. So the thing is if you wanna create your own custom firmware updates, you just reuse the same password because it's already signed. So I think someone had a good, I don't know. I mean, we were not sure if it was a trick or if they kind of messed up. It was kind of a little bit weird. Anyway, so last two slides, as a summary, we have routing methods for the most current, so most of the current released dreamy and robot robots and technically some others too. We can bypass secure boot, we can bypass any other security mechanisms. We even route the devices which came out two weeks ago. So basically we are at the cutting edge here. We get persistence and we can run our custom firmware. Now we can validate and verify the vendor's claims and the bad news is some of them are tricky. But the interesting thing here is the takeaway message. Even if you're not doing any robot hacking, the bootloader attack is technically applicable for many, many different other devices. We saw it in, like I said, smart speakers and other things. And this routing allows us basically to do further research into IoT and AI because now we have access to the AI machine learning models and we can basically take a look and compare them like more in a more qualitative way. So the final notes. Do you not use your knowledge for bad things? I mean, I know people like to have to burn down, but please don't do that. Help us to help others. So if you have a routing PCB, share it with other people as soon as you're done. We will publish the tools in the next couple of years, some of the next couple of years, the next couple of days. So some of them are already public, some of them will be enabled in the next couple of hours when I'm kind of getting more cool down. So please be patient if some things are not public yet. If you happen to be a hardware I owe in the Netherlands in October or November, in the beginning of November, feel free to join me. I might be there with some new things about regarding robots, which are not these robots, but some completely new company. All right, final thing. I would like to thank Danny Bigema with whom I started to research. I would also thank Kivar Nabeer, Xion Bayer, which is obviously a developer, and also Mikhail Kalkin, and all the testers in the community. They were a lot of people who were sacrificed or nearly sacrificed their devices to test our routing methods. Thankfully, we have no brick devices so far, but I mean, it could have happened, and this would be kind of sad. I got an email from one of the people like, oh, my wife would kill me if I destroyed this device, so let's hope that it doesn't break. All right, and that's the end of my presentation. Thank you very much for being here again. I'll see you at 10 a.m. in the morning. Thank you.