Thought I was just buying a smart vacuum. Turns out, it was a little spy on wheels.
Here’s the story of how my vacuum stopped working after I blocked its data uploads — and how I uncovered a hidden remote “kill switch.”
Hi, thanks for describing what you’ve found — but the details shared aren’t enough for the community to reproduce your findings.
What hostname/s did you block? What filename prevents auto-reboot? What firmware version is your device? Were any credentials necessary to access your robot’s internal syslogs? Was the remote always precisely 8*86400 seconds after you powered on the repaired model?
The repository contains only the barest “how to repurpose this device” details with no supporting material evident for your post’s topic, “what the OEM OS was doing”, which makes the final paragraph either wrong or misleading. Do you have a timeline in mind for when that will be published to GitHub?
The story is marginally interesting, but without the technical details, it’s more “this is completely unsurprising, see also nearly all in-home smart devices” and less “this is novel and interesting”. (I concur with the outrage, but outrage alone does not satisfy.)
This reveals a whole new channel of modern warfare. Imagine a nation state getting control of an adversaries' smart devices? You don't need to destroy capital-intensive infrastructure such as an electric grid if you can disable their ability to store and cook their food (internet connected ovens and refrigerators). That's morbidly fascinating, though I now realize I'm potentially open to such an attack.
It struck me recently how vulnerable we are to small disrutpive attacks of the sort you mention, and more. For example, several major European airports were closed recently due to unidentified drone activity around them. I don't know if the authorities have figured it out, but in theory someone could cripple air travel for the cost of a few anonymous drones.
Check out Mr. Robot S2E1, where someone is terrorized by their hacked smart house. Or 1977's Demon Seed, a film where an AI house does worse things. I really thought the latter would remain fictional, but I'm less sure now.
> This reveals a whole new channel of modern warfare. Imagine a nation state getting control of an adversaries' smart devices?
I expect there are oodles of sci-fi references to this already, but in particular I remember an audio-log from the game Horizon: Forbidden West, where a hacker is critiquing some shady corporate research he found, implying a project to weaponize domestic robots:
> There's the Moldova brain-hack of course, but also up and coming little devils like the know-it-all MEMEr, or my personal favorite, Sovereign 7482.
> Now that's an apex predator. Assuming control of them Ti-D-O bots and arming 'em with household appliances? Imagine tidying up after that! Gotta admit, it'd be fun to see 'em hunt in the wild.
Lesson learnt: Best thing to do for a smart device is not connect them to internet from day one. Though it beats the purpose to some extend, we don’t have an option of buying dump devices anymore.
Well, one of the big upside of the modern smart vacuums is you can see the map it built, set up rooms or zones, do a virtual cleaning, etc... This (1) definitely requires some connectivity, and (2) has to go via central server if the phone is not on same subnet.
Sadly, because of (2), most (all?) companies don't bother with local connectivity at all. Much easier to debug one codepath (via remote server) rather than two (remote server and direct connection).
So yeah, if you are worried about device being remote controlled by its manufacturer, don't buy devices which say "Can be remote controlled" right on the box. But of course then you are back to ancient tech, setting physical virtual wall devices or bounding the clean area with overturned chairs.
That was my one condition when an air fryer entered the house. No connecting it. When they’re putting WiFi on the cheapest models you know it’s a profit center in spite of you not paying for it.
I’ve been doing this a long while, but I’m finding it harder as more devices share my WiFi credentials with each other without my permission/consent/or even knowledge.
I recently moved into a new home and decided to take the opportunity to replace everything; it’s been surprising how many things are just coming to life. TVs, vacuums, kitchen appliances, etc. Some of my new TVs won’t even let me use the microphone on the remote until I give it my WiFi password. It’s quite ridiculous the world we’re creating for ourselves.
Very dramatic presentation for something very mundane. Every computer has "remote control" of some sort - if anything, to install security updates. Without security updates, there is a good chance your devices will turn into huge botnet at some point. I believe that EU CRA even requires such backchannel.
I can agree, however, that refusing to work without internet is be too much for the device which can support offline operation.
Remotely triggered security updates are very common. But my experience in seeing remote command execution to disable a device is bit concerning. Having rtty software installed is another nightmare. Not sure if you call all these mentioned in the article mundane
You are letting it connect to manufacturer's servers, and allow it to execute unknown commands. You know that one command, "501", disables vacuum. There is a very good chance that there is some other remote command with "remote exec random command" functionality, you just didn't see it. There is also a good chance that there are already commands for any creepy things you might want to be worried about (like send camera video).
So, given that, why are you worried about rtty specifically? It's likely a redundant debugging channel in case the main app crashes. It does not add any special functionality that main app does not have.
Now re "disabling the device" - I wonder what command means? Could it be something like "local logs buffer full, pausing operation until upload is done"? Thinking about this more, your blog basically says:
1. vacuum works fine
2. you disable half of the ports on the firewall
3. vacuum stops working
4. you send it for warranty repair
I was very surprised to see that 4 was "send it to warranty repair", instead of "re-open ports on firewall and see if it starts to work now". Did you try this? If not, then it's pretty likely the vacuum was not "bricked" in any sense, but rather was waiting forever for its logs to get uploaded.
The home office literally sshing into your appliance is a little surprising, but years ago when it came out that Tesla was doing this regularly to cars, I remember a lot of people saying this was common practice. (Maybe for things bigger than vacuums.)
The article is very vague on what actually caused the shutdown. Does he think a human triggered the kill command? Or the remote servers do this when they haven't heard from the device in a while? Or the device shuts itself down if it can't reach the servers?
- wasn’t just a vacuum cleaner; it was a small computer on wheels
- they didn’t merely create a backdoor; they utilized it
- they hadn’t merely incorporated a remote control feature. They had used it to permanently disable my device
> That was the moment my vacuum ceased functioning. The timestamp matched precisely with when it had stopped working, even though I hadn’t touched the app.
> Someone—or something—had remotely issued a kill command.
Uuuuh are you sure that you're not reading a bit too much into the word "REMOTE" in that logline?
These are some very strong accusations and opinions that to me don't feel like they're being backed up with equally strong evidence. At least not evidence that is part of that post.
What even is a RS_CTRL_REMOTE_EVENT?
Did you maybe check with e.g. Ghidra?
Your room dust now is being sucked up without swirling up a cloud, which is well and good---yet somehow you can't write the story about it without AI, or host it without the cloud.
The "kill switch" thing ridiculous dramatization, but I wonder if these telemetry endpoints are open and, if they are, how damaging would be flooding them with plausibile but incorrect data for a sustained amount of time.
I'm surprised they didn't push back when they said it was out of warranty. They send it in for repair, and it was never fixed. They can either continue the process of trying to repair it, or refund the original cost of the device.
This kind of intentional remote bricking should be super illegal. I would really like to see a law that would allow the customer a full refund of the original purchasing price if the manufacturer remotely disables advertised functionality of a device for whatever reason. Because this kind of deceptive behaviour needs to be slapped down hard.
1. Has the technical skills to disassemble this device, trace circuit boards, design his own boards and custom software to interface with components to substantially reverse engineer this device.
2. Is totally mystified when his internet connected device stops working after he blocks its communication, and rather than try unblocking it and seeing if it works again, sends it out for repair repeatedly.
Something here doesn't add up. Tastes like bullshit to me.
I am the author of this article. And I tried unblocking every time it went down. But my experience was, once it got bricked, it never started. So flashing was necessary to get it up and running. I missed adding that info in the article.
My guess would be that the manufacturer didn't remotely block the device, but rather the device itself did.
If last connection time < N days ago and last M tries connecting were unsuccessful, then: brick myself.
Still shitty, no doubt (and very similar to planned obsolescence), but the customer can un-brick by resetting to factory like they did in the service center.
He's insisting that they repeatedly remotely disabled his device in retaliation for blocking their data collection...
...yet they paid for the device to be shipped back and forth and inspected several times under warranty, presumably costing them $$$$?
It makes zero business sense to break your customer's products intentionally, which will lead to 1-star reviews and expensive support.
Plus, I hate to be the "this sounds like it was written by ChatGPT" guy, but this does. People don't write like this:
> Deep within the robot’s startup scripts, I discovered the smoking gun.
> It came back to life instantly. They hadn’t merely incorporated a remote control feature. They had used it to permanently disable my device.
> I may have lost my warranty, but I won back my autonomy.
Also, the idea that someone would waste months (?!) of their life on some broken vacuum cleaner until they "had a complete understanding of how the hardware was designed, down to each chip and wire connector" is just not real life. This is more like someone with a mental illness related to obsession, unless they're starting their own smart vacuum company.
I'm guessing this is 100% fiction from ChatGPT. Complete with the AI-generated image.
Lucky you, my Roborock won't even load the map without mothership connection, not to mention full cleaning. Seems like all SLAM and pathfinding is done remotely, crazy.
[Update #1] Author here:
I made some further progress.
1. Like a few comments mentioned here, the remote event happens for multiple reasons. Especially triggered by their app when you start or stop cleaning etc. I missed mentioning it in the article. The one I showed was suspicious as the device got bricked just after that event.
2. I fixed it by reseting the firmware and it worked for 2 days now without any issues. After second day cleaning it went back to charge as usual and never turned on. The bricking happened again this time, and I see a similar remote event again. This time am 100% sure there was no action from my side on the App or remote control.
3. What I found so far, after cleaning completes, the device uploads the map (in PNG) and some more data (in binary) to their server (There are very clear logs for this). After this upload, it receives a remote event and stops working.
4. How did I fix the device? I've the backup of all files in the device. Rebooting the device after replacing the files do the trick.
5. Now it reports the device is not on flat surface. Probably a loose connection with sensors which am yet to figure out. This time I suspect the bricking technique has changed, we shall be updating after more research
Note: I am not sure if I can publicly share all techniques used to get access to the device. But it is very straightforward as mentioned in the article and very easy if you have some knowledge on adb (Android Debug Bridge) tools and a USB to micro usb wire.
40 comments
[ 2.6 ms ] story [ 69.5 ms ] threadWhat hostname/s did you block? What filename prevents auto-reboot? What firmware version is your device? Were any credentials necessary to access your robot’s internal syslogs? Was the remote always precisely 8*86400 seconds after you powered on the repaired model?
The repository contains only the barest “how to repurpose this device” details with no supporting material evident for your post’s topic, “what the OEM OS was doing”, which makes the final paragraph either wrong or misleading. Do you have a timeline in mind for when that will be published to GitHub?
The story is marginally interesting, but without the technical details, it’s more “this is completely unsurprising, see also nearly all in-home smart devices” and less “this is novel and interesting”. (I concur with the outrage, but outrage alone does not satisfy.)
I expect there are oodles of sci-fi references to this already, but in particular I remember an audio-log from the game Horizon: Forbidden West, where a hacker is critiquing some shady corporate research he found, implying a project to weaponize domestic robots:
> There's the Moldova brain-hack of course, but also up and coming little devils like the know-it-all MEMEr, or my personal favorite, Sovereign 7482.
> Now that's an apex predator. Assuming control of them Ti-D-O bots and arming 'em with household appliances? Imagine tidying up after that! Gotta admit, it'd be fun to see 'em hunt in the wild.
Sadly, because of (2), most (all?) companies don't bother with local connectivity at all. Much easier to debug one codepath (via remote server) rather than two (remote server and direct connection).
So yeah, if you are worried about device being remote controlled by its manufacturer, don't buy devices which say "Can be remote controlled" right on the box. But of course then you are back to ancient tech, setting physical virtual wall devices or bounding the clean area with overturned chairs.
Why couldn't that just be over Bluetooth?
I recently moved into a new home and decided to take the opportunity to replace everything; it’s been surprising how many things are just coming to life. TVs, vacuums, kitchen appliances, etc. Some of my new TVs won’t even let me use the microphone on the remote until I give it my WiFi password. It’s quite ridiculous the world we’re creating for ourselves.
The real madness is to think that data harvesting is not happening.
I can agree, however, that refusing to work without internet is be too much for the device which can support offline operation.
So, given that, why are you worried about rtty specifically? It's likely a redundant debugging channel in case the main app crashes. It does not add any special functionality that main app does not have.
Now re "disabling the device" - I wonder what command means? Could it be something like "local logs buffer full, pausing operation until upload is done"? Thinking about this more, your blog basically says:
1. vacuum works fine
2. you disable half of the ports on the firewall
3. vacuum stops working
4. you send it for warranty repair
I was very surprised to see that 4 was "send it to warranty repair", instead of "re-open ports on firewall and see if it starts to work now". Did you try this? If not, then it's pretty likely the vacuum was not "bricked" in any sense, but rather was waiting forever for its logs to get uploaded.
In what way is this mundane? The writer purchased a device, and after purchase the device was remotely disabled.
Terrifying - that it happened is alarming but that it is now "mundane" is utterly chilling
https://valetudo.cloud/pages/general/supported-robots.html#i...
- Ten em-dashes
- "not just A, but B"
- incessant bullet points/markdown-style formatting- And an overly dramatic/promotional tone
Obviously the image is AI as well, but /shrug
> 2024/02/29, 14:06:55.852622 [LogKimbo][CAppSystemState] Handle message! cmd_id 501 RS_CTRL_REMOTE_EVENT, len 8 serialno 0
> Someone—or something—had remotely issued a kill command.
Uuuuh are you sure that you're not reading a bit too much into the word "REMOTE" in that logline?
These are some very strong accusations and opinions that to me don't feel like they're being backed up with equally strong evidence. At least not evidence that is part of that post.
What even is a RS_CTRL_REMOTE_EVENT? Did you maybe check with e.g. Ghidra?
1. Has the technical skills to disassemble this device, trace circuit boards, design his own boards and custom software to interface with components to substantially reverse engineer this device.
2. Is totally mystified when his internet connected device stops working after he blocks its communication, and rather than try unblocking it and seeing if it works again, sends it out for repair repeatedly.
Something here doesn't add up. Tastes like bullshit to me.
If last connection time < N days ago and last M tries connecting were unsuccessful, then: brick myself.
Still shitty, no doubt (and very similar to planned obsolescence), but the customer can un-brick by resetting to factory like they did in the service center.
He's insisting that they repeatedly remotely disabled his device in retaliation for blocking their data collection...
...yet they paid for the device to be shipped back and forth and inspected several times under warranty, presumably costing them $$$$?
It makes zero business sense to break your customer's products intentionally, which will lead to 1-star reviews and expensive support.
Plus, I hate to be the "this sounds like it was written by ChatGPT" guy, but this does. People don't write like this:
> Deep within the robot’s startup scripts, I discovered the smoking gun.
> It came back to life instantly. They hadn’t merely incorporated a remote control feature. They had used it to permanently disable my device.
> I may have lost my warranty, but I won back my autonomy.
Also, the idea that someone would waste months (?!) of their life on some broken vacuum cleaner until they "had a complete understanding of how the hardware was designed, down to each chip and wire connector" is just not real life. This is more like someone with a mental illness related to obsession, unless they're starting their own smart vacuum company.
I'm guessing this is 100% fiction from ChatGPT. Complete with the AI-generated image.
1. Like a few comments mentioned here, the remote event happens for multiple reasons. Especially triggered by their app when you start or stop cleaning etc. I missed mentioning it in the article. The one I showed was suspicious as the device got bricked just after that event.
2. I fixed it by reseting the firmware and it worked for 2 days now without any issues. After second day cleaning it went back to charge as usual and never turned on. The bricking happened again this time, and I see a similar remote event again. This time am 100% sure there was no action from my side on the App or remote control.
3. What I found so far, after cleaning completes, the device uploads the map (in PNG) and some more data (in binary) to their server (There are very clear logs for this). After this upload, it receives a remote event and stops working.
4. How did I fix the device? I've the backup of all files in the device. Rebooting the device after replacing the files do the trick.
5. Now it reports the device is not on flat surface. Probably a loose connection with sensors which am yet to figure out. This time I suspect the bricking technique has changed, we shall be updating after more research
Note: I am not sure if I can publicly share all techniques used to get access to the device. But it is very straightforward as mentioned in the article and very easy if you have some knowledge on adb (Android Debug Bridge) tools and a USB to micro usb wire.
A vacuum cleaner that doesn't suck ? Is this from Microsoft ?