When you buy through links on our articles, Future and its syndication partners may earn a commission.
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 keep…
When you buy through links on our articles, Future and its syndication partners may earn a commission.
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.
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.
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.
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.”
FollowTom’s Hardware on Google News, oradd us as a preferred source, to get our latest news, analysis, & reviews in your feeds.
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.
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.
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.”
FollowTom’s Hardware on Google News, oradd us as a preferred source, to get our latest news, analysis, & reviews in your feeds.