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

a smart vacuum being set up with a smart phone
(Image credit: Getty Images)

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.

the PCB of the iLife A11

(Image credit: Harishankar)

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.

a smart vacuum's components and sensors

(Image credit: Harishankar)

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.

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.”

Google Preferred Source

Follow Tom's Hardware on Google News, or add us as a preferred source, to get our latest news, analysis, & reviews in your feeds.

TOPICS
Jowi Morales
Contributing Writer

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.

  • TechieTwo
    Maybe not such a smart purchase... :(
    Reply
  • 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. It's not necessarily about spying or monetizing people's personal data.

    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.
    Reply