- Hi, I am Dennis Giese,
and welcome to my talk about robots with lasers and cameras,
but no security,
where we will talk about
ways how you can liberate your vacuum from the cloud.
Before we start,
here is some background information about me.
I'm a PhD student at Northeastern University,
and I'm working with Professor Guevera Noubir.
Our research field is wireless and embedded security.
My particular interest is in the reverse engineering
of interesting devices.
I focus on smart home devices,
mostly vacuum cleaning robots.
My current research is in the security and privacy
of smart home speakers.
In our most recent work,
we analyze the security and privacy
of used Amazon Echo devices.
This paper was published on ACM WiSec this year.
Let's talk about the goals of this talk.
First, I would like to give you an overview
of the current development
in rooting of vacuum cleaning robots.
In particular, we will focus on Roborock and Dreame.
We will talk about vulnerabilities and backdoors,
and I will explain new methods,
which you can use to root your device.
As a general side note,
I have no intention of bashing the companies.
I like the products,
and I think we have maintained a very friendly relationship.
However, obviously our goals are slightly different.
All right, let's talk about our motivation.
So why do we want to root devices?
Well, as devices have powerful hardware
and a lot of sensors,
we can play around with interesting hardware.
This is especially interesting for people in education.
Then we want to stop devices
from constantly calling home.
Also a lot of people have already
custom smart home services running,
for example, Home Assistant,
and here it is interesting to connect the vacuum cleaners
to that system.
And finally, you want to verify the privacy claims
of the manufacturers.
So why don't we trust IoT?
Well, IoT in general,
they're always connected to the internet
and then your home network.
The cloud communication is encrypted,
and you don't really know what kind of data is transmitted.
From our experience we know
that developing secure hardware and software is hard
and that IoT devices are not always being patched.
Also vendors sometimes contradict each other
in regards of their privacy claims.
And as an end user,
you have no way to be sure.
All right, here's an example.
Roborock claims for their flagship model
that nothing is sent to the cloud,
especially what is recorded by the camera.
This claim was also certified by the German TUV.
However, on the same website,
they show that you can access the camera remotely
from your phone.
For example, you can watch your pets and talk to them.
Let's talk about the problem of used devices.
A lot of people order devices on Amazon,
try them and return them.
So used devices are not that rare.
As a buyer, you have no real information
about the past of the device.
So a malicious person could have installed
a rootkit onto it.
As a new owner you have no way to verify the software
and as a result,
you might have a malicious device in your home network.
So rooting is the only way for you to verify
that the device is in fact in.
All right, let's take a look into the past,
the good old times of rooting.
My first work with vacuum cleaning robots was back in 2017.
Here I've worked with Daniel Wegemer,
and we were looking at the Xiaomi Vacuum clean robot
and the Roborock S5.
We figured out that the firmware images of just devices
were unsigned and encrypted with a very weak key
and that custom firmware could be pushed
from the local network,
As a result,
it was possible to root a device without disassembly
and develop custom software and voice packages for them.
We published our findings on the 34C3 and back in 2017
and also on DEF CON exactly three years ago.
Here we'd like to give you some short recap
about the hardware of the Xiaomi vacuum robot and the S5.
Both robots were running on quadcore CPU
and have 512 megabytes of RAM.
They had also 4gigabyte of eMMC flash.
They had a lot of sensors
and in particular, the most important ones
are the lighter sensor on the top of the robot,
the infrared sensor and the ultrasonic center.
These devices also have some debug ports,
for example, USB and UART,
however, a USB was kind of protected
and we never used this for anything.
To give you some background information about the software.
This device is run off Ubuntu 14.04,
mostly untouched.
However, the vendors obfuscated a root password.
Interestingly,
the vacuum cleaners were controlled by the player software,
which is basically an opensource
robot device interface and server.
So they used open-source software to run the devices.
But a lot of proprietary software on them,
for example, they use the custom adbd version
which had some authentication
so we couldn't really use it.
They run a custom watchdog,
which make sure that the device didn't crash,
but on the other side also enforce copy protection.
And they had a logging tool
which uploads a lot of data to the cloud.
They protected the ports on the device with IP tables,
for example,
they blocked port 22 for SSH
and blocked also the player ports.
However, the interesting thing was,
that the IP tables rules only apply to IPv4.
So if the device got an IPv6 address,
it will not firewall at all.
Alright, let's look on how the forces strike back
and how they started to lock down devices.
Well, the first steps in locking down we saw
with newer S5 firmware.
So here Roborock did block local firmware updates.
Interestingly, this change was also pushed through
other IoT devices from Xiaomi
so most devices were basically blocking local firm updates.
We saw more changes with the introduction of the Roborock S6
which came out in 2019.
For example, the firmware and the voice packages
were not signed,
so we were not able to create
our own custom voice packages anymore.
Each model also used different encryption keys.
So if we had encryption keys for one model,
we were not able to depcrypt firmware for a different model.
They also started to sign the configuration files
to enforce region locks
as many people bought cheap devices from China
and modified them so that we were able to use them
out of mainland China.
One interesting aspect is that most of the hardware
remained mostly the same
so most of the changes were basically just done in software.
All these changes meant that
in order to get root access onto the device,
we need to disassemble it.
One thing, which we thought back when this device came out,
that they might need to keep rooting method secret.
And so in the first two weeks
when I got the Roborock S6,
I was able to root it and developed two different methods,
one where we're expected to root passwords via UART
and they obfuscated it so I could get access to
obviously UART for example,
And the other way was,
I booted into a single user mode and modified files there
so that I had SSH access.
Back then I didn't publish the methods for some time,
as I assumed that Roborock would lock them down
as soon as we know about them.
So this is what you had to do to get root access.
You had basically to solder a virus to the test patch
to get the UART port.
With routing we made some observations over time.
Every time we publish a method, it got blocked
and here are some examples for blocking.
For example, local updates, which we published in 2017
were from firmware updates in 2018.
The root password method which I published in 2019
was blocked in newly produced devices back in 2019.
And U-boot bypass was fixed for new models in 2020.
So there was one model which came out at this time
and it was already patched.
This means basically that all current public methods
are basically blocked.
All right,
let's talk about the development of Roborock models
over time.
So we only will talk about global models.
There are way more models like in mainland China,
but in this case, I just want to talk about global models.
On the left side, you see the size of the RAM,
on the right side you'd see the size of the flash,
and this becomes more important later.
In 2016, Xiaomi released the V1,
which was basically your end product by Roborock.
Roborock released the S5 under their own name in 2017.
In 2019, we saw more devices,
we saw the Roborock S6 and the S6 Pure
and the Xiaomi M1S which was again, OM product.
In 2020, we saw the S4 Max and S5 Max
and their flagship model, the S6 MaxV.
And this year we saw the Roborock S7.
If you had to price,
then you see that higher prices do not really correlate
with better hardware.
Also one thing which we notice is that
manufacturers are recycling hardware in different models.
For example, the Xiaomi Vacuum Robot
has more or less the same hardware as the Roborock S4.
The Roborock S5 and the Roborock S6
are more or less the same.
And as you can see on the bottom,
the S6 Pure, the S4 Max, the S5 Max and the S7
have the same main board
and more or less the same hardware too.
However, the prices are very different for them.
As a conclusion, one thing which we notice is
that the hardware gets weaker over time
despite the devices getting more expensive.
Roborock has two vacuum cleaners which are special.
Both of them contain a camera,
which is a little bit more critical in regard to privacy.
The first one is the M1S which was released in 2019.
Instead of using an alternate chip,
this one uses a Rockchip Quadcore,
which has five megabytes of RAM,
four gigabyte of eMMC.
It has a lighter sensor,
which we already know from other models,
but in addition to that,
it has also an upward facing black and white camera.
It does have an ultrasonic distance sensor in the front
and infrared sensors.
To give you a perspective of the camera,
I record this video of the room with vacuum cleaner,
and I used Gstreamer for that.
The second model with a camera
is the Roborock S6 MaxV.
This is currently the flagship model.
It was released in 2020 and contains a Qualcomm Octocore
as you will see.
It has one gigabyte of RAM,
four gigabyte of eMMC flash.
In addition to the lighter,
it has also two color cameras in the front,
which are illuminated with infrared.
And attach the usual infrared sensors.
In the bottom left,
you can see the stereo camera of the device.
In the bottom it has the infrared illumination.
So this device will see in the dark.
On the right you find screenshots from the app.
As you can see the vacuum cleaner
can accurately detect objects and can avoid them.
This is also quite interesting, again, for privacy reasons.
If you look at the software of both devices,
both of them are very similar.
They use Android as the operating system
and the controlling software for the robot
is very similar to the previous models.
The software access the cameras
via the video4linux subsystem.
There are a lot of libraries which are used,
but the more interesting ones are OpenCV, OpenCL
and Tensorflow Lite.
Roborock learnt from the past
and added a lot of security measures to their device.
For example,
secure boot is enabled and they make use of the
replay-protected-memory-block as a downgrade protection.
The system partition is integrity protected with DM-Verity
so we cannot modify it.
Also, a lot of petitions are encrypted with LUKS,
in particular all the applications specific programs
are stored on an encrypted partition.
The keys for these petitions are stored in OPTEE
which is using ARM TrustZone,
but there are more security features.
For example,
Roborock added a kernel-based verification of binaries.
All binaries before we get executed
are checked for the correct signature.
This means we cannot really put any custom binaries
onto the system.
Also the signed and encrypted firmware updates.
This time, each of the firmware versions
has a different key.
The master keys itself are stored in OPTEE
and using TrustZone.
And interestingly, they modified the IP tables binary.
Traditionally, what we did for rooting,
we removed all the fiber roots
as soon as we root the device
so we could access SSH and other tools.
However, Roborock removed the ability of IP tables
to flush or delete rules
so as soon as rules were added to IP tables,
we cannot remove them anymore.
And they locked also UART,
so we cannot use UART to get root access.
All right.
We had some petitions which are especially interesting
on these devices,
which we need also later for our root.
There's the app partition
which contains the device credentials
and some other configuration files.
This partition is not protected by LUKS or DM-verity.
Then we have two copies of the system partition.
One of them is the active one,
one of them is the passive one.
Both partitions are protective of DM-Verity
so we cannot modify them.
Then we have two application partitions,
again one active and one passive copy,
which are encrypted with LUKS,
however we are not integrity protected.
They have a reserve partition,
which contains the calibration data.
This one is again encrypted.
and they have the user data partition,
which contains the log files and the maps,
and it's again it's encrypted with looks.
So let's talk about the new routing methods for Roborock.
Currently they have three models of vacuum cleaners
which have no public root.
This is the Roborock S7 which came out this year,
the M1S and the MaxV.
Let's start wit the Roborock.
So the Roborock S7 has more or less the same main board
as the S5 Max, S6 Pure etc.
However the problem is that they patched U-boot
so we cannot use UART anymore to root it.
In addition to that, the RootFS is a read only Squash FS
so even if you have access on the device,
we cannot modify the partition.
I developed a new method for this device,
which was FEL rooting.
This method doesn't require any soldering,
however it requires still that the device is disassembled.
This method also automatically patches the root FS
and enables SSH.
And it applies to all current NAND based Roborock models.
In order to find a new rooting method,
we need to reverse engineer the PCB.
We knew already where the UART pins were,
but we are useless after they blocked this functionality.
However, all the Allwinner SOCs have the so called FEL mode.
FEL mode is a low-level mode
which allows the flashing of the device.
And it is burnt in the SOC ROM
so it cannot be modified.
The idea is to load a custom OS via FEL.
There are two typical matters to trigger the FEL mode.
First, we can somehow disabled the flash chip,
for example, by grounding D clock,
wherever this method might be risky
if you don't do it correctly.
And the second one is, that we can pull the BOOT mode pin
or trigger the FEL pin.
The problem with this is we need to figure out
where this pin is.
So I got myself a spare PCB and did
destructively de-solder the associate chip.
After I did that,
I probed all the pins and was able to find
the incorrect pin.
For example, like J-tech or the boot mode selection.
And by having this, we can use it to trigger the FEL mode.
So how does this approach actually work?
The challenge for Allwinner SOCs is that
the NAND support the proprietary.
So we cannot use a main line kernel
or mainline U-boot.
So my approach was the following.
I extracted a current configuration
from the Roborock kernel.
I created my own InitramFS with Dropbear, SSH keys,
and some tools.
I compiled a minimal kernel
using the Nintendo NES classic sources.
The Nintendo NES classic uses the same chip
as the Roborock vacuums.
I created my custom U-boot version
and with a different extractor to Roborock configuration.
And I triggered the FEL mode by shorting the TPA17,
cause it's the boot selection pin, to ground.
Then I loaded U-Boot, kernel and the initramFS into the RAM
and executed it.
After I did that,
my custom has booted, patched automatically the root FS
and I had root.
How does the patching process exactly look like?
First we need to boot into the FEL image,
then we need to just decompress the Squash FS.
After that, we patched this image.
For example, we installed the authorized key file
and the custom Dropbear server.
We compressed the image again,
and overwrote the partition with the new image.
And as a result we have SSH access and root.
So what are the advantages of this new method?
Well, first we don't need any soldering anymore.
We just can short the mode pin one time
and we were able to go.
It's a very simple process,
and it also allows to restore bricked devices,
which was not possible before.
And also one important thing is that it can be used
for Allwinner based vacuum cleaners.
So now that we have root for the Roborock S7,
let's take a look at the camera based models.
So if you want to root the M1S and the MaxV,
we have some issues.
First, all the ports are closed or firewalled.
The file systems are encrypted or integrity protected,
and the USB interface is protected with some custom ADPD.
So to get root access, we need to have a layered approach.
First, we need to break in by USB,
then we need you to disable the SElinux
and then patch the application partition.
And as an important note,
while it might be possible to root these devices,
it might be impossible for many people.
So don't expect it to be that easy as for previous models.
All right, level one, get ADB shell.
If we connect over USB,
we need to do a challenge response authentication.
This authentication is based on the VINDA secret,
which we don't have.
So Roborock has it probably somewhere in a database.
The secret is also device specific.
Also the ADB is controlled
over a special configuration file,
which we might need to modify.
All the files are stored on a default position
and are thankfully not protected.
So our idea is to follows.
First, we need to connect to the flash,
for example, via in system programming
or by de-soldering it,
then we need to create or extract VINDA secret.
And then we use a tool to compute the challenge response.
So for the M1S we can do in system programming
by soldering small virus on the bottom side of the PCP.
The pictures which you see here are from my experiments
where I use the SD card as a replacement for the eMMC flash.
But the pin on this model is the same.
As an important warning,
if you don't know what you're doing,
you likely will break your device.
So I tried both methods,
but I figured out ISP access can be sometimes tricky.
So what I did instead was I used an adapter
to read out the chip,
which requires reflow soldering to remove the chip
and re-balling and then re-soldering it again.
Okay, what are the results of level one?
I have a more detailed how to on my website.
However what I did here is I set the VINDA secret to or use.
After I connected the device via USB,
I needed to extract the serial number from it.
So I ran ADB devices,
the serial numbers required
for the challenge response process.
In the next step I asked the device for a challenge.
So as you see here, I got like a random string back,
which is the challenge.
In the next step I used the tool VINDA
to generate a response.
So at this point,
I want to thank Erik Uhlmann for his support and help
to create this tool.
Before that I was computing the response manually,
but he extracted and got the function
and just put it in a C program
so now we can just run it from the shell.
The result of this program
is basically the response.
And as soon as we have that,
we can just run any commands which we want to do,
as you see here.
We have no shell access,
but SELinux is still enforced.
SELinux will prevent us from doing specific things.
Even if we are root.
For example, the network access is blocked
and we don't have any access to the dev directory
so we cannot mount partitions or access devices.
However, we can do two things.
We can do bind mounts and we can issue the kill command.
So the idea to disable SELinux is as follows.
First we copied a miio directory to a temporary location.
The miio directory contains the Xiaomi cloud client,
which is launched by the watchdog.
The watchdog has all privileges,
and it makes sure that if the new client is crashing,
that it gets restarted.
In the next step we replaced the miio client
with a bash script,
which disables SELinux.
In the next step,
we mount this temporary location
back to the original location.
If we now kill the miio client,
the watchdog will restart our bash script
instead of the real miio client.
So hopefully SELinux gets disabled.
Let's take a look if this works also in practice.
In this case, what we need to verify first,
is that is SELinux is actually enabled.
So with the getenforce command,
we get the response that it's enforcing.
In the next step we check the process ID
of the miio client process.
So we see the regular processes running.
Now, we copy the miio folder to a temporary location
and write our bash script into the client.
The client is not an alpha anymore.
Instead, it's a beta script.
Now, we bind mount this folder to the original location
and we kill the miio client.
And now hopefully the bash group has executed
and we can check it with getenforce,
and we see it's permitted as SELinux is disabled.
Let's do level three.
We have no full root access,
however, it's only temporarily.
So as in the moment when we restart the vacuum cleaner,
we lose root access.
So the good thing is the app partition
is not integrity protected.
If you modify information there
then we don't have any issue.
By modification of acute scripts,
we can disable SELinux and start Dropbear on different port.
The reason why we want to start Dropbear on a different port
is that IP tables still blocks the port 22.
As I mentioned before,
Roborock modified the IP tables binary
so that we cannot delete rules,
but instead we can just use a different port.
We are still limited
by the ELF binary signature verification.
However, we found a backdoor in this function.
If you give a binary a particular name,
then it is whitelisted.
We can even point symbolic links to this binary.
Many thanks again to Erik Uhlmann at this point,
which helped me to figure that out.
Let's do the demo again.
I want you to run Valetudo on my robot.
Valetudo is a cloud replacement,
which allows to control your vacuum robot locally.
As you can see here,
I downloaded it with we get into a temporary directory
and I try to launch it.
However, I got a segmentation fault.
Typically segmentation faults happen
if some libraries are broken.
However, when I was looking at a kernel lock,
I saw that the verify elf function kicked in
and stopped the execution.
So now let's try a trick with the whitelist.
So we renamed the Valetudo to the binary
to the whitelisted name.
As soon as we run the whitelisted name,
you see Valetudo is starting happily and everything works.
So now we have full root access
and can run our own binaries on the system.
So some other ideas for these vacuum cleaners,
well, we can ask OPTEE nicely
to decrypt firmware updates for us as we have root access
and as we have still a secure system,
OPTEE will happily decrypt firmware updates for us.
Also, we can access to the cameras directly.
For people who understand how TensorFlow light works,
you can take a look at the machine learning models
of the vacuum cleaner.
I myself have no idea how this works
so I didn't take a look at it.
And we can take also a look at the other backdoor.
So there is some hidden functions
which wait only to be explored.
So as a summary about Roborock,
well they have an easy method to root the S7 vacuum cleaner
and some other models.
We have also a rooting method to root the M1S and MaxV.
However, this method is dangerous
and will likely break your device.
It's mostly only feasible
if you have the equipment and experience.
So regard this root as a proof of concept
and that we technically can root these devices.
However, I don't think that it will be useful
for a lot of people.
As a general recommendation I think at this point,
I would say that we should try to avoid new Roborock models
if you want to have root.
Part of the reason is they lock down the systems.
And the other reason is that due to the weaker hardware,
we will run into resource issues
if you try to run custom software onto them.
All right.
So we need a new alternative,
and the great thing is there's a new player
in the field of vacuum cleaners,
which is Dreame.
Dreame is a great alternative for us.
They released their first model back in 2019,
and they produce OEM products also for Xiaomi.
They have four different kinds of vacuum cleaners
which they produce.
The Xiaomi 1C and the Dreame F9
are VSLAM based models,
so we have a camera which was looking on the ceiling
and we create a map via that.
The Dreame D9 has a more traditional, lighter sensor,
similar to the Roborock devices.
The Xiaomi 1C has a VSLAM and ToF camera
so it can scan produce scan objects
which are in front of it.
And the current flagship model is the Dreame L10 Pro
which has LiDAR and Line laser and a camera.
All of these devices are based on various Allwinner SoCs
Dreame uses for their device, a custom Android,
which is mostly based on the Linux
which has provided Allwinner.
The company developed their own robotics software
which is Ava.
So let's take a quick look on
what kind of sensors you can access on these devices.
These pictures were recorded on rooted vacuum cleaners.
As you can see here,
there's a camera which was looking onto the ceiling.
And if you root your devices,
you're able to access these cameras.
The Xiaomi 1T has an additional camera in the front,
which is a time of flood camera.
With that you get a point note of objects
which are in front of the vacuum cleaner.
The Dreame L10 pro uses line lasers
to detect objects in front of it.
As you can see on the right,
the device creates two laser beams
and if there's any object in front of the device,
the laser beam gets distorted.
The camera will pick up this distortion
and will determine how far away the object is.
So let's talk about how we can root Dreame.
The routing of the device is surprisingly easy.
So I bought my first Dreame robot when I was in China
back in 2019.
And it took me only a couple of days to root the device.
The good thing is with all the devices
have the same debug connector,
which can be accessed without breaking any warranty seals.
I did do a lot of reverse engineering
and I was able to extract the key material and firmware.
Also I reverse engineered ways
to create proper FEL with this.
So with the help of the Banana Pi tools,
which are also based on Allwinners SoCs,
I was able to create those images
which you can use to flag to devices.
To flag the device you need unfortunately to use
a Windows only software, which was Phoenix USB.
There might be also ways to flash it over Linux,
but I didn't investigate that.
So how does this debug interface look like?
The debug interface has 2x8 pins,
and it has a pitch set of two millimeter.
The two millimeters are way smaller
than the typical jumper wires which you get.
If you plan to connect it with (indistinct)
then make sure to connect to the right pins.
The debug interface
gives us a couple of interesting interfaces.
For example, we have USB,
we have UART and we have the boot selection pin.
I saw that there's also like another UART there
and likely J tech,
but I didn't investigate further.
To easily root a device,
we created custom PCBs
which enable you to easily access the USB and UART.
There's a simple version which just gives you a USB
and gives you the UART headers,
and there's an advanced version
which has an onboard serial controller.
I want to thank at this point, Ben Helfrich
who created these boards in (indistinct)
and at the bottom of the slides,
you find a link to the Gerber files.
Here are some examples how you can connect them.
For example, for the PCB,
you can insert it and you just have to make sure
that you have the right orientation,
that you don't fry the board
and you can just connect USB and UART.
If you don't have this board,
you can also use jumper wires,
but you need to be a little bit more careful
and make sure that the connection is properly done.
On the bottom there's a diagram
how you need to connect everything.
Let's talk about some interesting findings
which I saw when I reverse engineered the Dreame firmwares.
So all the devices have an ultra SSH backdoor.
This can be triggered from the cloud.
What this will do is it will create a reverse SSH shell
to one of Dreame's servers.
The interesting thing here is
that they hard-coded the credentials to the server,
which is public facing.
The bigger problem is that this user,
which is used to create this reverse SSH
has sudo rights on that server.
And it appears that the server is used for development.
I don't really know why they did that,
but this seems like a really, really bad idea.
Scary thing which I found were the startup debug scripts.
These scripts were downloaded over FTP
from some personal developers NAS.
These scripts are also executed at boot up for some devices.
The same debug scripts are also uploading lock files
onto that NAS
and the admin credentials are implanted in that script.
All of the vacuum cleaners have predictable root passwords.
For example, devices with a production firmware,
you can compute the root password from the serial number.
For devices with debug firmwares,
there's only one valid password.
So knowing that,
it might be a bad idea to connect your vacuum cleaner
directly to the internet.
I found also a lot of chatty functions.
The cloud IP allows the execution
of some of the debug functions.
For example,
someone can trigger the recording and uploads of pictures
or the recording uploads of camera records
for devices with cameras.
And the device also produces a lot of loc files.
The only way to prevent these uploads is basically rooting.
I don't know if these functions
are used on the regular basis by the developers,
but the fact that these functions exist is kind of scary.
As a summary about Dreame,
the devices are cheaper than Roborock
and they have also performance hardware.
This makes the device as the perfect target for rooting.
As I'm working on the rooting
for quite quite a time already,
I was able to work with the developer for Valetudo
on the support on the device.
So I'm happy to announce that all Dreame devices so far
are fully supported by the Valetudo since April, 2021.
All current models can be rooted without any soldering
and this also applies to all devices
released before August, 2021.
There will be some devices in the future,
we don't know yet if they are routable or not,
but we will figure out very soon.
The Dustbuilder is a website
to build your own custom robot firmwares.
You can create reproducible builds.
It's easy to use,
especially for Windows users.
In the past,
we had a lot of trouble with Windows and Mac users
where building firmwares were kind of tricky.
So this tool kind of makes it way easier.
The Dustbuilder works for
Dreame, Roborock and Viomi devices
and it's a perfect alternative to local building.
Wherever if you don't trust it,
the tools will be still published on GitHub.
You find Dustbuilder under a builder.dontvacuume.
At the end I want to thank a few people
which supported me in doing this presentation
and doing the research.
I want to thank Ben Helfrich,
Carolin Gross,
Cameron Kennedy,
Daniel Wegemer,
Erik Uhlmann,
Guevara Noubir,
and Soren Beye.
If you have any questions,
feel free to contact me via email, telegram or Twitter.
Visit my website for any additional information
or meet me here at Defcon if you're around,
if you happen to have a Dreame robot
or plan to get a Dreame robot,
I have a couple of spare PCBs with me
which you can pick up for free.
Thank you very much and have a nice Con.