Manufacturer issues remote kill command to disable smart vacuum after engineer blocks it from collecting data — user revives it with custom hardware and Python scripts to run offline
The smart vacuum cleaner was remotely bricked for not collecting data.
An engineer got curious about how his iLife A11 smart vacuum worked and monitored the network traffic coming from the device. That’s when he noticed it was constantly sending logs and telemetry data to the manufacturer — something he hadn't consented to. The user, Harishankar, decided to block the telemetry servers' IP addresses on his network, while keeping the firmware and OTA servers open. While his smart gadget worked for a while, it just refused to turn on soon after. After a lengthy investigation, he discovered that a remote kill command had been issued to his device.
He sent it to the service center multiple times, wherein the technicians would turn it on and see nothing wrong with the vacuum. When they returned it to him, it would work for a few days and then fail to boot again. After several rounds of back-and-forth, the service center probably got tired and just stopped accepting it, saying it was out of warranty. Because of this, he decided to disassemble the thing to determine what killed it and to see if he could get it working again.
Since the A11 was a smart device, it had an AllWinner A33 SoC with a TinaLinux operating system, plus a GD32F103 microcontroller to manage its plethora of sensors, including Lidar, gyroscopes, and encoders. He created PCB connectors and wrote Python scripts to control them with a computer, presumably to test each piece individually and identify what went wrong. From there, he built a Raspberry Pi joystick to manually drive the vacuum, proving that there was nothing wrong with the hardware.
From this, he looked at its software and operating system, and that’s where he discovered the dark truth: his smart vacuum was a security nightmare and a black hole for his personal data. First of all, it's Android Debug Bridge, which gives him full root access to the vacuum, wasn't protected by any kind of password or encryption. The manufacturer added a makeshift security protocol by omitting a crucial file, which caused it to disconnect soon after booting, but Harishankar easily bypassed it. He then discovered that it used Google Cartographer to build a live 3D map of his home.
This isn’t unusual, by far. After all, it’s a smart vacuum, and it needs that data to navigate around his home. However, the concerning thing is that it was sending off all this data to the manufacturer’s server. It makes sense for the device to send this data to the manufacturer, as its onboard SoC is nowhere near powerful enough to process all that data. However, it seems that iLife did not clear this with its customers. Furthermore, the engineer made one disturbing discovery — deep in the logs of his non-functioning smart vacuum, he found a command with a timestamp that matched exactly the time the gadget stopped working. This was clearly a kill command, and after he reversed it and rebooted the appliance, it roared back to life.
So, why did the A11 work at the service center but refuse to run in his home? The technicians would reset the firmware on the smart vacuum, thus removing the kill code, and then connect it to an open network, making it run normally. But once it connected again to the network that had its telemetry servers blocked, it was bricked remotely because it couldn’t communicate with the manufacturer’s servers. Since he blocked the appliance’s data collection capabilities, its maker decided to just kill it altogether. "Someone—or something—had remotely issued a kill command,” says Harishankar. “Whether it was intentional punishment or automated enforcement of 'compliance,' the result was the same: a consumer device had turned on its owner.”
Unfortunately, many other smart vacuum brands use similar hardware, so it’s not far-fetched to think that they have the same setup. This is likely especially true for cheaper devices that have less capable hardware and aren’t capable of edge computing, meaning they’ll have to send the data to some faraway server for processing. But because your information is being offboarded to another device outside of your control, you really have no idea what’s happening to it, giving the manufacturer free rein to use it as it pleases.
Get Tom's Hardware's best news and in-depth reviews, straight to your inbox.
In the end, the owner was able to run his vacuum fully locally without manufacturer control after all the tweaks he made. This helped him retake control of his data and make use of his $300 software-bricked smart device on his own terms. As for the rest of us who don’t have the technical knowledge and time to follow his accomplishments, his advice is to “Never use your primary WiFi network for IoT devices” and to “Treat them as strangers in your home.”
Follow Tom's Hardware on Google News, or add us as a preferred source, to get our latest news, analysis, & reviews in your feeds.

Jowi Morales is a tech enthusiast with years of experience working in the industry. He’s been writing with several tech publications since 2021, where he’s been interested in tech hardware and consumer electronics.
-
bit_user Not to side entirely with the manufacturer on this, but I can imagine reasons they might not want their robots operating without telemetry. For instance, being able to monitor that they're operating within safe parameters - especially where they might face some liability for damages or injuries caused by the robot. It's not necessarily about spying or monetizing people's personal data.Reply
Given that there's nothing time-sensitive about this story, Toms really should've reached out to the manufacturer, for comment. Maybe they would've given a typical non-answer, but you don't know if you don't ask. Also, it's a way you could've added value to the story, over and above merely summarizing someone's blog. -
wakuwaku nah home IOT devices are just way too finicky with wireless connections. Either you trust them, or you don't use them. There is no such thing as a "secure" and "private" middle ground where you separate them off with a vlan, only to discover they become really unreliable and being slow to respond or not respond at all. If an IOT device is gonna be only half as useful at the most on vlan, i rather not have any IOT devices in my home at all. Waste of money and time just to troubleshoot and coerce them to work on your vlan. These security people sure have plenty of time to do all this tinkering...must be wonderful not having a real job.Reply -
hotaru251 Reply
#1 based on claims the customers aren't even aware its sending data let alone tracking it.bit_user said:For instance, being able to monitor that they're operating within safe parameters - especially where they might face some liability for damages or injuries caused by the robot.
#2 even IF they knew you can have it monitor that stuff w/o need to send it to a server. (small bit of on board memory to handle periodic data that overwrites itself on next check.
bonus #3: can avoid any liability by having it in the ToU.
when its not done for personal data it is done for profit in other ways such as data to improve the thing in future (which IS profit as saves them having to do the situations themself)bit_user said:It's not necessarily about spying or monetizing people's personal data.
point is it was manufacturers who didn't inform users & actively tried to brick the device multiple times. -
bit_user Reply
It's an IoT device that requires network connectivity. It's obviously sending and receiving something.hotaru251 said:#1 based on claims the customers aren't even aware its sending data let alone tracking it.
You assume they know specifically what to look for. As a product ages, the manufacturer might start to see patterns in the types of failures which occurs and be able to fine-tune their failure model to predict these problems and disable the robot, before one of them occurs.hotaru251 said:#2 even IF they knew you can have it monitor that stuff w/o need to send it to a server. (small bit of on board memory to handle periodic data that overwrites itself on next check.
In many jurisdictions, laws would prevent enforcement of such terms. Otherwise, every company would just do that and product liability would no longer be a thing.hotaru251 said:bonus #3: can avoid any liability by having it in the ToU.
They obviously should've had some way to flag the problem to the user. At the very least, the service center should've been informed to look for that particular issue and bring it to the owner's attention. On the flip side, if it's sufficiently rare, maybe they just decided not to handle it and let the user assume it failed due to some defect or malfunction and get a different vacuum.hotaru251 said:point is it was manufacturers who didn't inform users & actively tried to brick the device multiple times.
I do wonder whether it was a contract repair center, rather than the actual manufacturer who was servicing it. These days, a lot of brands don't have their own repair network, but instead use contract repair services. That might explain why the repair techs weren't more knowledgeable or helpful. -
bit_user Reply
Oh, there are even smaller, cheaper, and simpler IoT devices that might do things you don't like, such as LED light bulbs!Devoteicon said:All this over a vacuum cleaner. :ROFLMAO: What a time to be alive. -
ottonis Such spying companies need to banned for life. There is zero reason to send data to wherever all over planet earth in order to cartograph the home. This is a task that even a C64 from 40 years ago could manage - locally, of course.Reply -
ottonis Reply
Yeah, but that's entirely irrelevant for the topic at hand.bit_user said:It's an IoT device that requires network connectivity. It's obviously sending and receiving something.
The device didn't stop working because it needed the telemetry but because a sinister dude from wherever in the world killed the device remotely. -
palladin9479 Replyottonis said:Yeah, but that's entirely irrelevant for the topic at hand.
The device didn't stop working because it needed the telemetry but because a sinister dude from wherever in the world killed the device remotely.
Service side is likely programmed to kill any unit not reporting in all that data for resale. These "smart" IoT devices are just data collectors for the companies real business, selling data to brokers.