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