camp2023-57158-eng-Vacuum_robot_security_and_privacy_opus.vtt

WEBVTT

00:00:00.000 --> 00:00:10.000
 [MUSIC]

00:00:10.000 --> 00:00:20.000
 [MUSIC]

00:00:20.000 --> 00:00:33.000
 All right, good evening again, everybody.

00:00:33.000 --> 00:00:34.560
 How's everybody doing tonight?

00:00:34.560 --> 00:00:35.560
 >> [APPLAUSE]

00:00:35.560 --> 00:00:38.160
 >> Yay, wonderful.

00:00:38.160 --> 00:00:41.360
 However, I must tell you, it's already day four.

00:00:41.360 --> 00:00:43.240
 >> [APPLAUSE]

00:00:43.240 --> 00:00:44.840
 >> But to cheer us up,

00:00:44.840 --> 00:00:48.200
 we have a great last talk for today here at Millieways.

00:00:48.200 --> 00:00:51.560
 By the way, the Fettyverse hashtag, as always,

00:00:51.560 --> 00:00:55.120
 is #cccamp23millerways.

00:00:55.120 --> 00:00:58.600
 And who here in the crowd owns a vacuum robot?

00:00:58.600 --> 00:01:01.440
 >> [APPLAUSE]

00:01:01.440 --> 00:01:05.160
 >> I would say not great, not terrible.

00:01:05.160 --> 00:01:09.400
 But wow, I didn't expect that from a hacker crowd.

00:01:09.400 --> 00:01:13.280
 So then, especially for those of you who own one, the next talk is for you.

00:01:13.280 --> 00:01:17.720
 In the next 45 minutes, our speaker, Dennis Gieser,

00:01:17.720 --> 00:01:22.400
 will tell us all the latest news about vacuum robots, their security, and

00:01:22.400 --> 00:01:25.320
 their privacy issues, so that hopefully in the end,

00:01:25.320 --> 00:01:27.840
 your robot will not suck your data.

00:01:27.840 --> 00:01:30.360
 Please give a warm welcome to Dennis and enjoy the talk.

00:01:30.360 --> 00:01:36.600
 >> [APPLAUSE]

00:01:36.600 --> 00:01:39.440
 >> All right, welcome to my talk.

00:01:39.440 --> 00:01:42.640
 Thank you very much for being here at this late time.

00:01:42.640 --> 00:01:44.200
 It's great that you had four days of camp.

00:01:44.200 --> 00:01:48.200
 I mean, I came a little bit late because I had some stuff to do.

00:01:48.200 --> 00:01:51.600
 But it's kind of great here, except for a little bit warm.

00:01:51.600 --> 00:01:57.000
 So my talk today is kind of like an update about making robots security and

00:01:57.000 --> 00:02:02.280
 privacy, and I know people think, wait, that's always the same topic every two

00:02:02.280 --> 00:02:06.960
 years, but I mean, there's a lot of development, so let's do a quick update.

00:02:06.960 --> 00:02:14.400
 So for people who don't know me, which is the slides are kind of a little broken.

00:02:14.400 --> 00:02:19.000
 I'm a PhD student at Northeastern University, and

00:02:19.000 --> 00:02:23.240
 primarily my research field is in wireless and embedded security and privacy.

00:02:24.760 --> 00:02:28.720
 I think due to the amount of many, many robots, vacuum robots which I have,

00:02:28.720 --> 00:02:32.280
 I can call myself a vacuum robot collector.

00:02:32.280 --> 00:02:36.480
 So I think nowadays something like 45 robots.

00:02:36.480 --> 00:02:40.760
 And I have interest in the reverse engineering of interesting devices.

00:02:40.760 --> 00:02:43.760
 And this can be anything, I mean robots obviously, but

00:02:43.760 --> 00:02:48.880
 I've also like smart speakers, look at flash memory and other things.

00:02:48.880 --> 00:02:52.960
 Let me quickly ask this to format kind of weird, a little bit.

00:02:52.960 --> 00:02:58.040
 Is it my laptop?

00:02:58.040 --> 00:03:04.600
 >> It's your laptop.

00:03:04.600 --> 00:03:07.600
 >> Okay, let me fix that maybe real quick.

00:03:07.600 --> 00:03:20.000
 How many security experts do we need to fix issues?

00:03:20.000 --> 00:03:20.760
 Okay.

00:03:20.760 --> 00:03:22.600
 >> How many laptops?

00:03:22.600 --> 00:03:24.600
 >> Yeah, the laptop, it should be 6 x 8.

00:03:24.600 --> 00:03:34.600
 [BLANK_AUDIO]

00:03:52.800 --> 00:03:54.640
 >> Okay, great.

00:03:54.640 --> 00:03:57.320
 All right, perfect.

00:03:57.320 --> 00:03:59.040
 Working with experts, that's great.

00:03:59.040 --> 00:04:03.200
 Okay, so like I said, I am interested in vacuum robot smart speakers and

00:04:03.200 --> 00:04:05.920
 all other interesting IoT devices.

00:04:05.920 --> 00:04:10.960
 Some of my recent work is, some time ago I was looking at Amazon's smart speakers,

00:04:10.960 --> 00:04:15.760
 like EchoDots, and I bought 86 used EchoDots from eBay,

00:04:15.760 --> 00:04:18.000
 from other sources like Kleinenzeig in Germany.

00:04:18.000 --> 00:04:22.320
 I was doing some forensics, and let's say it was very bad news for Amazon.

00:04:22.320 --> 00:04:26.600
 So if you have used IoT devices, don't sell them, or

00:04:26.600 --> 00:04:29.120
 bad people like me might buy them.

00:04:29.120 --> 00:04:33.000
 Some other recent projects, I do a lot of flash forensics.

00:04:33.000 --> 00:04:36.440
 For example, on the left you see like the Pixel Watch, but

00:04:36.440 --> 00:04:39.800
 I look at embedded devices and see what kind of data I can extract from flash

00:04:39.800 --> 00:04:42.680
 memory, but also look at flash memory itself.

00:04:42.680 --> 00:04:46.880
 Surprisingly, a lot of flash memories have their own processor on them, and

00:04:46.880 --> 00:04:49.760
 you can hack the flash from there to maybe do malicious things.

00:04:49.760 --> 00:04:52.640
 So this is kind of like a current research project of me.

00:04:52.640 --> 00:04:55.480
 Another thing which I run is robotinfo.dev,

00:04:55.480 --> 00:05:00.640
 which is basically a website where I do a systematic analysis of robots.

00:05:00.640 --> 00:05:02.360
 For example, which operations system they're running,

00:05:02.360 --> 00:05:05.200
 what kind of sensors they have, if they have vulnerabilities or not.

00:05:05.200 --> 00:05:10.240
 The primary focus of that site is more or less to look at security and privacy.

00:05:10.240 --> 00:05:14.520
 And what I use it also for, kind of like in the back end,

00:05:14.520 --> 00:05:15.680
 to track for the changes.

00:05:15.680 --> 00:05:17.520
 So basically every time there's a new firmware update,

00:05:17.520 --> 00:05:22.120
 there's an automatic process which downloads it, extracts it, and compares it.

00:05:22.120 --> 00:05:24.320
 So we kind of get an idea of what the vendors are doing.

00:05:24.320 --> 00:05:29.920
 One of the sources how I get all this information is basically by buying

00:05:29.920 --> 00:05:33.440
 devices, disassembling them, and kind of start to emulate them.

00:05:33.440 --> 00:05:38.240
 So I have something like 50 or 60 emulated vacuum robots,

00:05:38.240 --> 00:05:41.240
 which are kind of behaving like real robots to the clouds and kind of just look

00:05:41.240 --> 00:05:43.560
 like, okay, do we get pushed firmware updates?

00:05:43.560 --> 00:05:44.280
 Is there anything new?

00:05:45.360 --> 00:05:48.080
 But also on the other side, what we do is we take a look at the app.

00:05:48.080 --> 00:05:50.600
 So we decompile the app and look if anything changes.

00:05:50.600 --> 00:05:53.760
 This is also the basis for further research.

00:05:53.760 --> 00:05:56.400
 I mean, for example, right now I'm working on machine learning models and

00:05:56.400 --> 00:05:57.000
 some other things.

00:05:57.000 --> 00:06:01.480
 By the way, the rack, which you see there is one of my few racks of robots.

00:06:01.480 --> 00:06:07.760
 So I keep a set of robots from basically a reference model from each of the models

00:06:07.760 --> 00:06:09.960
 which we support for routing.

00:06:09.960 --> 00:06:12.160
 And every time there's a new firmware update or if I need to check something,

00:06:12.160 --> 00:06:16.080
 I just go to the rack and just grab one and test the things which I need to test and

00:06:16.080 --> 00:06:17.720
 just put it back.

00:06:17.720 --> 00:06:21.840
 Which also means, and I get this question quite often also on Twitter or X,

00:06:21.840 --> 00:06:26.800
 or via email like, hey, I want to buy a vacuum robot, which cleans the best?

00:06:26.800 --> 00:06:29.400
 I have no idea.

00:06:29.400 --> 00:06:33.080
 I root those devices, but I mean, I'm not actually using them except for one which

00:06:33.080 --> 00:06:37.320
 I use and it does the job good enough, so I have no idea.

00:06:37.320 --> 00:06:40.360
 So don't ask me which one is the best for cleaning X, Y, and Z.

00:06:41.400 --> 00:06:44.400
 All right, so what is the goal of this talk?

00:06:44.400 --> 00:06:47.720
 Well, I want to give you an overview over the development of the vacuum robot

00:06:47.720 --> 00:06:50.160
 hacking over the last five years.

00:06:50.160 --> 00:06:53.840
 And I want to give you some idea about vulnerabilities and

00:06:53.840 --> 00:06:55.840
 backdoors which exist today.

00:06:55.840 --> 00:07:00.080
 And give you some understanding about which routing methods we have.

00:07:00.080 --> 00:07:04.520
 The ultimate goal typically which I have is to get root access onto a device with

00:07:04.520 --> 00:07:05.440
 all this assembly.

00:07:05.440 --> 00:07:10.520
 Sometimes it works, sometimes it doesn't work, but we try our best to find ways and

00:07:10.520 --> 00:07:12.280
 sneak ways around to kind of get root access.

00:07:12.280 --> 00:07:20.920
 As a side note, generally we have some, I mean,

00:07:20.920 --> 00:07:23.840
 me and the vendors don't hate each other necessarily, but

00:07:23.840 --> 00:07:26.320
 the thing is we have a very competitive kind of setting.

00:07:26.320 --> 00:07:28.840
 So every time they fix something, we fix something, and

00:07:28.840 --> 00:07:30.520
 it's kind of like always competitive thing.

00:07:30.520 --> 00:07:33.440
 So I know, for example, when I was giving this talk at DefCon, but

00:07:33.440 --> 00:07:37.440
 they were watching live and right now we're probably working on firmware updates.

00:07:37.440 --> 00:07:43.000
 So yeah, so some of the devices which are covered in this talk,

00:07:43.000 --> 00:07:46.880
 they are the current Roborock vacuum robots.

00:07:46.880 --> 00:07:49.320
 Some of them just came out kind of very recently.

00:07:49.320 --> 00:07:52.120
 They are more or less all the dreamy robots,

00:07:52.120 --> 00:07:55.440
 like all the new generation, like our generation vacuum robots.

00:07:55.440 --> 00:08:00.400
 We have also a new routing method for all the older ones which came out like one and

00:08:00.400 --> 00:08:04.440
 a half years and before that, so the so-called P models.

00:08:04.440 --> 00:08:09.320
 And everything you see here can be also technically applied to other robots,

00:08:09.320 --> 00:08:13.680
 for example, Dnava robots which are more used in America.

00:08:13.680 --> 00:08:17.680
 Shark AI robots and also some lawn mowers like the ZEGWay.

00:08:17.680 --> 00:08:22.720
 Everything which is like underlined is basically robots which have like cameras

00:08:22.720 --> 00:08:24.080
 which you can access in one way or the other.

00:08:24.080 --> 00:08:29.760
 Right, as a general thing is, I mean, why we just as a comment kind of,

00:08:29.760 --> 00:08:32.800
 why we jumping around on Roborock and dreamy, why not iRobot?

00:08:32.800 --> 00:08:36.840
 The thing is, surprisingly Roborock and dreamy have some of the best value

00:08:36.840 --> 00:08:38.920
 propositions in terms of features and price.

00:08:38.920 --> 00:08:44.120
 But iRobot nowadays, they're very, very good in reducing the amount of hardware

00:08:44.120 --> 00:08:47.720
 which we put into the devices to make it barely work for the use case which it's

00:08:47.720 --> 00:08:51.360
 used to, which means it doesn't make any sense to root them because we don't have

00:08:51.360 --> 00:08:53.440
 any resources anymore to run our own stuff on them.

00:08:53.440 --> 00:08:57.040
 So there's a particular reason why, I mean, technically I have rooted these devices,

00:08:57.040 --> 00:08:58.880
 but I'm not touching them basically.

00:08:58.880 --> 00:09:02.720
 Okay, so about this talk.

00:09:02.720 --> 00:09:06.760
 The result which you see here will be basically the result of 50 months of

00:09:06.760 --> 00:09:10.960
 research and experiments, which is a little bit annoying in the sense of like

00:09:10.960 --> 00:09:14.680
 if you're sitting for this long time on kind of, I wouldn't say zero days,

00:09:14.680 --> 00:09:18.160
 it sounds always like very important, but on vulnerabilities which you can tell

00:09:18.160 --> 00:09:20.960
 anyone and disclose to anyone because basically as soon as they get burned,

00:09:20.960 --> 00:09:21.800
 they basically get burned.

00:09:21.800 --> 00:09:26.640
 This talk is collaborative effort with me and Zun Baeyer.

00:09:26.640 --> 00:09:30.200
 And Zun Baeyer is the developer of ValleTudo.

00:09:30.200 --> 00:09:34.600
 Traditionally, we had the separation of me doing all the routing part and

00:09:34.600 --> 00:09:38.040
 all the hardware stuff and he's basically taking care of the cloud replacement,

00:09:38.040 --> 00:09:38.920
 ValleTudo.

00:09:38.920 --> 00:09:43.240
 Nowadays, we're kind of like, he's also going into routing part because

00:09:43.240 --> 00:09:47.320
 that's the cooler part and he wants to enjoy his life too.

00:09:47.320 --> 00:09:51.800
 So we would be also here if it wasn't the community.

00:09:51.800 --> 00:09:56.160
 So a lot of people from the community support us by testing routing methods,

00:09:56.160 --> 00:09:59.560
 giving feedback to about software, catching things which we

00:09:59.560 --> 00:10:03.120
 messed up potentially, donating devices, donating money.

00:10:03.120 --> 00:10:04.840
 So there's a lot of support from the community.

00:10:04.840 --> 00:10:11.000
 Typically what we do is we don't disclose things to the vendors.

00:10:11.000 --> 00:10:14.600
 So the vendors are kind of unaware of the findings.

00:10:14.600 --> 00:10:17.800
 Well, technically not today because I gave this talk basically at DefCon like

00:10:17.800 --> 00:10:18.400
 five days ago.

00:10:18.400 --> 00:10:22.120
 So they basically weren't aware five days ago and we didn't see any updates so

00:10:22.120 --> 00:10:26.680
 far, so we are still working on that, I assume.

00:10:26.680 --> 00:10:30.240
 But expect firmware updates and patches over the next couple days, I assume.

00:10:30.240 --> 00:10:33.360
 Okay, so what's the motivation of this talk?

00:10:33.360 --> 00:10:36.000
 So why the heck do we want to route devices?

00:10:36.000 --> 00:10:39.520
 Well, one of the things is, for me at least,

00:10:39.520 --> 00:10:41.600
 when I started that is to play with cool hardware.

00:10:41.600 --> 00:10:44.880
 These devices are very powerful.

00:10:44.880 --> 00:10:49.640
 It's basically, imagine for a Raspberry Pi or a smartphone on tires,

00:10:49.640 --> 00:10:52.320
 very compact driving around here in your house.

00:10:52.320 --> 00:10:55.640
 So it's a very interesting platform for devices.

00:10:55.640 --> 00:10:57.920
 The other thing is because it's so powerful,

00:10:57.920 --> 00:11:01.600
 I want to basically stop the devices from constantly phoning home.

00:11:01.600 --> 00:11:05.840
 And phoning home is kind of a thing with these devices, so

00:11:05.840 --> 00:11:09.200
 you can expect a couple hundred megabytes per month in telemetry data,

00:11:09.200 --> 00:11:09.960
 pictures, whatever.

00:11:09.960 --> 00:11:17.680
 The other thing is if people want to use custom software like Home Assistant,

00:11:17.680 --> 00:11:22.240
 it's very, very difficult to integrate these devices in that system

00:11:22.240 --> 00:11:24.080
 without relying on the clouds.

00:11:24.080 --> 00:11:27.920
 And sometimes the cloud can also go down, so there's a lot of problems.

00:11:27.920 --> 00:11:31.400
 One thing which becomes more and more important nowadays is diagnosis of

00:11:31.400 --> 00:11:32.200
 broken devices.

00:11:32.200 --> 00:11:36.560
 This is not necessarily, I mean, it's still an issue in Europe, but

00:11:36.560 --> 00:11:39.080
 in America you have a warranty period of one year.

00:11:39.080 --> 00:11:42.400
 And these devices tend to break exactly after one year.

00:11:42.400 --> 00:11:47.720
 And so a lot of people in the US have the issue, okay, we cannot get it

00:11:47.720 --> 00:11:50.800
 repaired under warranty, so we need to find a different way and we can help out

00:11:50.800 --> 00:11:54.760
 people by diagnosing what kind of things might be broken.

00:11:54.760 --> 00:11:59.920
 And the thing which is related to my research is basically to verify the

00:11:59.920 --> 00:12:01.920
 privacy claims of the vendors.

00:12:01.920 --> 00:12:08.360
 So why do we don't trust the great companies who develop these nice IoT

00:12:08.360 --> 00:12:09.200
 products?

00:12:09.200 --> 00:12:12.720
 Well, if you think about these devices, these devices are directly connected to

00:12:12.720 --> 00:12:16.520
 your home network and can talk to everything typically in your home and

00:12:16.520 --> 00:12:18.600
 have some internet connection.

00:12:18.600 --> 00:12:22.880
 I know some people put them in some VLANs and stuff like that, but

00:12:22.880 --> 00:12:26.200
 I mean, let's be realistic, most like 99% of the users probably just put them in

00:12:26.200 --> 00:12:27.680
 their normal Wi-Fi and call it a day.

00:12:27.680 --> 00:12:32.120
 The communication to the cloud is encrypted and

00:12:32.120 --> 00:12:33.680
 you have no idea what the content is.

00:12:33.680 --> 00:12:37.560
 Also, even if the vendor is not malicious,

00:12:37.560 --> 00:12:39.440
 developing secure hardware and software is hard.

00:12:39.440 --> 00:12:42.680
 So nothing says that the vendor can get hacked at one day or that there's some

00:12:42.680 --> 00:12:46.520
 weird kind of vulnerability in the device which can be used remotely.

00:12:46.520 --> 00:12:50.240
 If you remember the Mirai botnets many, many years ago,

00:12:50.240 --> 00:12:53.520
 which basically where IP cameras got hacked from the internet and

00:12:53.520 --> 00:12:55.160
 create like a huge botnet.

00:12:55.160 --> 00:12:58.040
 So we want to kind of figure out if there's some hidden vulnerabilities which

00:12:58.040 --> 00:13:01.000
 the vendor didn't put in on purpose but which exist there.

00:13:01.000 --> 00:13:06.680
 And one of the things why I'm a little bit paranoid is because vendor claims

00:13:06.680 --> 00:13:07.640
 might contradict each other.

00:13:07.640 --> 00:13:14.040
 So I have my favorite go-to example for claims of vendors and

00:13:14.040 --> 00:13:17.680
 I use always Roborock but technically all the other vendors do more or less the same thing.

00:13:17.680 --> 00:13:22.440
 Roborock claim for the S6 Max-V like hey, it's built for privacy,

00:13:22.440 --> 00:13:24.520
 it's certified by the TIF, my favorite company.

00:13:24.520 --> 00:13:27.840
 Nothing is ever duplicated, nothing is ever stored,

00:13:27.840 --> 00:13:30.840
 nothing is ever sent to the cloud, the cameras are only used for AI detection.

00:13:30.840 --> 00:13:34.840
 It never leaves the robot, everything is fine, trust us please.

00:13:34.840 --> 00:13:37.440
 But if you scroll down a little bit more, it says by the way,

00:13:37.440 --> 00:13:41.640
 you can watch your pets remotely from your phone and can talk to it and

00:13:41.640 --> 00:13:44.720
 you can see what's going on in your home and you can drive around in your home and

00:13:44.720 --> 00:13:46.680
 basically watch if everything is okay.

00:13:46.680 --> 00:13:50.040
 So now the question is like okay, on one side nothing is ever sent to the cloud and

00:13:50.040 --> 00:13:53.240
 it's not possible to access the camera, basically the pictures, but

00:13:53.240 --> 00:13:55.480
 on the other side you can access it remotely, so what is it?

00:13:55.480 --> 00:14:00.120
 As a side note, I mean there's different ways to interpret what the exact thing is,

00:14:00.120 --> 00:14:01.760
 but I mean it's very, very unclear here.

00:14:01.760 --> 00:14:09.680
 The other thing is I recently caught how they uploaded pictures of users,

00:14:09.680 --> 00:14:14.040
 well, development devices basically which they gave away for free to users to the

00:14:14.040 --> 00:14:17.680
 cloud and where they used gig workers in Venezuela to kind of label them.

00:14:17.680 --> 00:14:22.240
 Which was a little bit unsettling because most of the users didn't realize that

00:14:22.240 --> 00:14:24.840
 it's somewhere hidden in the terms of service, but the pictures would be used by

00:14:24.840 --> 00:14:28.920
 people and some pictures which were uploaded were like people sitting on the

00:14:28.920 --> 00:14:31.880
 toilet, naked kids, whatever, you can be creative.

00:14:31.880 --> 00:14:35.600
 I have some examples from the MIT Tech Review article.

00:14:35.600 --> 00:14:38.920
 I was helping the journalists to figure out which device it was because I have

00:14:38.920 --> 00:14:43.560
 from all the devices to camera perspective, so I really quickly figured out it's iRobot.

00:14:43.560 --> 00:14:45.680
 And it turned out to be actually iRobot.

00:14:45.680 --> 00:14:49.320
 And the question is why do we need to know what kind of AC you have,

00:14:49.320 --> 00:14:50.840
 what kind of switches you have and everything else?

00:14:50.840 --> 00:14:56.720
 So this is basically the stuff which was labeled in Venezuela from the gig workers.

00:14:56.720 --> 00:15:00.720
 As a small fun fact, as soon as the article came out or

00:15:00.720 --> 00:15:03.520
 as soon as the journalists actually started to send out requests to all the vendors and

00:15:03.520 --> 00:15:07.280
 asking about them, that things, many of the vendors panicked and

00:15:07.280 --> 00:15:11.280
 started to change their firmwares, apps and also privacy policies.

00:15:11.280 --> 00:15:16.200
 So you see a lot of privacy policies being changed around November, December 2022,

00:15:16.200 --> 00:15:17.080
 which is kind of interesting.

00:15:17.080 --> 00:15:20.760
 The other thing, which is a motivation for me also,

00:15:20.760 --> 00:15:23.520
 these kind of devices have more and more sensors.

00:15:23.520 --> 00:15:27.360
 So, I mean, at some point we got cameras, which is kind of bad.

00:15:27.360 --> 00:15:29.920
 But nowadays some of the robots have even microphones.

00:15:29.920 --> 00:15:31.920
 And one of the things which I want to mention here is like,

00:15:31.920 --> 00:15:34.480
 when we started five years ago, we were kind of joking like, okay,

00:15:34.480 --> 00:15:41.640
 we tried to find a way to use the ultrasonic sensor to basically listen to people.

00:15:41.640 --> 00:15:45.120
 Or maybe you can use some other sensor to kind of spy on people.

00:15:45.120 --> 00:15:46.960
 But nowadays you don't need to do that.

00:15:46.960 --> 00:15:50.200
 The robots come with microphones themselves.

00:15:50.200 --> 00:15:53.280
 As a quick note, I know there's some papers out there which claim that you can use

00:15:53.280 --> 00:15:58.840
 the ladder to snoop on people by flashing the firmware and stuff like that.

00:15:58.840 --> 00:16:02.120
 But I can tell you today that it's not possible that the paper is more or

00:16:02.120 --> 00:16:02.760
 less not accurate.

00:16:02.760 --> 00:16:06.800
 So I know it's out there, but shocker in academia,

00:16:06.800 --> 00:16:10.200
 people might be not super accurate with papers.

00:16:10.200 --> 00:16:13.720
 So you cannot use the ladder as a microphone, just as a hint.

00:16:13.720 --> 00:16:16.560
 All right, so what are risks of devices with cameras?

00:16:16.560 --> 00:16:20.160
 Well, some of the devices might store pictures indefinitely.

00:16:20.160 --> 00:16:24.720
 Sad news is also a lot of them do both in cloud and locally.

00:16:24.720 --> 00:16:27.520
 There's some ways how I was able to figure that out.

00:16:27.520 --> 00:16:31.160
 So far I can't tell you exactly which companies there are, but there's some.

00:16:32.320 --> 00:16:37.200
 Also, if you buy used devices from, for example, Amazon Marketplace,

00:16:37.200 --> 00:16:39.280
 you need to be a little bit careful.

00:16:39.280 --> 00:16:41.360
 You don't know what was installed previously on the device.

00:16:41.360 --> 00:16:45.400
 So the previous user might have installed a rootkit.

00:16:45.400 --> 00:16:49.280
 The new owner cannot verify the software, and as a result,

00:16:49.280 --> 00:16:51.200
 you might have a malicious device in your network.

00:16:51.200 --> 00:16:53.800
 So we are in a hacker conference, and I just want to say it's super illegal to do

00:16:53.800 --> 00:16:54.640
 that, so don't do that.

00:16:54.640 --> 00:16:58.920
 Don't buy devices on Amazon and root them, put some rootkit onto that, and

00:16:58.920 --> 00:17:00.160
 send it back to Amazon.

00:17:00.160 --> 00:17:03.400
 That's very rude and probably illegal, I assume.

00:17:03.400 --> 00:17:05.040
 I hope so, at least.

00:17:05.040 --> 00:17:09.680
 Okay, so rooting is more or less the only way how you know that the device is clean

00:17:09.680 --> 00:17:10.080
 in a way.

00:17:10.080 --> 00:17:15.160
 So one of the things which is kind of interesting,

00:17:15.160 --> 00:17:18.560
 especially in Germany from some German press articles.

00:17:18.560 --> 00:17:28.120
 Some vendors got a little bit creative in sense of users which are privacy aware.

00:17:28.120 --> 00:17:31.800
 And they try to avoid the word camera as far as they can.

00:17:31.800 --> 00:17:35.040
 And instead, they try to use the word optical sensor.

00:17:35.040 --> 00:17:37.280
 And I have here an article from Golem.

00:17:37.280 --> 00:17:40.360
 I don't want to shame Golem, but I mean, many do that.

00:17:40.360 --> 00:17:43.200
 And they kind of asked the vendor, and the vendor said, yeah, optical sensor is

00:17:43.200 --> 00:17:43.720
 accurate.

00:17:43.720 --> 00:17:47.600
 So it's not a shaming thing, it's just like an info thing here.

00:17:47.600 --> 00:17:51.400
 So what Roborock kind of said is like, so we don't have cameras in there.

00:17:51.400 --> 00:17:54.480
 For privacy reasons, we just put an optical sensor which detects lasers.

00:17:54.480 --> 00:17:57.920
 So it's good for your privacy, so don't worry.

00:17:57.920 --> 00:17:59.320
 Everything will be fine.

00:17:59.320 --> 00:18:04.520
 And I have an output of the optical sensor on the right.

00:18:04.520 --> 00:18:08.440
 By the way, sorry it says, hello, Defqon, but I was too lazy to create another

00:18:08.440 --> 00:18:09.520
 picture for that.

00:18:09.520 --> 00:18:12.480
 So yeah, so as you see, there's an output of optical sensors.

00:18:12.480 --> 00:18:15.120
 So no camera involved.

00:18:15.120 --> 00:18:16.520
 Nothing to see here.

00:18:16.520 --> 00:18:17.680
 Right.

00:18:17.680 --> 00:18:20.040
 Also, certifications are very important.

00:18:20.040 --> 00:18:25.320
 Most of the devices which have cameras have some kind of certification,

00:18:25.320 --> 00:18:27.840
 either by TÜV Rheinland or by TÜV Süd.

00:18:27.840 --> 00:18:33.560
 So both of them are kind of testing all the devices, and all these devices met

00:18:33.560 --> 00:18:35.760
 the European cybersecurity standards.

00:18:35.760 --> 00:18:38.280
 So I think we can't end the talk here because all of them are secure, I assume,

00:18:38.280 --> 00:18:41.880
 because they got tested.

00:18:41.880 --> 00:18:43.560
 Yeah.

00:18:43.560 --> 00:18:45.560
 Sadly, yeah, we can't end here.

00:18:45.560 --> 00:18:46.040
 All right.

00:18:46.040 --> 00:18:47.280
 So what happened so far?

00:18:47.280 --> 00:18:50.760
 Let me give you a quick rundown here.

00:18:50.760 --> 00:18:55.120
 Let's start with a general observation, like what we saw in the last five years.

00:18:55.120 --> 00:19:01.280
 So every time we release a routing method, developers react in weird, sometimes

00:19:01.280 --> 00:19:02.400
 different ways.

00:19:02.400 --> 00:19:08.440
 So sometimes they even react in a way that they break things.

00:19:08.440 --> 00:19:12.720
 And there was some case where they pushed a very quick firmware update which

00:19:12.720 --> 00:19:16.360
 started to break hundreds of vacuum robots permanently because they kind of

00:19:16.360 --> 00:19:22.280
 started to panic and started to do weird things, which is kind of sad, which we

00:19:22.280 --> 00:19:23.960
 want to avoid, obviously.

00:19:23.960 --> 00:19:27.600
 The best case for us if they react is that our routing method just fails in a way

00:19:27.600 --> 00:19:31.360
 that says, hey, the file system is broken, we don't accept it, we don't boot it,

00:19:31.360 --> 00:19:32.760
 so whatever.

00:19:32.760 --> 00:19:33.440
 That's the best case.

00:19:33.440 --> 00:19:38.360
 So sadly, some vendors started to do things which are a little bit more mean.

00:19:38.360 --> 00:19:42.680
 The routing succeeds, everything is fine, but the device will break randomly.

00:19:42.680 --> 00:19:46.480
 For example, white cleans, at some point it will just crash, and it's very hard to

00:19:46.480 --> 00:19:48.200
 debug.

00:19:48.200 --> 00:19:51.520
 In particular cases, it's also so if it detects manipulations or routed

00:19:51.520 --> 00:19:55.440
 firmware, it will just destroy itself permanently, so it will just delete its

00:19:55.440 --> 00:19:58.640
 keys and it will be kind of like a problem.

00:19:58.640 --> 00:20:01.400
 So that's the reason why we need to buy the device in advance to kind of figure

00:20:01.400 --> 00:20:03.160
 stuff like that out.

00:20:03.160 --> 00:20:07.160
 So let's start with the first work in 2017.

00:20:07.160 --> 00:20:13.160
 This was a work together with Dani Wiggema, and it was about the Xiaomi

00:20:13.160 --> 00:20:16.800
 first generation and the Roborock S5, which was also kind of like the first

00:20:16.800 --> 00:20:18.960
 generation device back then.

00:20:18.960 --> 00:20:22.760
 Some of the findings which we found were that the firmware images are unsigned

00:20:22.760 --> 00:20:26.480
 and only encrypted with a very weak key, and I think the very weak key was just

00:20:26.480 --> 00:20:29.440
 Roborock as the name of the company.

00:20:29.440 --> 00:20:32.240
 This by itself wouldn't be a big issue.

00:20:32.240 --> 00:20:36.360
 The problem is that you could push custom firmware on the local network,

00:20:36.360 --> 00:20:42.360
 and so basically you could just flash the device over the network.

00:20:42.360 --> 00:20:45.560
 This is not necessarily a problem for us of people who want to root the devices,

00:20:45.560 --> 00:20:48.200
 but it's a bigger problem if you have malicious people who want to do bad

00:20:48.200 --> 00:20:49.040
 things.

00:20:49.040 --> 00:20:51.840
 Now people might say, okay, I don't have access, so typically attackers don't

00:20:51.840 --> 00:20:54.440
 have access to your personal network.

00:20:54.440 --> 00:20:59.120
 The problem is if your device is in provisioning mode, basically, so it opens

00:20:59.120 --> 00:21:02.440
 its own Wi-Fi access point and waits for you from pushing it into your private

00:21:02.440 --> 00:21:05.160
 Wi-Fi, then you can do the same pushing.

00:21:05.160 --> 00:21:08.080
 Basically, you can push the firmware onto that too.

00:21:08.080 --> 00:21:13.000
 When I was living in Darmstadt, I saw some of my neighbors had Xiaomi vacuum

00:21:13.000 --> 00:21:14.880
 robots which were paranoid.

00:21:14.880 --> 00:21:18.000
 They didn't put them into their Wi-Fi, so they had open Wi-Fi access points on

00:21:18.000 --> 00:21:19.480
 the robot.

00:21:19.480 --> 00:21:24.640
 I didn't do it, but technically I could have pushed a malicious firmware onto

00:21:24.640 --> 00:21:27.800
 that and just wait one day, they will probably put it in their Wi-Fi, and then

00:21:27.800 --> 00:21:29.120
 they would be screwed.

00:21:29.120 --> 00:21:29.880
 Still don't do that.

00:21:29.880 --> 00:21:32.880
 If you see improvised robots in your neighborhood, don't hack them.

00:21:32.880 --> 00:21:34.920
 That's very mean and annoying.

00:21:34.920 --> 00:21:37.800
 Anyway, so what's the result of these two facts?

00:21:37.800 --> 00:21:41.240
 One of the things is we could root the devices for disassembly, and we could

00:21:41.240 --> 00:21:43.440
 start the development of custom software and voice packages.

00:21:43.440 --> 00:21:48.480
 A lot of people in Germany apparently are very interested in voice packages.

00:21:48.480 --> 00:21:52.960
 I mean, for me, English is fine, but a lot of people got very creative with

00:21:52.960 --> 00:21:55.960
 like GLaDOS and some other things.

00:21:55.960 --> 00:22:02.200
 This was published on the CCC Congress in 2017 and also DEF CON in 2018, so

00:22:02.200 --> 00:22:03.280
 exactly five years ago.

00:22:03.280 --> 00:22:07.200
 So as you see, I do that stuff for a very long time already.

00:22:07.200 --> 00:22:10.960
 The reaction from that was Roborock, who developed both the devices, was not

00:22:10.960 --> 00:22:12.040
 very happy about that.

00:22:12.040 --> 00:22:16.360
 So what they started to do is they started to block local firmware updates

00:22:16.360 --> 00:22:17.320
 in the firmware.

00:22:17.320 --> 00:22:20.880
 Which is technically OK from a cyber security perspective, so I wasn't super

00:22:20.880 --> 00:22:22.040
 mad about that.

00:22:22.040 --> 00:22:24.960
 But also then what we started to introduce is we basically signed all

00:22:24.960 --> 00:22:28.800
 the firmware and voice packages, so we couldn't necessarily create our own

00:22:28.800 --> 00:22:29.680
 anymore.

00:22:29.680 --> 00:22:33.320
 And each of the device models basically used the firmware encryption keys.

00:22:33.320 --> 00:22:38.560
 So we had to basically get every device individually, like every model, and

00:22:38.560 --> 00:22:41.520
 extract the keys to kind of look in the firmware.

00:22:41.520 --> 00:22:44.360
 One of the things where we got a little bit annoyed about people buying cheap

00:22:44.360 --> 00:22:48.440
 devices in China and using them in Europe was basically that they started

00:22:48.440 --> 00:22:52.680
 to enforce region locks so that you couldn't import device anymore, but you

00:22:52.680 --> 00:22:56.520
 can't run them in Germany for whatever reason.

00:22:56.520 --> 00:22:58.800
 I mean, we just want to avoid that.

00:22:58.800 --> 00:23:02.840
 However, one of the interesting things is that the hardware mostly remains

00:23:02.840 --> 00:23:03.640
 the same.

00:23:03.640 --> 00:23:07.960
 So if you bought every two years a vacuum robot from Roborock and you take

00:23:07.960 --> 00:23:10.760
 the PCBs out and compare them to each other, the layout was more or less the

00:23:10.760 --> 00:23:11.040
 same.

00:23:11.040 --> 00:23:16.320
 So they sell you more or less the same hardware configuration all over again

00:23:16.320 --> 00:23:18.200
 every two years or every year even.

00:23:18.200 --> 00:23:20.360
 So that's their business model, I guess.

00:23:20.360 --> 00:23:23.200
 They can't charge you for updates, but they can charge you for new hardware,

00:23:23.200 --> 00:23:25.000
 just as a side note.

00:23:25.000 --> 00:23:27.920
 Anyway, the problem which we had now is we needed to disassemble the device,

00:23:27.920 --> 00:23:30.240
 which was kind of like a problem.

00:23:30.240 --> 00:23:31.080
 I have here an example.

00:23:31.080 --> 00:23:33.880
 So basically you need to completely unscrew the device.

00:23:33.880 --> 00:23:36.960
 You need to solder maybe a few things.

00:23:36.960 --> 00:23:45.680
 One of the good things here was that we figured out a way to bypass that,

00:23:45.680 --> 00:23:47.320
 which required assembly.

00:23:47.320 --> 00:23:52.760
 And this worked for the robot S6, S5 Max, S7, and also others.

00:23:52.760 --> 00:23:57.920
 The initial idea which we had was that we accessed the U-boot shell by UART.

00:23:57.920 --> 00:24:00.520
 Sadly, they figured that out at some point and fixed that.

00:24:00.520 --> 00:24:04.160
 And the new approach was that we get the device into bootloader mode and just

00:24:04.160 --> 00:24:05.880
 patch the file system over USB.

00:24:05.880 --> 00:24:09.720
 And this turned out to be the more efficient way to do that.

00:24:09.720 --> 00:24:10.720
 Again, there's advantages.

00:24:10.720 --> 00:24:12.880
 We need to disassemble the device, which is annoying.

00:24:12.880 --> 00:24:16.240
 But that's the price of doing business, I guess.

00:24:16.240 --> 00:24:20.320
 One of the interesting facts is that this method still works until today.

00:24:20.320 --> 00:24:29.000
 For all the other 16-based devices, so for example, S6 Pro Ultra and Q7.

00:24:29.000 --> 00:24:32.400
 When they saw that we have a new way to root the devices, they reacted again.

00:24:32.400 --> 00:24:33.720
 And we're not necessarily happy.

00:24:33.720 --> 00:24:36.600
 So as mentioned before, they locked the bootloader down so

00:24:36.600 --> 00:24:38.800
 we don't have a U-boot shell anymore.

00:24:38.800 --> 00:24:42.280
 And then they basically got through the book of all security methods and started

00:24:42.280 --> 00:24:45.200
 to introduce things like Secure Boot, SA Linux.

00:24:45.200 --> 00:24:47.000
 They introduced the M-variety.

00:24:47.000 --> 00:24:54.560
 And even newer device have encrypted file systems where the user data and

00:24:54.560 --> 00:24:55.520
 applications encrypted.

00:24:55.520 --> 00:24:58.480
 So we can't even figure out, OK, what is the application actually doing?

00:24:58.480 --> 00:25:02.160
 So we only see a partial of the portion of the system.

00:25:02.160 --> 00:25:08.080
 And they started to use Trust Zone where they stored the keys in OPT, basically.

00:25:08.080 --> 00:25:10.840
 Which has also the risk if you do any sketchy things,

00:25:10.840 --> 00:25:12.440
 where the keys just get wiped.

00:25:12.440 --> 00:25:15.840
 So you need to be careful with that.

00:25:15.840 --> 00:25:19.200
 One thing which we introduced at some point were custom LF binary signatures,

00:25:19.200 --> 00:25:20.000
 which I never saw before.

00:25:20.000 --> 00:25:24.280
 So they basically were assigning all LF binaries which exist in a system.

00:25:24.280 --> 00:25:28.600
 And every time you try to execute an unsigned binary, it just wouldn't execute.

00:25:28.600 --> 00:25:30.520
 It would get a second thought.

00:25:30.520 --> 00:25:35.120
 So in 2021, we fight back.

00:25:35.120 --> 00:25:41.600
 So this was a thing which I presented at DEF CON.

00:25:41.600 --> 00:25:44.000
 Oh, this is actually not accurate.

00:25:44.000 --> 00:25:46.880
 I presented at DEF CON 21.

00:25:46.880 --> 00:25:47.920
 Not here.

00:25:47.920 --> 00:25:53.560
 And the method was basically to bypass the LF binary verification and security.

00:25:53.560 --> 00:25:58.600
 So one of the ideas was to modify the configuration partition.

00:25:58.600 --> 00:26:01.680
 But it required basically the desoldering of the EMMC flash strip,

00:26:01.680 --> 00:26:04.720
 which most of the people can't do or don't want to do,

00:26:04.720 --> 00:26:07.440
 because it will very likely brick your device.

00:26:07.440 --> 00:26:08.720
 Or you need some ISP access.

00:26:08.720 --> 00:26:12.800
 So this was a very specific method for a very specifically specific people

00:26:12.800 --> 00:26:14.320
 who are good with soldering.

00:26:14.320 --> 00:26:16.280
 But it's not a broad thing.

00:26:16.280 --> 00:26:20.680
 And that was the reason why we said, OK, we want to maybe take a look

00:26:20.680 --> 00:26:24.800
 at different vendors for now and just wait until Roborock kind of cools down

00:26:24.800 --> 00:26:29.080
 and kind of gets more relaxed and stops being mean.

00:26:29.080 --> 00:26:33.760
 And one thing which we found was a new vendor, which is Dreamy.

00:26:33.760 --> 00:26:35.920
 And we have very similar devices to Roborock.

00:26:35.920 --> 00:26:37.240
 Basically, they were powerful.

00:26:37.240 --> 00:26:39.200
 They had cameras.

00:26:39.200 --> 00:26:40.920
 They had an extremely easy routing method,

00:26:40.920 --> 00:26:43.000
 basically, before disassembling.

00:26:43.000 --> 00:26:46.520
 And we were able to basically flash them over USB.

00:26:46.520 --> 00:26:48.480
 One of the problems with the flashing over USB part

00:26:48.480 --> 00:26:50.000
 was that some devices got soft-bricked.

00:26:50.000 --> 00:26:53.880
 But I think we solve that problem nowadays.

00:26:53.880 --> 00:26:58.400
 So how did Roborock react onto our Defqon talk back then?

00:26:58.400 --> 00:27:03.960
 Well, I got a very nice email from the Roborock CEO one day after my talk.

00:27:03.960 --> 00:27:04.960
 Oh, thank you for the talk.

00:27:04.960 --> 00:27:08.080
 Our engineers watched the talk live and are fixing right now

00:27:08.080 --> 00:27:09.440
 all the vulnerabilities.

00:27:09.440 --> 00:27:14.120
 So that's the reason why I know that we are watching those talks.

00:27:14.120 --> 00:27:16.480
 What we did now is we encrypted all the partitions,

00:27:16.480 --> 00:27:21.000
 except the system partition, which we can do for technical reasons.

00:27:21.000 --> 00:27:23.600
 They started to obfuscate the ALF binary signature.

00:27:23.600 --> 00:27:27.440
 So we cannot find it that easily and patch it.

00:27:27.440 --> 00:27:31.280
 And we started to add custom code into the random libraries

00:27:31.280 --> 00:27:33.640
 to kind of detect if we try to bypass the traffic.

00:27:33.640 --> 00:27:37.240
 So one of the ways how we kind of disconnected us from the cloud

00:27:37.240 --> 00:27:41.680
 is that we redirect traffic via DNS to the robot itself

00:27:41.680 --> 00:27:43.680
 so that basically nothing goes to the cloud.

00:27:43.680 --> 00:27:45.360
 Everything stays on the robot.

00:27:45.360 --> 00:27:48.960
 And they figured out, hey, you still wanted to expel traffic from the robot.

00:27:48.960 --> 00:27:50.320
 So how can we do that?

00:27:50.320 --> 00:27:52.960
 We just have a detection, which detects

00:27:52.960 --> 00:27:57.560
 if you want to upload something to your roborock.com domain.

00:27:57.560 --> 00:28:00.120
 And if you do that, it has some obfuscated way

00:28:00.120 --> 00:28:03.120
 to kind of do DNS queries on itself in the libcurl library.

00:28:03.120 --> 00:28:06.720
 So at some point, we noticed, wait, we have still traffic going off

00:28:06.720 --> 00:28:09.760
 to Roborock, even though we have blocked all the domains.

00:28:09.760 --> 00:28:12.440
 And so we figured out that they introduced some sneaky way

00:28:12.440 --> 00:28:14.920
 to still exfutrate log files and some other stuff,

00:28:14.920 --> 00:28:17.760
 even if the device is rooted.

00:28:17.760 --> 00:28:18.480
 We figured it out.

00:28:18.480 --> 00:28:19.360
 We patch it nowadays.

00:28:19.360 --> 00:28:20.680
 But this is one of the things.

00:28:20.680 --> 00:28:24.920
 They try to find ways to bypass our routing methods.

00:28:24.920 --> 00:28:27.880
 And notice they love obfuscation.

00:28:27.880 --> 00:28:30.040
 They use XOR everywhere they can use it.

00:28:30.040 --> 00:28:34.600
 So it's kind of like it gets a little bit annoying from time to time.

00:28:34.600 --> 00:28:39.120
 So how does their stuff look like?

00:28:39.120 --> 00:28:44.760
 So as mentioned, they noticed check for L signatures in the kernel.

00:28:44.760 --> 00:28:49.760
 So basically, they use the doMMap function,

00:28:49.760 --> 00:28:55.680
 which basically creates a memory area for if you try to run a program.

00:28:55.680 --> 00:28:59.280
 And if the file is not signed correctly, it will basically secfault.

00:28:59.280 --> 00:29:01.320
 So every time you try to execute your own custom binary,

00:29:01.320 --> 00:29:04.040
 it will just secfault. Nothing happens.

00:29:04.040 --> 00:29:07.520
 And they got really creative in naming the functions.

00:29:07.520 --> 00:29:09.760
 So I have an example on the right, which is basically

00:29:09.760 --> 00:29:12.960
 the doMMap function from the S8.

00:29:12.960 --> 00:29:16.960
 And they started to use names like clock set rate DSP0.

00:29:16.960 --> 00:29:18.520
 There's no DSP0, by the way.

00:29:18.520 --> 00:29:20.080
 Or clock set, whatever thing.

00:29:20.080 --> 00:29:22.520
 So these functions are actually just to verify the signature.

00:29:22.520 --> 00:29:26.560
 But they named them in the super weird way so that we would think,

00:29:26.560 --> 00:29:28.960
 oh, that's probably something important, so we don't touch it.

00:29:28.960 --> 00:29:32.480
 But in reality, that's where obfuscated signature check.

00:29:32.480 --> 00:29:34.120
 And they do some weird other stuff.

00:29:34.120 --> 00:29:36.480
 So I think they use some code obfuscation tools

00:29:36.480 --> 00:29:39.360
 to basically try to get a soft track.

00:29:39.360 --> 00:29:43.160
 So at the same time, Dreamy started also to panic directly after the talk.

00:29:43.160 --> 00:29:45.040
 So they did a lot of changes in their firmware.

00:29:45.040 --> 00:29:51.920
 They removed the UART lock-in shell and the UBoot shell.

00:29:51.920 --> 00:29:54.280
 So they just patched UBoot.

00:29:54.280 --> 00:29:57.840
 And they pushed changes, which started apparently to break robots

00:29:57.840 --> 00:30:00.040
 if their firmware version was too old.

00:30:00.040 --> 00:30:00.800
 So it was kind of weird.

00:30:00.800 --> 00:30:04.800
 So we got a lot of feedback back from people who didn't have rooted vacuum

00:30:04.800 --> 00:30:08.680
 robots, but their device was bricked from a firmware update.

00:30:08.680 --> 00:30:10.760
 And especially this happened outside of the warranty.

00:30:10.760 --> 00:30:13.960
 So they kind of parametric devices.

00:30:13.960 --> 00:30:16.800
 One of the fun facts is because we compared firmware updates,

00:30:16.800 --> 00:30:21.040
 we found a way simpler routing methods which we weren't aware of.

00:30:21.040 --> 00:30:25.920
 So they patched something where we didn't know that it was there.

00:30:25.920 --> 00:30:28.880
 And it was very helpful because one thing which we noticed

00:30:28.880 --> 00:30:31.360
 was that they removed this function.

00:30:31.360 --> 00:30:34.000
 And what it does is if you press the reset button for one second,

00:30:34.000 --> 00:30:36.560
 it will pop a lock-in shell.

00:30:36.560 --> 00:30:39.520
 And we had no idea because we thought, OK, we removed the lock-in shell,

00:30:39.520 --> 00:30:42.320
 so we need to do the USB and whatever.

00:30:42.320 --> 00:30:44.320
 And then we noticed, wait, they removed that.

00:30:44.320 --> 00:30:46.680
 And it took many, many months until it got actually

00:30:46.680 --> 00:30:50.240
 pushed into all the devices which were newly produced.

00:30:50.240 --> 00:30:51.880
 And we saw that and we were like, oh, wait,

00:30:51.880 --> 00:30:55.880
 there's a way safer method because now you can connect over UART,

00:30:55.880 --> 00:30:58.560
 press the reset button for one second, and just get a lock-in shell.

00:30:58.560 --> 00:31:00.440
 And you can lock in with a particular password.

00:31:00.440 --> 00:31:02.400
 So this was very helpful.

00:31:02.400 --> 00:31:04.320
 So thanks for showing us this thing.

00:31:04.320 --> 00:31:06.040
 That's not the only time it just happened.

00:31:06.040 --> 00:31:09.680
 So we found a couple other things which were also kind of useful.

00:31:09.680 --> 00:31:10.480
 Right.

00:31:10.480 --> 00:31:11.920
 But we started to panic even more.

00:31:11.920 --> 00:31:16.600
 And they introduced like a secure boot and have set the if-uses,

00:31:16.600 --> 00:31:19.120
 which was kind of being expected.

00:31:19.120 --> 00:31:23.840
 They signed the system partition and are doing the verification

00:31:23.840 --> 00:31:25.800
 of a U-boot, which is the bootloader.

00:31:25.800 --> 00:31:28.760
 And they started to pair the kernel with a particular version

00:31:28.760 --> 00:31:30.840
 of the system partition.

00:31:30.840 --> 00:31:33.960
 And this is kind of important for the thing which we did next.

00:31:33.960 --> 00:31:39.800
 They basically introduced the judge countermeasures.

00:31:39.800 --> 00:31:43.600
 So judge countermeasurements, what is that?

00:31:43.600 --> 00:31:46.760
 This is one of the things which we introduced in 2020

00:31:46.760 --> 00:31:47.560
 in all new firmwares.

00:31:47.560 --> 00:31:50.640
 So if you have a firmware which is newer than-- or a device also

00:31:50.640 --> 00:31:54.080
 which is newer than 2022, you have it.

00:31:54.080 --> 00:31:57.480
 Rooted firmwares would start to crash randomly.

00:31:57.480 --> 00:32:00.120
 And it was super weird for us to debug that.

00:32:00.120 --> 00:32:02.240
 And at the end of the day, we figured it out.

00:32:02.240 --> 00:32:03.400
 But this was super annoying.

00:32:03.400 --> 00:32:04.920
 And it was super mean by them.

00:32:04.920 --> 00:32:06.640
 And I think it was directed directly at us.

00:32:06.640 --> 00:32:08.440
 This was not a thing against other vendors.

00:32:08.440 --> 00:32:10.680
 It was directly directed at us.

00:32:10.680 --> 00:32:11.840
 So what does it do?

00:32:11.840 --> 00:32:15.880
 So they bake the expected SHA-256 hash of the root file

00:32:15.880 --> 00:32:17.800
 system into the kernel.

00:32:17.800 --> 00:32:21.160
 Then as soon as you run the cleaning process,

00:32:21.160 --> 00:32:23.040
 at some random time in the cleaning process,

00:32:23.040 --> 00:32:26.040
 it will compute the hash of the actual system partition,

00:32:26.040 --> 00:32:29.880
 compared if it matches to the hash which the kernel expects.

00:32:29.880 --> 00:32:31.880
 If the hash is not correct, they will just

00:32:31.880 --> 00:32:36.440
 start spawning your threads and run malloc in a loop, which

00:32:36.440 --> 00:32:38.360
 will basically cause the whole memory--

00:32:38.360 --> 00:32:41.240
 that you get the memory leak, basically, randomly.

00:32:41.240 --> 00:32:42.520
 This can be after five minutes.

00:32:42.520 --> 00:32:43.480
 This can be after 10 minutes.

00:32:43.480 --> 00:32:45.020
 But the robot will at some point crash

00:32:45.020 --> 00:32:46.880
 and just stop at some point.

00:32:46.880 --> 00:32:48.640
 And this is extremely difficult to debug,

00:32:48.640 --> 00:32:52.360
 because the thing is there's no locks.

00:32:52.360 --> 00:32:54.480
 You can't run trace the whole time, because it just

00:32:54.480 --> 00:32:55.200
 happens randomly.

00:32:55.200 --> 00:32:56.800
 So at some point, we figured it out.

00:32:56.800 --> 00:32:59.240
 But this was extremely annoying.

00:32:59.240 --> 00:33:01.960
 It cost me weeks of reverse engineering

00:33:01.960 --> 00:33:04.800
 and figuring out what's going on, basically comparing firmwares.

00:33:04.800 --> 00:33:06.160
 Why it doesn't crash with this firmware?

00:33:06.160 --> 00:33:07.360
 Why it crashed with this firmware?

00:33:07.360 --> 00:33:08.800
 What changed?

00:33:08.800 --> 00:33:11.160
 That's just very sad.

00:33:11.160 --> 00:33:13.920
 Anyway, so that was the past.

00:33:13.920 --> 00:33:15.120
 We figured it out.

00:33:15.120 --> 00:33:19.640
 So let's talk about the current state of robot security.

00:33:19.640 --> 00:33:21.560
 I want to just use one device, which

00:33:21.560 --> 00:33:24.320
 I think is the one which has the most protections

00:33:24.320 --> 00:33:25.720
 and is the most secure one.

00:33:25.720 --> 00:33:29.120
 And that's the Roborock S8 Pro Ultra.

00:33:29.120 --> 00:33:32.440
 That's the current flagship model by Roborock.

00:33:32.440 --> 00:33:36.000
 So that's the newest kind of thing which we have.

00:33:36.000 --> 00:33:41.920
 This device runs an all-winner MR813,

00:33:41.920 --> 00:33:46.000
 which is a quad-core sock and runs a couple more MCUs.

00:33:46.000 --> 00:33:49.520
 It has either 502 megabytes of RAM or 1 gigabyte of RAM.

00:33:49.520 --> 00:33:51.400
 The reason why they have two different things

00:33:51.400 --> 00:33:52.840
 is I think they started with 1 gigabyte

00:33:52.840 --> 00:33:54.640
 and figured out they can get away with 512.

00:33:54.640 --> 00:33:58.920
 So it's kind of like a cost-cutting measurement.

00:33:58.920 --> 00:34:03.560
 And they have 4 gigabyte of flash.

00:34:03.560 --> 00:34:05.360
 This device has two cameras.

00:34:05.360 --> 00:34:07.120
 One LIDAR sensor and two line lasers.

00:34:07.120 --> 00:34:09.680
 So it's kind of interesting from a platform.

00:34:09.680 --> 00:34:11.680
 And security-wise, we checked everything in the book.

00:34:11.680 --> 00:34:13.920
 Basically, secure boot, the MBRT-protected root of S,

00:34:13.920 --> 00:34:18.840
 everything encrypted, SA Linux, and ALF signatures.

00:34:18.840 --> 00:34:20.040
 All right.

00:34:20.040 --> 00:34:23.160
 I want to give you a short rundown

00:34:23.160 --> 00:34:27.560
 about the boot process of the S8 Ultra.

00:34:27.560 --> 00:34:29.200
 It looks a little bit complicated,

00:34:29.200 --> 00:34:34.280
 but it's important to kind of understand that for our attack.

00:34:34.280 --> 00:34:35.680
 Let me just get a quick drink here.

00:34:35.680 --> 00:34:40.920
 All right.

00:34:40.920 --> 00:34:43.520
 So we start at the boot ROM, which is basically

00:34:43.520 --> 00:34:45.520
 baked into the SOC.

00:34:45.520 --> 00:34:48.600
 The boot ROM checks the baked in hash,

00:34:48.600 --> 00:34:52.520
 which is like in the effuses of the TOC0, which is kind

00:34:52.520 --> 00:34:54.440
 of like the first-stage bootloader.

00:34:54.440 --> 00:34:56.280
 The first-stage bootloader initializes the RAM,

00:34:56.280 --> 00:34:58.960
 so from there we can do other things.

00:34:58.960 --> 00:35:00.800
 Then TOC0, or the first-stage bootloader,

00:35:00.800 --> 00:35:02.280
 checks the signature of TOC1, which

00:35:02.280 --> 00:35:07.480
 is like a technical term here, which launches the trust zone

00:35:07.480 --> 00:35:11.160
 component, which is OPT, which then verifies and launches

00:35:11.160 --> 00:35:13.040
 your boot.

00:35:13.040 --> 00:35:15.680
 You would guess it's a boot configuration.

00:35:15.680 --> 00:35:19.000
 Then verifies and launches the actual Linux kernel.

00:35:19.000 --> 00:35:21.200
 The Linux kernel has baked in the DMVariety key,

00:35:21.200 --> 00:35:24.920
 which will basically verify and mount the root file system.

00:35:24.920 --> 00:35:28.440
 And the Linux kernel has also the ALF binary signature thing,

00:35:28.440 --> 00:35:31.480
 which will basically check all the in-head software, which

00:35:31.480 --> 00:35:33.480
 will be launched after that.

00:35:33.480 --> 00:35:35.720
 The in-head software itself will talk again to trust zone,

00:35:35.720 --> 00:35:37.220
 and it will get the keys for the partitions,

00:35:37.220 --> 00:35:39.920
 and will start to decrypt the software partition,

00:35:39.920 --> 00:35:42.480
 and will decrypt the user data partition.

00:35:42.480 --> 00:35:45.280
 So basically what this means is everything

00:35:45.280 --> 00:35:49.440
 checked everything else, which is kind of an issue.

00:35:49.440 --> 00:35:50.680
 Or does it?

00:35:50.680 --> 00:35:52.080
 So the question is, is everything

00:35:52.080 --> 00:35:53.520
 actually checked by everything?

00:35:53.520 --> 00:35:56.720
 Well, there's one thing which is a little bit questionable,

00:35:56.720 --> 00:35:59.000
 and this is the U-Boot portion.

00:35:59.000 --> 00:36:00.600
 So what is U-Boot?

00:36:00.600 --> 00:36:03.360
 It's the de facto default bootloader for embedded devices,

00:36:03.360 --> 00:36:05.720
 so you find it in all the embedded devices, more or less.

00:36:05.720 --> 00:36:07.840
 It's very powerful software.

00:36:07.840 --> 00:36:10.320
 It does some setup of hardware.

00:36:10.320 --> 00:36:13.040
 It sets also the command line arguments for the kernel.

00:36:13.040 --> 00:36:15.360
 It verifies the kernel and boots it.

00:36:15.360 --> 00:36:18.680
 And the important thing here is it uses an environment

00:36:18.680 --> 00:36:19.600
 to configure itself.

00:36:19.600 --> 00:36:20.880
 And why we need to use this environment

00:36:20.880 --> 00:36:22.320
 is if you do firmware updates, you

00:36:22.320 --> 00:36:24.200
 don't want to do it on the operating system which

00:36:24.200 --> 00:36:25.120
 you're running right now.

00:36:25.120 --> 00:36:27.980
 You want to do it on a copy, and then just switch to copy.

00:36:27.980 --> 00:36:31.520
 So you need to have the mechanism to switch between both.

00:36:31.520 --> 00:36:34.220
 So this is like the AB booting.

00:36:34.220 --> 00:36:36.160
 And it supports a very powerful command set.

00:36:36.160 --> 00:36:38.600
 For example, it allows you to loading partitions into memories

00:36:38.600 --> 00:36:40.000
 which you need for the kernel load.

00:36:40.000 --> 00:36:42.160
 It allows you to access memory, and it allows you also

00:36:42.160 --> 00:36:44.080
 to change memory.

00:36:44.080 --> 00:36:48.400
 So access memory and changing memory.

00:36:48.400 --> 00:36:49.920
 Can we do anything with that?

00:36:49.920 --> 00:36:53.840
 Well, the question is, can we ask U-Boot very nicely

00:36:53.840 --> 00:36:55.180
 to just modify itself?

00:36:55.180 --> 00:36:57.240
 And so the theory would be here, well,

00:36:57.240 --> 00:36:58.860
 can we use the read and write commands

00:36:58.860 --> 00:37:01.740
 to overwrite instructions in the sense of can we just

00:37:01.740 --> 00:37:03.440
 patch the signature functions?

00:37:03.440 --> 00:37:05.240
 And so what we need to do here is

00:37:05.240 --> 00:37:06.280
 we need to do a little bit of math.

00:37:06.280 --> 00:37:08.520
 So we need to figure out where the signature function is

00:37:08.520 --> 00:37:09.760
 actually in the memory.

00:37:09.760 --> 00:37:11.760
 We need to figure out where U-Boot is basically

00:37:11.760 --> 00:37:13.760
 relocating itself, which is a kind of technical thing which

00:37:13.760 --> 00:37:14.760
 U-Boot is doing.

00:37:14.760 --> 00:37:17.440
 And we need to calculate the exact place in memory.

00:37:17.440 --> 00:37:19.920
 And then we can use this command basically

00:37:19.920 --> 00:37:24.080
 which writes this E0 1 6 at this particular memory address.

00:37:24.080 --> 00:37:26.040
 And this basically overwrites all the instructions

00:37:26.040 --> 00:37:28.320
 of the signature check function.

00:37:28.320 --> 00:37:30.400
 Which means, so what's the consequence of that?

00:37:30.400 --> 00:37:34.440
 Well, if we supply U-Boot with malicious config,

00:37:34.440 --> 00:37:36.560
 what it will do is it will basically

00:37:36.560 --> 00:37:40.720
 ask U-Boot to patch itself very nicely, which

00:37:40.720 --> 00:37:42.740
 will disable the verify function so we can

00:37:42.740 --> 00:37:44.520
 start to modify the kernel.

00:37:44.520 --> 00:37:45.960
 Because we have modified the kernel,

00:37:45.960 --> 00:37:48.480
 we can basically disable the elf signature verification.

00:37:48.480 --> 00:37:51.280
 And we can disable the root file system verification.

00:37:51.280 --> 00:37:53.640
 And from there, we can just pull out the keys from upt

00:37:53.640 --> 00:37:56.600
 and we have everything compromised basically at this point.

00:37:56.600 --> 00:37:57.800
 So we can run our own kernels.

00:37:57.800 --> 00:37:59.720
 We can run our own file systems.

00:37:59.720 --> 00:38:03.680
 So what we did achieve with that method generally,

00:38:03.680 --> 00:38:06.160
 well, we bypassed the secure boot process.

00:38:06.160 --> 00:38:07.400
 We can modify the kernel.

00:38:07.400 --> 00:38:10.040
 We can remove all these checks which are in there.

00:38:10.040 --> 00:38:11.880
 We can also disable the ELINOS, which sometimes

00:38:11.880 --> 00:38:13.000
 gets a little bit annoying.

00:38:13.000 --> 00:38:16.080
 And we can modify the root file system.

00:38:16.080 --> 00:38:18.320
 From there, we can start to install custom software

00:38:18.320 --> 00:38:20.400
 and get SSH access.

00:38:20.400 --> 00:38:22.680
 One quick comment here is it's not limited only

00:38:22.680 --> 00:38:23.680
 on all WinRSOC.

00:38:23.680 --> 00:38:25.920
 So this attack method surprisingly

00:38:25.920 --> 00:38:27.800
 works for many, many other devices.

00:38:27.800 --> 00:38:29.520
 So I tested this on other robots.

00:38:29.520 --> 00:38:30.680
 I tested it on smart speakers.

00:38:30.680 --> 00:38:31.840
 I tested it on media devices.

00:38:31.840 --> 00:38:34.120
 So this works generally wherever you have U-Boot.

00:38:34.120 --> 00:38:37.640
 You can use the memory commands to just overwrite and patch

00:38:37.640 --> 00:38:40.000
 U-Boot itself basically as long as you have access to somehow

00:38:40.000 --> 00:38:42.280
 to your environment partition, which brings us

00:38:42.280 --> 00:38:43.080
 to the next problem.

00:38:43.080 --> 00:38:45.920
 So how can we modify the environment partition?

00:38:45.920 --> 00:38:48.240
 So the problem is without root access,

00:38:48.240 --> 00:38:51.240
 we cannot modify it for obvious reasons.

00:38:51.240 --> 00:38:53.160
 And we cannot also modify root file system

00:38:53.160 --> 00:38:55.520
 if you don't have shell access to the device.

00:38:55.520 --> 00:38:58.360
 And one thing which I can do, but probably most of the people

00:38:58.360 --> 00:39:01.000
 in here can do, is to disorder the flash memory, which

00:39:01.000 --> 00:39:02.320
 is kind of a little bit dangerous

00:39:02.320 --> 00:39:05.480
 and will definitely void your warranty.

00:39:05.480 --> 00:39:07.160
 So the good news is I figured out a way

00:39:07.160 --> 00:39:08.560
 to do that for each of the devices.

00:39:08.560 --> 00:39:12.720
 So for the old P models, we have a new method,

00:39:12.720 --> 00:39:15.840
 which is the USB stick method, which I will explain in a minute.

00:39:15.840 --> 00:39:18.640
 For the newer devices, we use like FEL boot.

00:39:18.640 --> 00:39:20.600
 So we get it into bootloader.

00:39:20.600 --> 00:39:22.880
 And for all the Robrock devices, we

00:39:22.880 --> 00:39:25.080
 have a thing which we call scary FEL boot.

00:39:25.080 --> 00:39:27.440
 And I will explain why it's scary.

00:39:27.440 --> 00:39:30.000
 So as a quick recap for people who saw the presentation

00:39:30.000 --> 00:39:32.640
 two years ago, Dreamy is very, very nice

00:39:32.640 --> 00:39:34.440
 and gave us lots of debug pins, which

00:39:34.440 --> 00:39:36.820
 are accessible without completely disassembling the device.

00:39:36.820 --> 00:39:38.760
 You just need to basically remove a cover

00:39:38.760 --> 00:39:40.480
 and you have access there.

00:39:40.480 --> 00:39:42.760
 And all the new devices have exactly the same pinout.

00:39:42.760 --> 00:39:44.800
 So if you have a routing adapter,

00:39:44.800 --> 00:39:46.320
 which you can get today for free here,

00:39:46.320 --> 00:39:50.040
 if I have still some left, you can just connect to that

00:39:50.040 --> 00:39:53.600
 and you get access to your UART, USB, and some other things.

00:39:53.600 --> 00:39:58.360
 So let's talk about the USB stick method.

00:39:58.360 --> 00:40:02.880
 So Dreamy left a back drawer in all the P models

00:40:02.880 --> 00:40:03.800
 for whatever reason.

00:40:03.800 --> 00:40:05.400
 I think they just forgot about that.

00:40:05.400 --> 00:40:07.760
 There's this script which gets executed as soon as you

00:40:07.760 --> 00:40:10.520
 attach an empty USB stick.

00:40:10.520 --> 00:40:12.640
 And this is how it looks like.

00:40:12.640 --> 00:40:14.840
 So basically, if you attach an empty USB stick,

00:40:14.840 --> 00:40:16.960
 there's a function which will try to check something.

00:40:16.960 --> 00:40:18.280
 But as you see, this function is basically

00:40:18.280 --> 00:40:19.440
 doing exactly the same thing.

00:40:19.440 --> 00:40:20.880
 You just pop a login shell.

00:40:20.880 --> 00:40:23.840
 So if you just attach an empty USB stick,

00:40:23.840 --> 00:40:25.960
 they forgot to do the actual authentication.

00:40:25.960 --> 00:40:27.920
 So you have a shell and from there

00:40:27.920 --> 00:40:30.600
 you can just do the old methods of routing.

00:40:30.600 --> 00:40:32.320
 Very, very easy.

00:40:32.320 --> 00:40:34.480
 And so after locking, you can just patch the environment

00:40:34.480 --> 00:40:35.560
 and install custom software.

00:40:35.560 --> 00:40:37.040
 It's super trivial.

00:40:37.040 --> 00:40:39.080
 The sad news is, apparently for the new models,

00:40:39.080 --> 00:40:39.800
 we didn't forget that.

00:40:39.800 --> 00:40:41.200
 So I assume they have two branches which

00:40:41.200 --> 00:40:42.200
 at some point separated.

00:40:42.200 --> 00:40:44.360
 They did the implementation of the authentication

00:40:44.360 --> 00:40:46.760
 of the new models, but they forgot to patch it back.

00:40:46.760 --> 00:40:51.920
 So they have, I think, some weird issues with their code

00:40:51.920 --> 00:40:53.760
 management.

00:40:53.760 --> 00:40:58.800
 For the new RuboRub models, we have this method of FEL boot,

00:40:58.800 --> 00:40:59.840
 FEL root.

00:40:59.840 --> 00:41:02.440
 And basically what it does is we need to use some adapter.

00:41:02.440 --> 00:41:04.800
 We need to use a cable to just get it into bootloader mode.

00:41:04.800 --> 00:41:07.920
 So we need to short the boot selection pin down to ground.

00:41:07.920 --> 00:41:11.280
 And then we have custom Phoenix Suite image,

00:41:11.280 --> 00:41:15.160
 which will basically give us fast boot interface

00:41:15.160 --> 00:41:16.320
 to access the flash memory.

00:41:16.320 --> 00:41:18.160
 So it's actually not really a firmware update.

00:41:18.160 --> 00:41:19.700
 It's kind of like a weird, sketchy thing

00:41:19.700 --> 00:41:22.480
 which got zombie together out of different parts, which

00:41:22.480 --> 00:41:23.240
 barely works.

00:41:23.240 --> 00:41:26.440
 But it works perfectly fine for whatever we try to do.

00:41:26.440 --> 00:41:28.280
 So what it allows us to automatically patch

00:41:28.280 --> 00:41:31.040
 the bootloader and the environment.

00:41:31.040 --> 00:41:34.320
 And it allows us to send the root file system and the kernel

00:41:34.320 --> 00:41:36.640
 onto the robots via USB.

00:41:36.640 --> 00:41:38.000
 And it's very, very safe.

00:41:38.000 --> 00:41:39.880
 So so far, we had zero brick robots.

00:41:39.880 --> 00:41:41.240
 And even if the robot is brick, we

00:41:41.240 --> 00:41:43.880
 can recover any robot by doing this method without erasing

00:41:43.880 --> 00:41:46.320
 data which existed before.

00:41:46.320 --> 00:41:50.640
 There's a how-to on my website, which you can just look at.

00:41:50.640 --> 00:41:52.440
 It's lots of pictures.

00:41:52.440 --> 00:41:53.840
 So it should be very trivial.

00:41:53.840 --> 00:41:56.720
 If you want to get adapters, there's some [INAUDIBLE]

00:41:56.720 --> 00:41:57.400
 online.

00:41:57.400 --> 00:41:58.760
 But you also can get some from me.

00:41:58.760 --> 00:42:00.040
 I have still some parts left.

00:42:00.040 --> 00:42:02.840
 So in case you were interested, just hit me up.

00:42:02.840 --> 00:42:06.320
 Let's talk about the scary FL root.

00:42:06.320 --> 00:42:08.120
 So the problem which we have with Roborock,

00:42:08.120 --> 00:42:09.160
 we're a little bit smarter.

00:42:09.160 --> 00:42:12.480
 They don't give us any debug pins outside, except for USB.

00:42:12.480 --> 00:42:15.440
 And so I got a little desperate.

00:42:15.440 --> 00:42:17.200
 So the first approach which I typically do

00:42:17.200 --> 00:42:19.600
 is I need to complete the device down.

00:42:19.600 --> 00:42:23.120
 So I spend $1,000, get the device assembled,

00:42:23.120 --> 00:42:24.240
 remove the PCB.

00:42:24.240 --> 00:42:26.240
 One thing which I typically do is I remove also

00:42:26.240 --> 00:42:29.360
 the main processor, which is like 400-something pins,

00:42:29.360 --> 00:42:33.680
 and start to map out where the tracks are going.

00:42:33.680 --> 00:42:38.080
 I remove also the EMMC on the backside and do the same thing.

00:42:38.080 --> 00:42:41.280
 So then the big question is like, OK, I take both pictures,

00:42:41.280 --> 00:42:45.160
 put them above each other in my favorite hacking tool, MSPaint,

00:42:45.160 --> 00:42:48.400
 and look at the data sheet and just map down, OK,

00:42:48.400 --> 00:42:49.120
 where are the pins.

00:42:49.120 --> 00:42:51.680
 So you see there, I started to kind of map down, like, oh, OK,

00:42:51.680 --> 00:42:54.120
 I have like RX, TX, FEL.

00:42:54.120 --> 00:42:56.480
 I have like the data lines of the UART.

00:42:56.480 --> 00:42:58.440
 And the same thing I do at the front.

00:42:58.440 --> 00:43:00.360
 So basically I run all the things down

00:43:00.360 --> 00:43:03.400
 and figure out where are the traces for what,

00:43:03.400 --> 00:43:04.920
 so that I have some idea.

00:43:04.920 --> 00:43:07.320
 And one of the things I noticed is actually

00:43:07.320 --> 00:43:11.840
 I can get access to all the EMMC data lines and pins

00:43:11.840 --> 00:43:15.040
 which I need to access EMMC memory from the holes

00:43:15.040 --> 00:43:15.600
 of the buttons.

00:43:15.600 --> 00:43:17.520
 So basically I will just do a quick thing

00:43:17.520 --> 00:43:19.400
 in more that don't have much time.

00:43:19.400 --> 00:43:21.040
 Basically if you just assemble the device,

00:43:21.040 --> 00:43:23.480
 you just remove-- without disassembling the device,

00:43:23.480 --> 00:43:28.200
 you just remove the one cover, and you remove the rubber cover,

00:43:28.200 --> 00:43:30.520
 and you can access everything from this hole

00:43:30.520 --> 00:43:32.600
 without touching any screws on the back.

00:43:32.600 --> 00:43:34.320
 So you don't need to disassemble the device.

00:43:34.320 --> 00:43:37.240
 You don't trash any warranty seals.

00:43:37.240 --> 00:43:41.400
 You can access everything from the holes of the buttons.

00:43:41.400 --> 00:43:43.040
 I think my presentation is gone.

00:43:43.040 --> 00:43:43.680
 Is this my laptop?

00:43:43.680 --> 00:43:57.240
 OK, no, OK, that's me.

00:43:57.240 --> 00:43:58.000
 Sorry about that.

00:43:58.000 --> 00:44:02.540
 OK.

00:44:02.540 --> 00:44:10.780
 This is a faster way to do that, actually.

00:44:10.780 --> 00:44:16.980
 All right, I promise I will be very quick for the last five

00:44:16.980 --> 00:44:20.380
 minutes because I'm running a little bit of the time.

00:44:20.380 --> 00:44:25.180
 OK, so the good news was that I can access all the pins from--

00:44:25.180 --> 00:44:32.060
 I'm so sorry.

00:44:32.060 --> 00:44:33.700
 I promise it worked better at Defqon.

00:44:33.700 --> 00:44:38.720
 OK.

00:44:38.720 --> 00:44:48.460
 So was it scary?

00:44:48.460 --> 00:44:52.860
 Basically we can route the device now without tear down.

00:44:52.860 --> 00:44:54.820
 We can access it from under the cover.

00:44:54.820 --> 00:44:58.300
 And that applies both for S8 and S8 for Ultra.

00:44:58.300 --> 00:45:00.660
 What we can do with that is if you short the data zero pin

00:45:00.660 --> 00:45:04.260
 to ground at boot up, it can't load the file system,

00:45:04.260 --> 00:45:05.260
 even the bootloader.

00:45:05.260 --> 00:45:06.500
 And it will go into bootloader mode,

00:45:06.500 --> 00:45:07.420
 which is kind of great for us.

00:45:07.420 --> 00:45:10.060
 And then we can just splash it again over USB.

00:45:10.060 --> 00:45:12.580
 So it's basically the same approach as for the L10 Ultra

00:45:12.580 --> 00:45:14.260
 or the ARM models.

00:45:14.260 --> 00:45:18.300
 And there will be also how to do that very easily.

00:45:18.300 --> 00:45:19.620
 The question is why is it scary?

00:45:19.620 --> 00:45:22.220
 And the scary part is you need to basically find

00:45:22.220 --> 00:45:23.860
 where the trace is and then kind of market it

00:45:23.860 --> 00:45:24.940
 in this presentation.

00:45:24.940 --> 00:45:26.780
 And you need to scratch off the solder mask

00:45:26.780 --> 00:45:28.100
 and access the copper trace.

00:45:28.100 --> 00:45:29.540
 I would give you a demonstration,

00:45:29.540 --> 00:45:31.460
 but I think I'm running definitely out of time.

00:45:31.460 --> 00:45:34.300
 So maybe hit me up later and I can just show you

00:45:34.300 --> 00:45:36.580
 with a microscope how to do that.

00:45:36.580 --> 00:45:38.900
 Don't do this method by the way if you feel uncomfortable.

00:45:38.900 --> 00:45:40.660
 As an alternative, you can still tear it down.

00:45:40.660 --> 00:45:42.180
 So before you break your device,

00:45:42.180 --> 00:45:44.220
 it might be safer to disassemble it

00:45:44.220 --> 00:45:46.260
 and just connect to the actual pin on the back

00:45:46.260 --> 00:45:47.500
 of the mainboard.

00:45:47.500 --> 00:45:50.980
 If unsure, please ask others.

00:45:50.980 --> 00:45:52.980
 There's a Telegram group where a lot of people

00:45:52.980 --> 00:45:55.340
 did already a lot of experiments of that

00:45:55.340 --> 00:45:57.080
 and did it on their own.

00:45:57.080 --> 00:45:59.300
 So they know how to do that.

00:45:59.300 --> 00:46:01.660
 For the other RoboWork models, a little more complicated.

00:46:01.660 --> 00:46:05.060
 So sadly for most robots, the process model is the same,

00:46:05.060 --> 00:46:07.980
 but we cannot access the flash or the back pins

00:46:07.980 --> 00:46:10.340
 from outside, so you need to disassemble them.

00:46:10.340 --> 00:46:14.820
 Here the alternative way to get into FAL mode

00:46:14.820 --> 00:46:16.300
 is to basically connect to a UART

00:46:16.300 --> 00:46:21.300
 and press the keyboard to while basically accessing it.

00:46:21.300 --> 00:46:24.420
 You can check out also my website,

00:46:24.420 --> 00:46:27.940
 robotinfo.dev for the pinouts,

00:46:27.940 --> 00:46:30.100
 or again ask in the community.

00:46:30.100 --> 00:46:31.900
 So for the last few slides,

00:46:31.900 --> 00:46:33.640
 what can we do with root access?

00:46:33.640 --> 00:46:34.880
 So what do we have now?

00:46:34.880 --> 00:46:36.580
 So we have secure boot defeated.

00:46:36.580 --> 00:46:38.460
 We can run custom software,

00:46:38.460 --> 00:46:40.340
 but what kind of software can we run?

00:46:40.340 --> 00:46:44.700
 And the question is can we build something of our own

00:46:44.700 --> 00:46:46.900
 with like as an operation system of SLAM,

00:46:46.900 --> 00:46:48.600
 navigation and IEI models.

00:46:48.600 --> 00:46:51.400
 Well, to do our own software is a little bit complicated.

00:46:51.400 --> 00:46:52.620
 So our main idea is like,

00:46:52.620 --> 00:46:54.420
 can we just disconnect the device from the cloud

00:46:54.420 --> 00:46:56.460
 and just keep all the vendor logic in place

00:46:56.460 --> 00:46:59.520
 and just run the original software?

00:46:59.520 --> 00:47:02.020
 So one of the questions is like,

00:47:02.020 --> 00:47:03.920
 what kind of different ways we can we do that?

00:47:03.920 --> 00:47:06.460
 Some people think we can just disconnect the cloud.

00:47:06.460 --> 00:47:09.540
 This will make the robot work in most cases,

00:47:09.540 --> 00:47:10.640
 like if you press the buttons,

00:47:10.640 --> 00:47:13.260
 but you will lose the features like live maps

00:47:13.260 --> 00:47:15.180
 or advanced features and map editing.

00:47:15.180 --> 00:47:17.020
 And why root the device if you just basically

00:47:17.020 --> 00:47:18.540
 lose all this functionality?

00:47:18.540 --> 00:47:20.940
 So instead what we try to do is like we try to redirect

00:47:20.940 --> 00:47:22.880
 the cloud traffic to our own software.

00:47:22.880 --> 00:47:24.980
 And for that we need to extract some firmware secrets

00:47:24.980 --> 00:47:29.620
 and basically point it to like a fake cloud emulation.

00:47:29.620 --> 00:47:32.820
 So let's talk quickly about replacing the cloud.

00:47:32.820 --> 00:47:34.940
 The initial approach which we had was to redirect

00:47:34.940 --> 00:47:38.020
 DNS traffic and this was kind of easy.

00:47:38.020 --> 00:47:39.500
 We were just changing the host files

00:47:39.500 --> 00:47:41.740
 and we used IP tables to reroute that.

00:47:41.740 --> 00:47:45.500
 Sadly, Xiaomi who runs the ecosystem, the backend,

00:47:45.500 --> 00:47:46.380
 kind of figured it out.

00:47:46.380 --> 00:47:48.820
 And so what we did is like they started to introduce

00:47:48.820 --> 00:47:50.980
 some content measurements and they basically hard coded

00:47:50.980 --> 00:47:53.460
 IP addresses in the cloud binary,

00:47:53.460 --> 00:47:55.140
 which was a little bit mean because that means

00:47:55.140 --> 00:47:57.300
 that DNS redirection doesn't work anymore.

00:47:57.300 --> 00:48:01.980
 Our content measurement was basically we counter measured

00:48:01.980 --> 00:48:04.340
 their stuff, we just replaced their hard coded IP addresses

00:48:04.340 --> 00:48:05.860
 with our hard coded IP addresses

00:48:05.860 --> 00:48:08.300
 and it was just working fine.

00:48:08.300 --> 00:48:10.220
 So this allowed us to run Balotudu,

00:48:10.220 --> 00:48:13.020
 which is like the custom software which is developed by Zoom

00:48:13.020 --> 00:48:15.700
 and it completely replaces the cloud and the vendor apps.

00:48:15.700 --> 00:48:17.980
 It runs locally in a robot, so you have like one package

00:48:17.980 --> 00:48:21.020
 which has everything in it, like on the robot itself.

00:48:21.020 --> 00:48:22.800
 It features everything which the cloud offers you,

00:48:22.800 --> 00:48:24.860
 like full the robot control, live maps,

00:48:24.860 --> 00:48:27.340
 map editing, the robot configuration.

00:48:27.340 --> 00:48:30.400
 It has a responsive web interface

00:48:30.400 --> 00:48:33.220
 and it works both in mobile and desktop.

00:48:33.220 --> 00:48:35.580
 It gives you also REST RP and the MQTT functionality,

00:48:35.580 --> 00:48:38.780
 which is important for people who run home automation software.

00:48:38.780 --> 00:48:41.740
 The weird thing choice from Zoom was basically

00:48:41.740 --> 00:48:43.100
 to use embedded JavaScript.

00:48:43.100 --> 00:48:44.260
 There might be something more performant,

00:48:44.260 --> 00:48:45.420
 but I mean, it works.

00:48:45.420 --> 00:48:47.260
 These devices are powerful enough.

00:48:47.260 --> 00:48:49.460
 Anyway, to give you some ideas how this looks like,

00:48:49.460 --> 00:48:51.420
 I mean, it's a very nice interface

00:48:51.420 --> 00:48:54.340
 and it gives you all the functionality which you need.

00:48:54.340 --> 00:49:00.460
 One thing, how do you get the custom software generated?

00:49:00.460 --> 00:49:02.020
 There's a website called DustBlooder

00:49:02.020 --> 00:49:03.820
 and one of the reasons why I created this website

00:49:03.820 --> 00:49:06.060
 was basically that Mac users started to break their devices

00:49:06.060 --> 00:49:08.020
 because Macs are kind of behaving a little bit weird

00:49:08.020 --> 00:49:11.100
 how they unpack file systems and repack them again.

00:49:11.100 --> 00:49:12.740
 So I just want to avoid the support cases

00:49:12.740 --> 00:49:17.300
 and just have a website which takes care of that.

00:49:17.300 --> 00:49:19.540
 So basically with this website,

00:49:19.540 --> 00:49:22.860
 you can build your own robot firmwares

00:49:22.860 --> 00:49:26.060
 and they're most of the time reproducible builds.

00:49:26.060 --> 00:49:26.900
 It's easy to use.

00:49:26.900 --> 00:49:30.240
 It works for Dreamy, Roborock, and VioMe, and some others.

00:49:30.240 --> 00:49:34.180
 If you don't trust it, the scripts are online on GitHub.

00:49:34.180 --> 00:49:35.320
 You can just do it themselves.

00:49:35.320 --> 00:49:36.220
 You just need the firmware file,

00:49:36.220 --> 00:49:38.780
 which we can provide you out of legal reasons.

00:49:38.780 --> 00:49:40.740
 But if you're interested in that,

00:49:40.740 --> 00:49:42.620
 you can go to this website.

00:49:42.620 --> 00:49:44.880
 All right, there's a couple more interesting things,

00:49:44.880 --> 00:49:47.980
 but I think I will get torn down by from the,

00:49:47.980 --> 00:49:50.700
 let me maybe quickly go through that.

00:49:50.700 --> 00:49:53.820
 - Exactly, we have a proposal for you guys.

00:49:53.820 --> 00:49:56.940
 As the time has elapsed already and due to technical issues,

00:49:56.940 --> 00:49:59.180
 we already are five minutes over.

00:49:59.180 --> 00:50:01.860
 We just want to give everybody the opportunity

00:50:01.860 --> 00:50:04.220
 to go to the next talk perhaps.

00:50:04.220 --> 00:50:08.860
 However, as this stage will only continue at 12.30

00:50:08.860 --> 00:50:11.700
 with a movie night with War Games,

00:50:11.700 --> 00:50:14.200
 which you could definitely have a watch,

00:50:14.200 --> 00:50:16.420
 we want to also give you the opportunity

00:50:16.420 --> 00:50:19.100
 to share and demonstrate especially the robots

00:50:19.100 --> 00:50:22.420
 you brought here until 12 o'clock.

00:50:22.420 --> 00:50:23.260
 - Yeah, I think--

00:50:23.260 --> 00:50:24.300
 - If that's fine for the crowd.

00:50:24.300 --> 00:50:27.060
 (audience cheering)

00:50:27.060 --> 00:50:30.260
 Looks like it, so please continue.

00:50:30.260 --> 00:50:32.740
 - All right, yeah, sorry for the technical issues.

00:50:32.740 --> 00:50:35.600
 I tested everything before, but you never know.

00:50:35.600 --> 00:50:37.660
 Anyway, what kind of interesting things did you find?

00:50:37.660 --> 00:50:40.820
 Well, we have some camera access.

00:50:40.820 --> 00:50:44.380
 All the devices use the video for Linux subsystem

00:50:44.380 --> 00:50:45.840
 for their cameras.

00:50:45.840 --> 00:50:47.560
 So if you have root access on the device,

00:50:47.560 --> 00:50:50.500
 you can just talk to the cameras via the device notes

00:50:50.500 --> 00:50:52.440
 like video zero, video one.

00:50:52.440 --> 00:50:54.820
 And some of the vendors were even so nice

00:50:54.820 --> 00:50:57.660
 and left us debugging tools for the cameras,

00:50:57.660 --> 00:50:59.660
 like camera demo, which is an all-in-one tool

00:50:59.660 --> 00:51:01.700
 where you can just pull pictures

00:51:01.700 --> 00:51:03.860
 and configurations from the camera.

00:51:03.860 --> 00:51:07.940
 So let me show you some examples from the optical sensors.

00:51:07.940 --> 00:51:11.620
 This is like the Roborock G10S,

00:51:11.620 --> 00:51:14.380
 which is mostly used in China and I think in Russia

00:51:14.380 --> 00:51:15.700
 and some other Eastern European states

00:51:15.700 --> 00:51:17.620
 because we can get it cheaper.

00:51:17.620 --> 00:51:20.700
 On the left, you see the robot seeing itself in the mirror.

00:51:20.700 --> 00:51:23.140
 So some philosophical picture, basically.

00:51:23.140 --> 00:51:25.780
 And on the right is some example of the output.

00:51:25.780 --> 00:51:27.860
 Dreamy is a little bit better,

00:51:27.860 --> 00:51:29.300
 has better, nicer cameras.

00:51:29.300 --> 00:51:31.580
 So on the left, you see the Dreamy L10S Ultra,

00:51:31.580 --> 00:51:32.980
 again, in the mirror.

00:51:32.980 --> 00:51:34.980
 Under the right, you see one of the pictures

00:51:34.980 --> 00:51:36.740
 which it does use for object detection.

00:51:36.740 --> 00:51:38.860
 This is in our lab in Boston.

00:51:38.860 --> 00:51:42.480
 So this is the kind of quality of pictures you get nowadays.

00:51:43.580 --> 00:51:48.580
 This is one where I, this is from the S8.

00:51:48.580 --> 00:51:50.780
 Basically, on the left, it's a little bit weird

00:51:50.780 --> 00:51:54.460
 because I think I didn't have the exposure correctly.

00:51:54.460 --> 00:51:56.420
 On the right, you see my blue elephant,

00:51:56.420 --> 00:51:59.220
 which I left in the tent, I think.

00:51:59.220 --> 00:52:00.060
 So it's not blue here

00:52:00.060 --> 00:52:01.500
 because it has like an infrared camera.

00:52:01.500 --> 00:52:05.000
 So it sees basically just in black and white.

00:52:05.000 --> 00:52:07.860
 Right, let's talk about quick findings

00:52:07.860 --> 00:52:09.420
 which we found at Dreamy.

00:52:09.420 --> 00:52:12.040
 So last time, if people saw the last time presentation,

00:52:12.040 --> 00:52:14.900
 you might have seen some very sketchy things

00:52:14.900 --> 00:52:16.840
 which were left in the firmware.

00:52:16.840 --> 00:52:19.820
 Good news this time, they didn't leave SSH credentials

00:52:19.820 --> 00:52:21.680
 to the backend service in the firmware this time.

00:52:21.680 --> 00:52:24.840
 So that was good for them, I assume.

00:52:24.840 --> 00:52:26.820
 They made a lot of improvements in the software.

00:52:26.820 --> 00:52:29.340
 So the software is more stable, it's more clean,

00:52:29.340 --> 00:52:31.380
 which is also very good for us.

00:52:31.380 --> 00:52:33.800
 One of the bad news is that they introduced a lot of

00:52:33.800 --> 00:52:35.700
 calling home functions

00:52:35.700 --> 00:52:37.780
 and started to enforce geo-blocking by IP addresses.

00:52:37.780 --> 00:52:39.460
 So they introduced a lot of functions

00:52:39.460 --> 00:52:44.460
 where they will detect if you buy a cheap device in China

00:52:44.460 --> 00:52:47.740
 and use it anywhere else, and I think vice versa.

00:52:47.740 --> 00:52:50.340
 So there's kind of some weird stuff going on.

00:52:50.340 --> 00:52:51.640
 Also, one quick thing is,

00:52:51.640 --> 00:52:54.900
 many robots will detect where we are.

00:52:54.900 --> 00:52:56.220
 Roborock does it, Dreamy does it,

00:52:56.220 --> 00:52:58.380
 and a couple other companies do that too.

00:52:58.380 --> 00:53:00.220
 If you're, for example, in America,

00:53:00.220 --> 00:53:02.620
 they will disable some functions in the software basically.

00:53:02.620 --> 00:53:04.320
 So you don't have edge cleaning anymore

00:53:04.320 --> 00:53:08.620
 if you are in the US, if it detects that it's in the US.

00:53:08.620 --> 00:53:10.660
 And part of the reason is apparently that iRobot

00:53:10.660 --> 00:53:12.700
 has patents on that which expire I think next year.

00:53:12.700 --> 00:53:14.620
 So I would expect that this function

00:53:14.620 --> 00:53:16.740
 gets enabled magically next year.

00:53:16.740 --> 00:53:19.020
 Also, some devices have a dust sensor

00:53:19.020 --> 00:53:22.180
 to test how dusty the air is,

00:53:22.180 --> 00:53:23.220
 but it's not enabled in software

00:53:23.220 --> 00:53:25.060
 because iRobot has again a patent on that

00:53:25.060 --> 00:53:26.020
 which expires next year.

00:53:26.020 --> 00:53:28.460
 So I think it's kind of weird patent stuff.

00:53:28.460 --> 00:53:31.860
 So in case of you wondering why they so livid

00:53:31.860 --> 00:53:35.980
 about geo-blocking, it's one of the legal reasons also.

00:53:35.980 --> 00:53:39.380
 So the other thing is Dreamy robots and also other robots

00:53:39.380 --> 00:53:42.860
 support camera monitoring so you can watch your pets remotely.

00:53:42.860 --> 00:53:45.260
 And for legal reasons, most of the time,

00:53:45.260 --> 00:53:47.340
 if you're for actually all the devices,

00:53:47.340 --> 00:53:49.260
 if you enable the remote camera feature,

00:53:49.260 --> 00:53:51.740
 it will warn you via voice prompt and say like,

00:53:51.740 --> 00:53:53.420
 oh, camera monitoring is enabled

00:53:53.420 --> 00:53:56.700
 and it will repeat that every three minutes or so.

00:53:56.700 --> 00:54:00.500
 The, this is I think a legal requirement

00:54:00.500 --> 00:54:01.820
 in many, many countries.

00:54:01.820 --> 00:54:03.900
 And so, yeah.

00:54:05.360 --> 00:54:08.140
 One of the things is that these voice prompts

00:54:08.140 --> 00:54:09.600
 they need obviously to be localized.

00:54:09.600 --> 00:54:12.180
 So for example, you don't wanna hear like a,

00:54:12.180 --> 00:54:13.820
 you know, English voice prompt if you're in Germany

00:54:13.820 --> 00:54:14.860
 and some other things.

00:54:14.860 --> 00:54:17.940
 So the, these audio files are part of an externally

00:54:17.940 --> 00:54:20.300
 downloaded audio pack.

00:54:20.300 --> 00:54:21.620
 The problem with this audio pack is

00:54:21.620 --> 00:54:22.780
 they are not signed or encrypted.

00:54:22.780 --> 00:54:25.060
 So basically you can just override the audio prompt,

00:54:25.060 --> 00:54:26.940
 like this warning audio prompt with an empty file

00:54:26.940 --> 00:54:29.460
 and basically push it onto the device

00:54:29.460 --> 00:54:32.340
 and just disable this prompt and it can spy on people

00:54:32.340 --> 00:54:34.040
 which is probably I think a little bit illegal.

00:54:34.040 --> 00:54:36.020
 So don't do that again.

00:54:36.020 --> 00:54:38.820
 That's probably very illegal in Germany, I think.

00:54:38.820 --> 00:54:42.180
 And the important aspect here is it works on all devices,

00:54:42.180 --> 00:54:43.220
 not only rooted devices.

00:54:43.220 --> 00:54:44.740
 So be a little bit careful

00:54:44.740 --> 00:54:47.380
 if you get device from somewhere else.

00:54:47.380 --> 00:54:50.500
 One of the biggest fails I saw so far for a very long time

00:54:50.500 --> 00:54:52.220
 was how they signed the signatures.

00:54:52.220 --> 00:54:55.240
 So I think this is part of a panic process

00:54:55.240 --> 00:54:58.340
 which we had last year or two years ago.

00:54:58.340 --> 00:55:03.000
 So new robots of Dreamy encrypt and sign the firmware,

00:55:03.000 --> 00:55:05.140
 but in a very weird way.

00:55:05.140 --> 00:55:06.780
 So the firmware payload looks like this.

00:55:06.780 --> 00:55:08.940
 So you have an outside zip archive

00:55:08.940 --> 00:55:10.380
 which is encrypted with static passwords

00:55:10.380 --> 00:55:12.400
 which is different for each of the models.

00:55:12.400 --> 00:55:15.540
 Then they have a random file

00:55:15.540 --> 00:55:18.040
 which is signed with a private key by Dreamy

00:55:18.040 --> 00:55:19.880
 which you don't have.

00:55:19.880 --> 00:55:22.660
 And then you have a zip archive inside

00:55:22.660 --> 00:55:25.520
 which is encrypted with the random files, the password.

00:55:25.520 --> 00:55:29.100
 Well, what's the problem here?

00:55:29.100 --> 00:55:30.660
 Well, the actual firmware is not signed,

00:55:30.660 --> 00:55:31.860
 only the password is.

00:55:31.860 --> 00:55:34.060
 So basically they signed the password,

00:55:34.060 --> 00:55:37.700
 but they didn't sign the actual firmware.

00:55:37.700 --> 00:55:40.280
 So you can basically create your fake firmware update

00:55:40.280 --> 00:55:43.240
 by just reusing the password which we used before.

00:55:43.240 --> 00:55:44.980
 As an analogy, what I would say is,

00:55:44.980 --> 00:55:48.220
 imagine you could prove that the phone is yours

00:55:48.220 --> 00:55:50.140
 if the pin on the phone is the same as yours.

00:55:50.140 --> 00:55:51.780
 So it's kind of like if I have a phone

00:55:51.780 --> 00:55:53.780
 which has the password 1234,

00:55:53.780 --> 00:55:55.220
 well, actually, now that I think about it,

00:55:55.220 --> 00:55:56.060
 the analogy is kind of weird.

00:55:56.060 --> 00:55:57.180
 But okay, it's a huge problem.

00:55:57.180 --> 00:56:00.240
 So that's a very, very huge fail.

00:56:00.240 --> 00:56:03.340
 So basically you can create your own firmware updates

00:56:03.340 --> 00:56:05.500
 which are correctly signed in a way

00:56:05.500 --> 00:56:07.940
 without the private key of Dreamy

00:56:07.940 --> 00:56:09.340
 because we just signed the password

00:56:09.340 --> 00:56:11.340
 and not the actual firmware.

00:56:11.340 --> 00:56:13.100
 All right, as a summary, finally.

00:56:13.100 --> 00:56:16.320
 So we have routing methods for most of the current release,

00:56:16.320 --> 00:56:18.220
 Dreamy and Roborock models.

00:56:18.220 --> 00:56:19.700
 So we can bypass secure boot,

00:56:19.700 --> 00:56:22.240
 we can bypass any other security mechanism.

00:56:22.240 --> 00:56:26.060
 We have persistence, we can run our own custom software.

00:56:26.060 --> 00:56:28.420
 Now we can validate and verify vendor claims

00:56:28.420 --> 00:56:29.860
 which is a very good thing.

00:56:29.860 --> 00:56:32.760
 It's probably what the TÜV should have done some time ago.

00:56:32.760 --> 00:56:36.380
 And the bootloader attack is also pliable

00:56:36.380 --> 00:56:37.540
 to many, many other devices.

00:56:37.540 --> 00:56:39.500
 So if you have smart speakers and they run your boot,

00:56:39.500 --> 00:56:41.460
 then just take a quick look into that

00:56:41.460 --> 00:56:43.180
 if you can manipulate that.

00:56:43.180 --> 00:56:47.100
 And this whole routing method basically allows us also

00:56:47.100 --> 00:56:50.060
 to do further research into IoT and AI.

00:56:50.060 --> 00:56:52.860
 As some final notes,

00:56:52.860 --> 00:56:55.380
 please don't use the knowledge for bad things.

00:56:55.380 --> 00:56:59.100
 If you do routing, please help others

00:56:59.100 --> 00:57:00.460
 if they need help with routing.

00:57:00.460 --> 00:57:04.500
 Not many people are feeling comfortable with doing that.

00:57:04.500 --> 00:57:06.220
 Especially if you have routing PCBs,

00:57:06.220 --> 00:57:08.820
 feel free to share them in your hacker space.

00:57:08.820 --> 00:57:11.400
 The tools are mostly published already,

00:57:11.400 --> 00:57:13.100
 but there's still some work to do

00:57:13.100 --> 00:57:16.860
 because I was a little bit busy over the last couple days.

00:57:16.860 --> 00:57:18.780
 So if there's something not published yet,

00:57:18.780 --> 00:57:21.260
 please be patient, this will be published very soon.

00:57:21.260 --> 00:57:23.540
 If you're interested in more vacuum robot hacking

00:57:23.540 --> 00:57:25.940
 or flash forensics, you can join me

00:57:25.940 --> 00:57:27.380
 at the hardware I own in the Netherlands,

00:57:27.380 --> 00:57:30.020
 which is in the beginning of November.

00:57:30.020 --> 00:57:31.900
 There might or might not be a talk

00:57:31.900 --> 00:57:33.940
 maybe about vacuum robots again.

00:57:33.940 --> 00:57:38.080
 This time not about Robrock or Dreamy, so we will see.

00:57:38.080 --> 00:57:39.820
 So some announcements.

00:57:39.820 --> 00:57:41.380
 I want to thank Dani Wiggema,

00:57:41.380 --> 00:57:44.520
 Giban Obeer, Zirn Baier and Mikael Kolkin,

00:57:44.520 --> 00:57:47.720
 and obviously also all the testers in the community.

00:57:47.720 --> 00:57:50.780
 And yeah, that's my presentation.

00:57:50.780 --> 00:57:53.140
 If you have any questions, feel free to contact me

00:57:53.140 --> 00:57:56.920
 on via Telegram, Twitter or email.

00:57:56.920 --> 00:57:58.820
 And thank you very much.

00:57:58.820 --> 00:58:01.260
 I can also do a quick demonstration of the microscope

00:58:01.260 --> 00:58:04.020
 if you're interested, are you interested?

00:58:04.020 --> 00:58:04.860
 All right, okay.

00:58:04.860 --> 00:58:08.020
 (audience applauding)

00:58:08.020 --> 00:58:11.980
 Let me just change to the camera.

00:58:11.980 --> 00:58:13.900
 By the way, the camp is very dusty as you can see.

00:58:13.900 --> 00:58:17.700
 These robots are not meant for being on a camp.

00:58:17.700 --> 00:58:20.060
 So as mentioned before, for the Robrock,

00:58:20.060 --> 00:58:21.660
 it's a little bit sketchy or a little bit scary

00:58:21.660 --> 00:58:24.740
 because you have to basically remove the cover,

00:58:24.740 --> 00:58:26.060
 which is very easy, you can just remove it

00:58:26.060 --> 00:58:29.700
 and you have here the plastic part, the rubber part.

00:58:29.700 --> 00:58:35.620
 And then you need to find the trace.

00:58:35.620 --> 00:58:39.500
 Oh, oops.

00:58:39.500 --> 00:58:46.460
 As you see, CS people are always tricky.

00:58:46.460 --> 00:58:47.300
 All right.

00:58:47.300 --> 00:58:55.660
 Now let me just change it real quick.

00:58:55.660 --> 00:58:58.820
 (audience chattering)

00:58:58.820 --> 00:59:03.340
 So this is the left button basically.

00:59:03.340 --> 00:59:07.280
 And as you can see in a second, we have there a trace.

00:59:07.280 --> 00:59:15.620
 Which is basically here comes the via out

00:59:15.620 --> 00:59:19.380
 and then goes through here and goes there.

00:59:19.380 --> 00:59:21.100
 So one thing which you can do to basically route it,

00:59:21.100 --> 00:59:23.380
 you take like something pointy, you don't wanna cut it,

00:59:23.380 --> 00:59:26.260
 you just wanna scrape off the trace a little bit.

00:59:26.260 --> 00:59:28.740
 So you take it and you find it anyway here

00:59:28.740 --> 00:59:32.740
 and you just start to scratch.

00:59:32.740 --> 00:59:42.340
 And at some point, so if you use a knife,

00:59:42.340 --> 00:59:45.100
 just scratch it, don't cut it please.

00:59:45.100 --> 00:59:46.540
 And at some point you will see the copper

00:59:46.540 --> 00:59:47.660
 and that should be more or less enough

00:59:47.660 --> 00:59:50.740
 to kind of hold it down for like in a moment

00:59:50.740 --> 00:59:52.420
 when you power the device on

00:59:52.420 --> 00:59:54.220
 and it will go into bootloader mode.

00:59:54.220 --> 00:59:55.860
 So just scratch a little bit.

00:59:55.860 --> 00:59:57.780
 I know it looks scary and you need to have

00:59:57.780 --> 00:59:59.260
 some very good eyes if you have a microscope,

00:59:59.260 --> 01:00:01.860
 it's bonus points but you might use also phone.

01:00:01.860 --> 01:00:02.900
 And as you can see a little bit,

01:00:02.900 --> 01:00:05.780
 you see like already now the copper and that's enough.

01:00:05.780 --> 01:00:07.700
 You just need to have like a very short contact.

01:00:07.700 --> 01:00:12.700
 It's not mission critical basically to keep it in place.

01:00:12.700 --> 01:00:14.860
 Actually, do I see the copper?

01:00:14.860 --> 01:00:17.420
 Yeah, I can scratch even a little bit more.

01:00:17.420 --> 01:00:21.900
 It's a little bit tricky to do it on camera.

01:00:21.900 --> 01:00:25.060
 (audience chattering)

01:00:25.060 --> 01:00:28.740
 The more effort you put into that, the less it's visible.

01:00:28.740 --> 01:00:33.700
 All right, I think it should be.

01:00:33.700 --> 01:00:38.140
 Okay, just imagine but do you see the copper there?

01:00:38.140 --> 01:00:39.740
 You should see at some point a copper.

01:00:39.740 --> 01:00:41.140
 Again, don't cut the trace

01:00:41.140 --> 01:00:44.500
 but you can scratch it off anywhere you want.

01:00:44.500 --> 01:00:47.060
 For the other devices, it's a little bit easier.

01:00:48.340 --> 01:00:52.060
 The scary aspect of rooting the Dreamy devices

01:00:52.060 --> 01:00:54.940
 is to remove the cover and it will feel wrong

01:00:54.940 --> 01:00:57.100
 because you need to use a lot of force.

01:00:57.100 --> 01:00:59.100
 And because I did that already probably 50 times

01:00:59.100 --> 01:01:01.940
 for these ones, this is easier but at some point

01:01:01.940 --> 01:01:04.660
 it just comes off and you have the back pins

01:01:04.660 --> 01:01:06.340
 very nicely here.

01:01:06.340 --> 01:01:09.700
 So from a rooting perspective, Dreamy is great

01:01:09.700 --> 01:01:11.380
 but nowadays we can also root Roborock.

01:01:11.380 --> 01:01:12.780
 So it's kinda like, I mean, you're not limited

01:01:12.780 --> 01:01:14.260
 to one company or the other.

01:01:14.260 --> 01:01:16.340
 You can just decide freely.

01:01:17.140 --> 01:01:18.860
 All right, if you have any questions,

01:01:18.860 --> 01:01:22.660
 feel free to ask them probably after this thing outside.

01:01:22.660 --> 01:01:25.740
 Have a bag of couple rooting adapters left.

01:01:25.740 --> 01:01:27.740
 Sorry for the technical issues.

01:01:27.740 --> 01:01:30.020
 It worked for me before but I mean, you never know.

01:01:30.020 --> 01:01:31.100
 It's computer stuff.

01:01:31.100 --> 01:01:33.420
 All right, thank you very much for being here

01:01:33.420 --> 01:01:35.580
 and thank you very much for your patience.

01:01:35.580 --> 01:01:38.740
 (audience applauding)

01:01:39.020 --> 01:01:41.600
 (gentle music)

01:01:41.600 --> 01:01:44.180
 (upbeat music)