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.
Just meaning this as feedback -- I hate these kinds of comments. Unless there is something concretely failing that you can point out, it's not very useful to say "it seems like chatgpt". I hate inaccurate articles as much as the next person, but "seems like chatgpt" is a criticism that can be lobbied at _every article_, and therefore loses value. For instance, I could very well claim that your comment looks like it's written by ChatGPT, and thus should be disregarded. And you could claim the same about this comment.
Fair, yeah. There's a few concrete points: the ai generated header image is a start, but "I had recently bought an iLife A11 smart vacuum—a sleek, affordable, and technologically advanced robot promising effortless cleaning and intelligent navigation." sounds like an advertisement or marketing fluff. Extremely frequent use of em-dashes. Frequent use of "It was X, but also Y" sentences. "In seconds, I had full root access. No hacks, no exploits. Just plug and play." is such hokey writing. That's just the first 3rd.
I agree with the grandparent comment and wanted to say something similar. I’m allergic to AI written drivel and at the first “it wasn’t just” I had to close the article.
Whether or not the author used AI to write it, it’s a valid criticism that it sounds like it, it makes people not want to read it and the author should consider a less offputting style if they want more engagement.
Edit to add, it’s worth flagging AI articles if you don’t want to see them, just commenting on it ends up making for a poor discussion - this thread is littered with talk about how it’s AI written. Better just to vote for it to flagged/dead.
It sounds like the re-flashing was an important step in fixing it, and that just unblocking the IP would not have fixed it if the bricking command had been sent. After all, this was happening sufficiently early in startup that the device appeared to not turn on (rather than boot loop, or turn off after connecting).
I think, charitably, what might have happened here is:
1. Author left out the diagnostic step that restoring the connectivity didn't fix the robot, because it didn't work.
2. Author did the technical analysis mentioned (there is a repository attached. I haven't verified that it actually has the level of technical analysis indicated).
3. Author took some creative liberties (possibly involving some AI-assisted punching-up) when writing the blog post story to make it more compelling in a way that made it feel a bit off and left me and others questioning its veracity.
Yeah I agree this seems most likely. I get the impression the author is not a frequent writer, so "hey LLM turn this draft into a blog post" seems the most likely scenario.
Skimming the post and skipping past the fluff, I thought it was an interesting situation and bit of debugging.
Well, the device _did_ turn on, at least enough that author could adb into, SSH into it, examine files, read the logs.
The post really makes it unclear how permanent the disablement was, or how exactly "one script had been modified to prevent the main application from launching". Would really love to see some details here. Could author undo that change? Did they try to?
Yea, I feel like this is the kind of thing that makes manufacturers resistant to open/hackable devices.
I've done restrictive or invasive things to a variety of devices I own. But if something isn't working the way it should, "reset back to a clean default state and test again" always comes before trying to engage a warranty service process.
The device might not be designed with a publicized tool to restore to a "clean state", and there's also the business signaling factor of "the device stopped working, so I will make sure sure it costs them money to handle a warranty claim".
I had the same thought... if an intentional manually sent kill command was sent to the vacuum to disable it, surely it'd be clear that blocking its access to the internet entirely, not just the logging servers, would prevent this? I don't know why you wouldn't force it to be fully offline in the first place. Possible that by default that also causes it to brick itself.
Also the very frequent use of `—` gives me ChatGPT vibes, but may just be for editing or a personal style. Still enjoyed reading it.
Does it really?
In my opinion, if it stops working and it's under warranty, why not send it out for repair? They did no changes to the actual device, and apparently it was working fine for a few days without network connection, so if it suddenly stops working and it's under warranty that's the manufacturer's/store's problem, not theirs. Trying to fix it/reverse engineer it takes time, and I can see someone with these kinds of skills wanting to spend it on something else than trying to figure out how the manufacturer bricked their vacuum.
In addition, _someone_ is paying for the repairs under warranty, so if enough people were to do it, hopefully it would disincentivize completely blocking devices just because they can't reach a server.
"Something here doesn't add up. Tastes like bullshit to me."
Perhaps so, but it's easily confirmed by another owner of said device going through the same or similar procedure.
If there's any truth to this then everyone should know about it. (Frankly, from what I've seen lately I'd not be a bit surprised that manufacturers would stoop so low).
I recently bought a robot vacuum, installed valetudo, installed tailscale onto the robot itself and now I can control it from anywhere through my personal mesh vpn.
It's pretty amazing. Valetudo is perhaps the most opinionated software I've ever used, which comes with the good and the bad. But overall, it works and it does what it says it will do.
I don't really need to access it remotely, though it has come in handy: when heading out of town I can turn off the scheduled cleans and just run it once on the day I'm returning home. Which is really the only functionality you would need the manufacturer-provided cloud connectivity for.
It's been fun explaining to people that it's "declouded", but I can access it from anywhere. Melts non-tech peoples' brains a little bit.
To expand on laulis' comment: Valetudo isn't a full custom-firmware, it's a mod for the existing firmware. You copy on the Valetudo daemon binary, fuss with the init scripts to start the daemon, and fuss with the DNS and such to point some domains at 127.0.0.1 to talk to that daemon instead of the normal servers (well, actually you probably download a firmware image from dustbin that already has those modifications applied).
This is a distinction that is worth making because the robot is still running and relying on all of the on-robot proprietary code; it's just the in-cloud code that has been replaced.
it's a bit of a blurry distinction because, what is firmware if not the software that runs on an embedded device? a more accurate description would be that the high-level operating system (HLOS) has been modified to include the installation of a drop-in-replacement for the cloud API. the client side, and whatever hardware abstraction layer lives below it, is untouched. so the client thinks it's talking to the server but it's actually talking to a local open-source server.
I think it's also not quite correct to say the low-level firmware is unmodified, because with vale tudo you rely on the project author to provide a minimal rootkit that gets customized on a per-serial-number basis for the initial rooting.
from a high-level though, it delivers what it says on the tin - cloud features without any requirement of packets leaving your network or even the robot itself.
Why on earth would you do it?! It was literally the comment I visit HN for - a solution for the problem we basically all have, already tested by someone, starting a thread with people's experience of it.
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.
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.
Lots of movie plots with hacking critical infrastructure. Hackers controlled the ballast of a ship. Some other movie(s??) have taken over the flow of oil/gas at refineries. The entire US electrical grid is nothing but a soft target. A Ukranian style sneak drone attack on enough substations would knock the entire country into a blackout without ever touching the generation plants.
Former Illinoisan, and happy that Sven is national on the MeTV network.
I've heard he's now in commercials with Howard Ankin, which seems strange since he gets thrown out of the back of the hearse in the middle of each show!
Make no mistake, I am very excited for this weekend's broadcast.
When I am away from home for extended periods, I like to watch Sven to get a taste of home. It's especially nice for after I return from travel and want to unwind.
PSA: There's full broadcasts of Svengoolie up on Archive.org! Some uploaded by the man himself! ETA: A lot more than I realized; the last ~year some fellow has been recording and uploading them regularly.
> 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.
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.
Phones are extremely hard to hack and getting harder. The phone hacking companies only bother targeting an extremely limited set of people because once it becomes widespread, the whole exploit chain gets patched and you have to spend millions of dollars developing a new one.
With ARM Memory Tagging Extension becoming common on phones now it's getting borderline impossible to hack them.
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.
Oh, your XOURR smart vacuum got remotely disabled? Unfortunately the XOURR company has ceased operations so no refund is possible, but luckily there's a sale on IWEEET robot vacuums now, and I hear they're very reliable!
Most "smart" devices simply don't function without connectivity back to the manufacturer's cloud, and this is basically just the same thing with extra steps.
It clearly doesn't need the cloud, it intentionally bricks itself if it can't exfiltrate it's logs. It's not like it's sending data necessary for its immediate operation.
Sure it does need the cloud - you might have notice that the kill command was delivered _over cloud connection_. And author carefully blocked not entire connectivity, but only the part that they considered "logs". They wanted to keep cloud control, just not the whole thing.
Given the complete lack of relevant technical details, it could be something as simple as "internal log storage full, refusing to start up until logs uploaded". We'd never know.
Yes BUT "I paid it back, so nothing bad ever happened" is not sufficient.
Someone (or a company) does something bad - yes, pay it back, but there needs to be some punishment for doing evil. Pay back X 100. Or pay purchaser + pay fine.
Just paying back the cost (or fraud) is saying "it's fine if you don't get caught, and if you do get caught, there's no real cost to you."
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.
I'm amazed this is so common. I don't think any of my household appliances require wifi access. Our PC, laptops, phones, tablets and printer do, of course. I do occasionally check which devices are connected to my wifi, and try to keep track of what's what, but there are always a few mysterious devices I don't recognise, so I block those just to see what stops working.
> but I’m finding it harder as more devices share my WiFi credentials with each other
Sorry, what? That's not a documented thing.
There are limited ways in which you can share credentials (like between iPhones), and there have been some weird things in the past related to sharing with friends' accounts (the controversial Windows 10 Wi-Fi Sense in 2015), but your consumer devices aren't just sharing Wi-Fi credentials with each other. There isn't even a protocol for that kind of automatic discovery.
As for the microphone on the remote, you need to enable Wi-Fi on the TV so it can perform voice recognition on remote servers. The TV doesn't have the chips/software to do voice recognition. So that makes complete sense.
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.
This is when you only want to clean only left half of the room, for example. In the old robotics vacuums, your choices were either enough physical "virtual wall" units (those little stubby boxes you place on the floor) or physically fencing it, with overturned chairs or boxes or something.
With the smart vacuums, you get the nifty map and you can draw the lines/boxes around the area you want cleaned. Very convenient, but naturally requires some sort of device with a screen (to show map) and position input (to draw the boundaries), like a phone.
They could, but it'd still be two codepaths to debug and test - via central server and via bluetooth. So the difference would be even greater, with the benefits unclear - the amount of people who genuinely care about fully offline vacuum is pretty low.
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.
> 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?
Having thrown one version of everest-server of _a_ CRL-200S firmware (which might not be the one OP's firmware is running) into Ghidra and having found the string, this "REMOTE CONTROL" to me really does not look like it's executing remote commands.
I mean it does, but not like shell commands but probably IR remote?
The CRL-200S can be controlled via an IR remote, so it is possible that it saw something.
The sun, perhaps?
That vaccum comes with cell phone app. It'd totally be reasonable to have "remote control event" for things like "start vacuuming" button pressed on an app.
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.
I had a similar problem with Twinkly Xmas tree lights. It was even more frustrating than this because instead of just having me send the lights back, they just kept me trying all these different power plugs/checking with a voltmeter, etc. I should have asked myself “why in the f$&@ am I doing this” when clearly the lights were just dead. After the last correspondence I was busy and waited a month to respond and when I wrote them back they basically said it’s out of warranty, good luck. I pushed back and they couldn’t have cared less. All you can do is tell your friends and write a bad review. Good luck making it slip past all the positive fake reviews!
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?
1. I didn't see any obvious AI ticks in the article.
2. If you want to claim that some slop is AI then please bring reasons. Even if they are the stuff of "there is too many em-dashes" then fine at least you brought something.
Top image is definitely AI, watermarked though so they're not hiding that.
I do see a lot of em dashes throughout the opening, but at least one of them seems proper. "Inside, the iLife A11 wasn’t just a vacuum cleaner; it was a small computer on wheels." is also kind of an AI tick phrasing. And there's pretty heavy use of bullet points for listing things beyond what I would normally expect from a tech blog.
(Also a lot of random lines are in block quotes for emphasis, but that could be a writing quirk. Kinda weird to read though)
If you go through there's at least enough of a smell I suspect someone had an AI polish or edit their actual blog post here?
But is it malicious or innocuous? I could see just the assumption being made that if it hasn’t phoned home it must be malfunctioning and ask risk mitigation then force it to brick. It’s not super unreasonable considering very few people will ever block the comms.
Punishment due to not receiving telemetry? Please, that's fantasy land stuff.
It might be a malfunction caused by his blocking, but the idea that someone in HQ was like "guys, we've got someone blocking telemetry!" "disable his vacuum, the bastard".
Or in some design meeting they were like "what do we do if a handful of privacy nerds block our telemetry?" "well.. I guess we should automatically disable their vacuums in a weird way so they repeatedly send them in for repair and it costs us loads of money".
>"The manufacturer had the power to remotely disable devices and used it against me for blocking their data collection."
He posits that some low-level support person triggered a remote "kill switch" because he dared to block some telemetry servers which is, frankly, ridiculous.
A much simpler explanation is that the device disabled itself after being unable to contact the cloud servers for X time (probably a bug), rather than an employee sending a kill command over the now-disabled cloud connection.
The article is obviously AI-written, and also I very much doubt that these conclusions were reached without a sycophantic AI in their ear.
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.)
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.
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.
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.
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.
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.
100% agree. The whole is written in such a gushingly dramatic tone. No real technical details, just lots of alluded information. I don't believe a word of it.
- 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
It was until AI started doing it everywhere. When I took technical writing course in college, many years ago, breaking up paragraphs with bullet-point lists was one of the core techniques taught for writing clear, effective documentation.
I don’t think there’s any single way to be sure, but it sure reads like ChatGPT to me. Which I’m not sure is such a bad thing—I presume the author used an AI to help them write the story, but the story is real. Or maybe they edited it themselves to make it sound more generic. Whatever the reason, the style takes away from my reading experience. It’s a blog post, I expect some personality!
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.)
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.
Allegedly. The article while extremely heavy on the drama provides no real details at all apart from one log message. And they're totally extrapolating out what the start of the log message might mean.
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.
Whether or not the author used AI to write it, it’s a valid criticism that it sounds like it, it makes people not want to read it and the author should consider a less offputting style if they want more engagement.
Edit to add, it’s worth flagging AI articles if you don’t want to see them, just commenting on it ends up making for a poor discussion - this thread is littered with talk about how it’s AI written. Better just to vote for it to flagged/dead.
I think, charitably, what might have happened here is:
1. Author left out the diagnostic step that restoring the connectivity didn't fix the robot, because it didn't work.
2. Author did the technical analysis mentioned (there is a repository attached. I haven't verified that it actually has the level of technical analysis indicated).
3. Author took some creative liberties (possibly involving some AI-assisted punching-up) when writing the blog post story to make it more compelling in a way that made it feel a bit off and left me and others questioning its veracity.
Skimming the post and skipping past the fluff, I thought it was an interesting situation and bit of debugging.
The post really makes it unclear how permanent the disablement was, or how exactly "one script had been modified to prevent the main application from launching". Would really love to see some details here. Could author undo that change? Did they try to?
It sure sounds like they were aware of the relation, just not how or why one thing led to the other.
I've done restrictive or invasive things to a variety of devices I own. But if something isn't working the way it should, "reset back to a clean default state and test again" always comes before trying to engage a warranty service process.
The device might not be designed with a publicized tool to restore to a "clean state", and there's also the business signaling factor of "the device stopped working, so I will make sure sure it costs them money to handle a warranty claim".
Also the very frequent use of `—` gives me ChatGPT vibes, but may just be for editing or a personal style. Still enjoyed reading it.
Were they even able to see what was inside the traffic they blocked? Or are they just assuming it’s telemetry?
Does it really? In my opinion, if it stops working and it's under warranty, why not send it out for repair? They did no changes to the actual device, and apparently it was working fine for a few days without network connection, so if it suddenly stops working and it's under warranty that's the manufacturer's/store's problem, not theirs. Trying to fix it/reverse engineer it takes time, and I can see someone with these kinds of skills wanting to spend it on something else than trying to figure out how the manufacturer bricked their vacuum.
In addition, _someone_ is paying for the repairs under warranty, so if enough people were to do it, hopefully it would disincentivize completely blocking devices just because they can't reach a server.
Perhaps so, but it's easily confirmed by another owner of said device going through the same or similar procedure.
If there's any truth to this then everyone should know about it. (Frankly, from what I've seen lately I'd not be a bit surprised that manufacturers would stoop so low).
https://valetudo.cloud/pages/general/supported-robots.html#i...
It's pretty amazing. Valetudo is perhaps the most opinionated software I've ever used, which comes with the good and the bad. But overall, it works and it does what it says it will do.
I don't really need to access it remotely, though it has come in handy: when heading out of town I can turn off the scheduled cleans and just run it once on the day I'm returning home. Which is really the only functionality you would need the manufacturer-provided cloud connectivity for.
It's been fun explaining to people that it's "declouded", but I can access it from anywhere. Melts non-tech peoples' brains a little bit.
> Cloud replacement for vacuum robots enabling local-only operation
This is a distinction that is worth making because the robot is still running and relying on all of the on-robot proprietary code; it's just the in-cloud code that has been replaced.
I think it's also not quite correct to say the low-level firmware is unmodified, because with vale tudo you rely on the project author to provide a minimal rootkit that gets customized on a per-serial-number basis for the initial rooting.
from a high-level though, it delivers what it says on the tin - cloud features without any requirement of packets leaving your network or even the robot itself.
here's a talk from the author discussing his research https://www.youtube.com/watch?v=AfMfYOUYZvc
Middle would imply there being another end still.
Why on earth would you do it?! It was literally the comment I visit HN for - a solution for the problem we basically all have, already tested by someone, starting a thread with people's experience of it.
Unless it's Saturday Night and you're drunk. Then go for Demon Seed.
Don't give Svengoolie any ideas!
Alas, lately it's mostly been 60's and earlier, when at one point it was a lot of 70's-90's stuff.
Former Illinoisan, and happy that Sven is national on the MeTV network.
I've heard he's now in commercials with Howard Ankin, which seems strange since he gets thrown out of the back of the hearse in the middle of each show!
Sven is one of the few things I miss about living in Chicago.
When I am away from home for extended periods, I like to watch Sven to get a taste of home. It's especially nice for after I return from travel and want to unwind.
PSA: There's full broadcasts of Svengoolie up on Archive.org! Some uploaded by the man himself! ETA: A lot more than I realized; the last ~year some fellow has been recording and uploading them regularly.
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.
With ARM Memory Tagging Extension becoming common on phones now it's getting borderline impossible to hack them.
Given the complete lack of relevant technical details, it could be something as simple as "internal log storage full, refusing to start up until logs uploaded". We'd never know.
Someone (or a company) does something bad - yes, pay it back, but there needs to be some punishment for doing evil. Pay back X 100. Or pay purchaser + pay fine.
Just paying back the cost (or fraud) is saying "it's fine if you don't get caught, and if you do get caught, there's no real cost to you."
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.
Do you have any specific examples of a product doing this?
Sorry, what? That's not a documented thing.
There are limited ways in which you can share credentials (like between iPhones), and there have been some weird things in the past related to sharing with friends' accounts (the controversial Windows 10 Wi-Fi Sense in 2015), but your consumer devices aren't just sharing Wi-Fi credentials with each other. There isn't even a protocol for that kind of automatic discovery.
As for the microphone on the remote, you need to enable Wi-Fi on the TV so it can perform voice recognition on remote servers. The TV doesn't have the chips/software to do voice recognition. So that makes complete sense.
What brand?
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.
This is when you only want to clean only left half of the room, for example. In the old robotics vacuums, your choices were either enough physical "virtual wall" units (those little stubby boxes you place on the floor) or physically fencing it, with overturned chairs or boxes or something.
With the smart vacuums, you get the nifty map and you can draw the lines/boxes around the area you want cleaned. Very convenient, but naturally requires some sort of device with a screen (to show map) and position input (to draw the boundaries), like a phone.
Why couldn't that just be over Bluetooth?
The real madness is to think that data harvesting is not happening.
> 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?
I mean it does, but not like shell commands but probably IR remote? The CRL-200S can be controlled via an IR remote, so it is possible that it saw something. The sun, perhaps?
Feel free to prove me wrong on this of course.
1. I didn't see any obvious AI ticks in the article.
2. If you want to claim that some slop is AI then please bring reasons. Even if they are the stuff of "there is too many em-dashes" then fine at least you brought something.
I do see a lot of em dashes throughout the opening, but at least one of them seems proper. "Inside, the iLife A11 wasn’t just a vacuum cleaner; it was a small computer on wheels." is also kind of an AI tick phrasing. And there's pretty heavy use of bullet points for listing things beyond what I would normally expect from a tech blog.
(Also a lot of random lines are in block quotes for emphasis, but that could be a writing quirk. Kinda weird to read though)
If you go through there's at least enough of a smell I suspect someone had an AI polish or edit their actual blog post here?
Maybe he's using a Mac?
Those of us who have been professional writers are quite comfortable with pressing ⇧⌥-
"2024/02/29, 14:06:55.852622 [LogKimbo][CAppSystemState] Handle message! cmd_id 501 RS_CTRL_REMOTE_EVENT, len 8 serialno 0"
Note something being named RS_CTRL_REMOTE_EVENT
I'd have been tempted to explore this further - does sending fake or repeated telemetry satisfy it?
It might be a malfunction caused by his blocking, but the idea that someone in HQ was like "guys, we've got someone blocking telemetry!" "disable his vacuum, the bastard".
Or in some design meeting they were like "what do we do if a handful of privacy nerds block our telemetry?" "well.. I guess we should automatically disable their vacuums in a weird way so they repeatedly send them in for repair and it costs us loads of money".
Come on, at least try to live in the real world.
He posits that some low-level support person triggered a remote "kill switch" because he dared to block some telemetry servers which is, frankly, ridiculous.
The article is obviously AI-written, and also I very much doubt that these conclusions were reached without a sycophantic AI in their ear.
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.
- 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
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.)
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