Kickstarter is full of projects like this where every possible shortcut is taken to get to market. I’ve had some good success with a few Kickstarter projects but I’ve been very selective about which projects I support. More often than not I can identify when a team is in over their heads or think they’re just going to figure out the details later, after the money arrives.
For a period of time it was popular for the industrial designers I knew to try to launch their own Kickstarters. Their belief was that engineering was a commodity that they could hire out to the lowest bidder after they got the money. The product design and marketing (their specialty) was the real value. All of their projects either failed or cost them more money than they brought in because engineering was harder than they thought.
I think we’re in for another round of this now that LLMs give the impression that the software and firmware parts are basically free. All of those project ideas people had previously that were shelved because software is hard are getting another look from people who think they’re just going to prompt Claude until the product looks like it works.
The people doing these kickstarters are outsourcing the work because they can’t do it themselves. If they use an LLM, they don’t know what to look for or even ask for, which is how they get these problems where the production backend uses shared credentials and has no access control.
The LLM got it to “working” state, but the people operating it didn’t understand what it was doing. They just prompt until it looks like it works and then ship it.
> they'd rather vibe code themselves than trust an unproven engineering firm
You could cut the statement short here, and it would still be a reasonable position to take these days.
LLMs are still complex, sharp tools - despite their simple appearance and proteststions of both biggest fans and haters alike, the dominating factor for effectiveness of an LLM tool on a problem is still whether or not you're holding it wrong.
LLMs definitely write more robust code than most. They don't take shortcuts or resort to ugly hacks. They have no problem writing tedious guards against edge cases that humans brush off. They also keep comments up to date and obsess over tests.
I had 5.3-Codex take two tries to satisfy a linter on Typescript type definitions.
It gave up, removed the code it had written directly accessing the correct property, and replaced it with a new function that did a BFS to walk through every single field in the API response object while applying a regex "looksLikeHttpsUrl" and hoping the first valid URL that had https:// would be the correct key to use.
On the contrary, the shift from pretraining driving most gains to RL driving most gains is pressuring these models resort to new hacks and shortcuts that are increasingly novel and disturbing!
The discourse around LLMs has created this notion that humans are not lazy and write perfect code. They get compared to an ideal programmer instead of real devs.
LLM's at best asymptotically approach a human doing the same task. They are trained on the best and the worst. Nothing they output deserves faith other than what can be proven beyond a shadow of a doubt with your own eyes and tooling. I'll say the same thing to anyone vibe coding that I'd say to programmatically illiterate. Trust this only insofar as you can prove it works, and you can stay ahead of the machine. Dabble if you want, but to use something safely enough to rely on, you need to be 10% smarter than it is.
How about complaining that brain waves get sent to a server?
I'm a neuroscientist, so I'm not going to say that the EEG data is mind reading or anything, but as a precedent, non privacy of brain data is very bad.
How useful could something like this be for research? I'm not a neuroscientist so I have no clue, but it seems like the only justification I can think of..
The general idea of an EEG system that posts data to a network?
Very, but there are already tons of them at lots of different price, quality, openness levels. A lot of manufacturers have their own protocols; there are also quasi/standards like Lab Streaming Layer for connecting to a hodgepodge of devices.
This particular data?
Probably not so useful. While it’s easy to get something out of an EEG set, it takes some work to get good quality data that’s not riddled with noise (mains hum, muscle artifacts, blinks, etc). Plus, brain waves on their own aren’t particularly interesting—-it’s seeing how they change in response to some external or internal event that tells us about the brain.
Not a neuroscientist either but I would imagine that raw data without personal information would not be useful for much. I can imagine that it would be quite valuable if accompanied with personal data plus user reports about how they slept each night, what they dreamed about if anything, whether it was positive dreams or nightmares etc. And I think quite a few people wouldn’t mind sharing all of that in the name of science, but in this case they don’t seem to have even tried to ask.
Millions of people voluntarily use Gmail which gives a lot more useful data than EEG output to DHS et al without a warrant under FAA702. What makes you think people who “have nothing to hide” would care about publishing their EEG data?
Ok, obviously unethical to do it, but this sounds like you've got the power to create some sci-fi shared dreaming device, where you can read people's brainwaves and send signals to other people's masks based on those signals. Or send signals to everyone at the same time and suddenly people all across the world experience some change in their dream simultaneously.
Like, don't actually do it, but I feel like there's inspiration for a sci-fi novel or short story there.
I have deployed open MQTT to the world for quick prototypes on non personal (and healthcare) data. Once my cloud provider told me to stop because they didn’t like it, that could be used for relay DDOS attacks.
I would not trust the sleep mask company even if they somehow manage to have some authentication and authorisation on their MQTT.
I would love to see the prompt history. Always curious how much human intervention/guidance is necessary for this type of work because when I read the article I come away thinking I prompt Claude and it comes out with all these results. For example, "So Claude went after the app instead. Grabbed the Android APK, decompiled it with jadx." All by itself or the author had to suggest and fiddle with bits?
The shared hardcoded credentials pattern isn't just an IoT problem. I work in AWS security and see the same thing constantly. Teams hardcode a single set of AWS access keys into their application, share them across every environment, and hope nobody runs strings on the binary. Same logic, same laziness, same outcome.
The difference is when it's a sleep mask, someone reads your brainwaves. When it's a cloud credential, someone reads your customer database. Per-device or per-environment credential provisioning isn't even hard anymore. AWS has IAM roles, IoT has device certificates, MQTT has client certs and topic ACLs. The tooling exists. Companies skip it because key management adds a step to the assembly line and nobody budgets time for security architecture on v1.
> nobody budgets time for security architecture on v1
It’s quite literally why the internet is so insecure, because at many points all along the way, “hey, should we design and architect for security?” is/was met with “no, we have people to impress and careers to advance with parlor tricks to secure more funding; besides, security is hard and we don’t actually know what we are doing, so tow the line or you’ll be removed.”
The narrator in the article acts as a third person observer and identifies "Claude" as the active hacker. So assuming the (unidentified) company that sells/manages the product wants to prosecute a CFAA violation, who do they go after? Was Claude the one responsible for all of the hacking?
This feels like a reason to buy the device to me? I would want to block all of the data going to the cloud and would only want operations happening locally. But the MQTT broadcast then allows me to create a local only integration in Home Assistant with all of the data.
What's the real risk profile? Robbers can see you are asleep instead of waiting until you aren't home?
I have not implemented MQTT automations myself, but it's there a way to encrypt them? That could be a nice to have
Sounds like you cannot control which MQTT endpoint it is headed to? It just goes to the server of the device. Assuming you could modify the firmware, you could program it to send to a local MQTT.
Author doesn’t spell out why they are not naming them, but my guess is they are trying to not promote the product to malicious actors who would be interested in the sleep data of others.
I guess that’s not a huge problem, though, since all users are presumably at least anonymous.
This guy bought an internet connected sleep mask so it's not surprising that it was collecting all kinds of data, or that it was doing it insecurely (everyone should expect IoT anything to be a security nightmare) so to me the surprising thing about this is that the company actually bothered to worry about saving bandwidth/power and went through the trouble of using MQTT. Probably not the best choice, and they didn't bother to do it securely, but I'm genuinely impressed that they even tried to be efficient while sucking up people's personal data.
"The ZZZ mask is an intelligent sleep mask — it allows you to sleep less while sleeping deeper. That’s the premise — but really it is a paradigm breaking computer that allows full automation and control over the sleep process, including access to dreamtime."
or if this is another scifi variation of the same theme, with some dev like embellishments.
the shared MQTT credentials pattern is unfortunately super common in budget IoT. seen the exact same thing in smart plugs and air quality sensors. the frustrating part is per-device auth is not even hard to set up, mosquitto supports client certs and topic ACLs with minimal config. manufacturers skip it because per-device key provisioning adds a step to the assembly line and nobody wants to think about key management. so they hardcode one set of creds and hope nobody runs strings on the binary.
This smells like bullshit to me, although I am admittedly not experienced with Claude.
I find it difficult to believe that a sleep mask exists with the features listed: "EEG brain monitoring, electrical muscle stimulation around the eyes, vibration, heating, audio." while also being something you can strap to your face and comfortably sleep in, with battery capacity sufficient for several hours of sleep.
I also wonder how Claude probed bluetooth. Does Claude have access to bluetooth interface? Why? Perhaps it wrote a secondary program then ran that, but the article describes it as Claude probing directly.
I'm also skeptical of Claude's ability to make accurate reverse-engineered bluetooth protocol. This is at least a little more of an LLM-appropriate task, but I suspect that there was a lot of chaff also produced that the article writer separated from the wheat.
If any of this happened at all. No hardware mentioned, no company, no actual protocol description published, no library provided.
It makes a nice vague futuristic cyperpunk story, but there's no meat on those bones.
A lot of BLE peripherals are very easy to probe. And there are libraries available for most popular languages that allow you to connect to a peripheral and poke at any exposed internals with little effort.
As for the reverse engineering, the author claims that all it took was dumping the strings from the Dart binary to see what was being sent to the bluetooth device. It's plausible, and I would give them the benefit of the doubt here.
Found that in seconds. EEG, electrical stimulation, heat, audio, etc. Claims a 20 hour battery.
As to the Claude interactions, like others I am suspicious and it seems overly idealized and simplified. Claude can't search for BT devices, but you could hook it up with an MCP that does that. You can hook it up with a decompiler MCP. And on and on. But it's more involved than this story details.
That appears to be more than a centimeter thick, and not particularly flexible. It's more like ski goggles than a sleep mask.
So yeah, a product exists that claims to be a sleep mask with these features. Maybe someone could even sleep while wearing that thing, as long as they sleep on their back and don't move around too much. I remain skeptical that it actually does the things it claims and has the battery life it claims. This is kickstarter after all. Regardless, this would qualify as the device in question for the article. Or at least inspiration for it.
Without evidence such as wireshark logs, programs, protocol documentation, I'm not convinced that any of this actually _happened_.
Claude, or any good agent, doesn't need MCP to do things. As long as it has access to a shell it can craft any command that it needs to fulfill its prompt.
There are no shell commands to do what is described. I could get Claude to interact with BLE devices, but it did it by writing and running various helper applications, for instance using the Bleak library. So I guess not an MCP per se.
I was originally going to ask something similar, but from a different angle.
These blog posts now making the rounds on HN are the usual reverse engineering stories, but made a lot more compelling simply because they involve using AI.
Never mind that the AI part isn't doing any heavy lifting and probably just as tedious as not using AI in the first place. I am confused why the author mentions it so prominently. Past authors would not have been so dramatic and just waved their hands that they had some trial and error before finding out how the app is built. The focus would have been on the lack of auth and the funny stuff they did before reporting it to the devs.
As an aside, it seems cool that the bar to reverse engineering has lowered from all the LLMs. Maybe we'll get to take full control of many of these "smart" devices that require proprietary/spyware apps and use them in a fully private way. There's no excuse that any such apps solely to interact with devices locally need to connect to the internet, like dishwasher.
It's disappointing to see. It doesn't take much work to configure a MQTT server to require client certificates for all connections. It does require an extra step in provisioning to give each device a client certificate. But for a commercial product, it's inexcusably negligent.
Then there's hardening your peripheral and central device/app against the kinds of spoofing attacks that are described in this blog post.
If your peripheral and central device can securely [0] store key material, then (in addition to the standard security features that come with the Bluetooth protocol) one may implement mutual authentication between the central and peripheral devices and, optionally, encryption of the data that is transmitted across that connection.
Then, as long as your peripheral and central devices are programmed to only ever respond when presented with signatures that can be verified by a trusted public key, the spoofing and probing demonstrated here simply won't work (unless somebody reverse engineers the app running on the central device to change its behaviour after the signature verification has been performed).
To protect against that, you'd have to introduce server-mediated authorisation. On Android, that would require things like the Play Integrity API and app signatures. Then, if the server verifies that the instance of the app running on the central device is unmodified, it can issue a token that the central device can send to the peripheral for verification in addition to the signatures from the previous step.
Alternatively, you could also have the server generate the actual command frames that the central device sends to the peripheral. The server would provide the raw command frame and the command frame signed with its own key, which can be verified by the peripheral.
I guess I got a bit carried away here. Certainly, not every peripheral needs that level of security. But, into which category this device falls, I'm not sure. On the one hand, it's not a security device, like an electronic door lock. And on the other hand, it's a very personal peripheral with some unusual capabilities like the electrical muscle stimulation gizmo and the room occupancy sensor.
[0]: Like with the Android KeyStore and whichever HSMs are used in microcontrollers, so that keys can't be extracted by just dumping strings from a binary.
Interesting project. Here's a thought which I've always had in the back of my mind, ever since I saw something similar in an episode of Buck Rogers (70s-80s)! Many people struggle with falling asleep due to persistent beta waves; natural theta predominance is needed but often delayed. Imagine an "INEXPENSIVE" smart sleep mask that facilitates sleep onset by inducing brain wave transitions from beta (wakeful, high-frequency) to alpha (8-13 Hz, relaxed) and then theta (4-8 Hz, stage 1 light sleep) via non-invasive stimulation. A solution could be a comfortable eye mask with integrated headphones (unintrusive) and EEG sensors.
It could use binaural beats or similar audio stimulation to "inject" alpha/theta frequencies externally, guiding the brain to a tipping point for abrupt sleep onset. Sensors would detect current waves; app-controlled audio ramps from alpha-inducing beats to theta, ensuring natural predominance. If it could be designed, it could accelerate sleep transition, improve quality, non-pharmacological.
> For obvious reasons, I am not naming the product/company here, but have reached out to inform them about the issue.
Coward. The only way to challenge this garbage is "Name and Shame". Light a fire under their asses. That fire can encourage them to do right, and as a warning to all other companies.
Doesn't disclosing this to the world at the same time as you disclose it to the company immediately send hundreds of black hats to their terminals to see how much chaos they can create before the company implements a fix?
Perhaps the author is not a coward, but is giving the company time to respond and commit to a fix for the benefit of other owners who could suffer harm.
So your plan is to let the blackhats in the know attack user devices, rather than send out a large warning to "Quit using immediately"?
If we applied this similar analogy to a e.coli infection of foods, your recommendation amounts to "If we say the company name, the company would be shamed and lose money and people might abuse the food".
People need to know this device is NOT SAFE on your network, paired to your phone, or anything. And that requires direct and public notification.
I did consider naming, but they were very responsive to the disclosure and I was not entirely familiar with potential legal implications of doing so. (For what it's worth, it is not Luuna)
It's good that they were responsive in the disclosure, but it's still a mark of sloppiness that this was done in the first place, and I'd like to know so I can avoid them.
Even if naming and shaming doesn't work, I sure want to know so I can always avoid them for myself and my family. Thanks for the call-out and the educated guess.
Kickstarter is full of projects like this where every possible shortcut is taken to get to market. I’ve had some good success with a few Kickstarter projects but I’ve been very selective about which projects I support. More often than not I can identify when a team is in over their heads or think they’re just going to figure out the details later, after the money arrives.
For a period of time it was popular for the industrial designers I knew to try to launch their own Kickstarters. Their belief was that engineering was a commodity that they could hire out to the lowest bidder after they got the money. The product design and marketing (their specialty) was the real value. All of their projects either failed or cost them more money than they brought in because engineering was harder than they thought.
I think we’re in for another round of this now that LLMs give the impression that the software and firmware parts are basically free. All of those project ideas people had previously that were shelved because software is hard are getting another look from people who think they’re just going to prompt Claude until the product looks like it works.
At this point, I trust LLMs to come up with something more secure than the cheapest engineering firm for hire.
"Anyone else out there vibe circuit-building?"
https://xcancel.com/beneater/status/2012988790709928305
The cheapest engineering firms you hire are also using LLMs.
The operator is still a factor.
Yeah, but they’ll add another layer of complexity over doing it yourself
The people doing these kickstarters are outsourcing the work because they can’t do it themselves. If they use an LLM, they don’t know what to look for or even ask for, which is how they get these problems where the production backend uses shared credentials and has no access control.
The LLM got it to “working” state, but the people operating it didn’t understand what it was doing. They just prompt until it looks like it works and then ship it.
You're still not following.
The parents are saying they'd rather vibe code themselves than trust an unproven engineering firm that does(n't) vibe code.
> they'd rather vibe code themselves than trust an unproven engineering firm
You could cut the statement short here, and it would still be a reasonable position to take these days.
LLMs are still complex, sharp tools - despite their simple appearance and proteststions of both biggest fans and haters alike, the dominating factor for effectiveness of an LLM tool on a problem is still whether or not you're holding it wrong.
LLMs definitely write more robust code than most. They don't take shortcuts or resort to ugly hacks. They have no problem writing tedious guards against edge cases that humans brush off. They also keep comments up to date and obsess over tests.
I had 5.3-Codex take two tries to satisfy a linter on Typescript type definitions.
It gave up, removed the code it had written directly accessing the correct property, and replaced it with a new function that did a BFS to walk through every single field in the API response object while applying a regex "looksLikeHttpsUrl" and hoping the first valid URL that had https:// would be the correct key to use.
On the contrary, the shift from pretraining driving most gains to RL driving most gains is pressuring these models resort to new hacks and shortcuts that are increasingly novel and disturbing!
Interesting and completely wrong statement, what gave you this impression?
The discourse around LLMs has created this notion that humans are not lazy and write perfect code. They get compared to an ideal programmer instead of real devs.
Amen. On top of that, especially now, with good prompting you can get closer to that better than you think.
LLM's at best asymptotically approach a human doing the same task. They are trained on the best and the worst. Nothing they output deserves faith other than what can be proven beyond a shadow of a doubt with your own eyes and tooling. I'll say the same thing to anyone vibe coding that I'd say to programmatically illiterate. Trust this only insofar as you can prove it works, and you can stay ahead of the machine. Dabble if you want, but to use something safely enough to rely on, you need to be 10% smarter than it is.
I know right. I kept waiting for a sarcasm tag at the end
right and wrong don't exist when evaluating subjective quantifiers
And the cheapest engineering firm won't use LLMs as well, wherever possible?
The cheapest engineering firm will turn out to be headed up by an openclaw instance.
fun fact, LLMs come in cheapest and useless and expensive but actually does what's being asked, too.
So, will they? Probably. Can you trust the kind of LLM that you would use to do a better job than the cheapest firm? Absolutely.
this.
While most comments are focused on the issue that they found, I’m more intrigued by the fact that Claude was able to reverse engineer so well.
Lowering the skills bar needed to reverse engineer at this level could have its own AI-related implications.
How about complaining that brain waves get sent to a server? I'm a neuroscientist, so I'm not going to say that the EEG data is mind reading or anything, but as a precedent, non privacy of brain data is very bad.
Non-privacy of this person is currently sleeping data is very bad as well, for different reasons.
You know, now that I'm thinking about it, I'm beginning to wonder if poor data privacy could have some negative effects.
Unsecured fitness monitor data revealed military guard post (IIRC) activity a while back.
Yawp. T’was Strava. https://www.theguardian.com/world/2018/jan/28/fitness-tracki...
People will be lining up to have their brainwaves harvested because it'll be mildly easier to send emails or something similarly inane.
Corporations will be lining up to require their employees have their brainwaves harvested, so they can fire employees who aren't alert enough.
You could read the alertness level from an EEG, which could be helpful to a burglar. The device with slow-wave status seems ideal.
How useful could something like this be for research? I'm not a neuroscientist so I have no clue, but it seems like the only justification I can think of..
The general idea of an EEG system that posts data to a network?
Very, but there are already tons of them at lots of different price, quality, openness levels. A lot of manufacturers have their own protocols; there are also quasi/standards like Lab Streaming Layer for connecting to a hodgepodge of devices.
This particular data?
Probably not so useful. While it’s easy to get something out of an EEG set, it takes some work to get good quality data that’s not riddled with noise (mains hum, muscle artifacts, blinks, etc). Plus, brain waves on their own aren’t particularly interesting—-it’s seeing how they change in response to some external or internal event that tells us about the brain.
Not a neuroscientist either but I would imagine that raw data without personal information would not be useful for much. I can imagine that it would be quite valuable if accompanied with personal data plus user reports about how they slept each night, what they dreamed about if anything, whether it was positive dreams or nightmares etc. And I think quite a few people wouldn’t mind sharing all of that in the name of science, but in this case they don’t seem to have even tried to ask.
What if you gonna think about your social security number 30000 times in your dreams, and someone knows the pattern? See the danger? That's evil.
If they're taking patient data for research without permission, they are not ethical researchers.
Is it really “without permission” if it’s from a server for which the access credentials have been deliberately published to the entire internet?
If it's without the patient's permission, then yes, it is without the only permission that matters for medical ethics.
I believe they use it for sleep tracking
I would presume data privacy laws already have good precedent for health data?
> I would presume data privacy laws already have good precedent for health data?
Google for a list of all the exceptions to HIPPA. There are a lot of things that _seem_ like they should be covered by HIPPA but are not...
Interesting...
Only for "covered entities" under HIPAA (at least in the US)
Millions of people voluntarily use Gmail which gives a lot more useful data than EEG output to DHS et al without a warrant under FAA702. What makes you think people who “have nothing to hide” would care about publishing their EEG data?
Ok, obviously unethical to do it, but this sounds like you've got the power to create some sci-fi shared dreaming device, where you can read people's brainwaves and send signals to other people's masks based on those signals. Or send signals to everyone at the same time and suddenly people all across the world experience some change in their dream simultaneously.
Like, don't actually do it, but I feel like there's inspiration for a sci-fi novel or short story there.
Dreamscape, 1984
That’s the plot of Paprika.
Inception
Remember that the S in IoT stands for Security.
I have deployed open MQTT to the world for quick prototypes on non personal (and healthcare) data. Once my cloud provider told me to stop because they didn’t like it, that could be used for relay DDOS attacks.
I would not trust the sleep mask company even if they somehow manage to have some authentication and authorisation on their MQTT.
I don't think there is an S in IoT?..
Right - the saying indicates that IoT stuff is well known for ignoring security.
Went right over my head :)
Where I work, the saying is, "The H in ABC stands for Happiness."
(Also, "We're not happy until you're not happy.")
Thank you for your astute observation. :)
Exactly
I would love to see the prompt history. Always curious how much human intervention/guidance is necessary for this type of work because when I read the article I come away thinking I prompt Claude and it comes out with all these results. For example, "So Claude went after the app instead. Grabbed the Android APK, decompiled it with jadx." All by itself or the author had to suggest and fiddle with bits?
Very little intervention tbh. I will try to retrieve it and post.
By default, Claude code keeps session history (as jsonl files in ~/.claude).
It’s wasteful not to save and learn from those.
Really is a derth of livestreams demostrating these things. Youd think if thetes so much Unaided AI work people would stream it.
The shared hardcoded credentials pattern isn't just an IoT problem. I work in AWS security and see the same thing constantly. Teams hardcode a single set of AWS access keys into their application, share them across every environment, and hope nobody runs strings on the binary. Same logic, same laziness, same outcome.
The difference is when it's a sleep mask, someone reads your brainwaves. When it's a cloud credential, someone reads your customer database. Per-device or per-environment credential provisioning isn't even hard anymore. AWS has IAM roles, IoT has device certificates, MQTT has client certs and topic ACLs. The tooling exists. Companies skip it because key management adds a step to the assembly line and nobody budgets time for security architecture on v1.
> nobody budgets time for security architecture on v1
It’s quite literally why the internet is so insecure, because at many points all along the way, “hey, should we design and architect for security?” is/was met with “no, we have people to impress and careers to advance with parlor tricks to secure more funding; besides, security is hard and we don’t actually know what we are doing, so tow the line or you’ll be removed.”
The narrator in the article acts as a third person observer and identifies "Claude" as the active hacker. So assuming the (unidentified) company that sells/manages the product wants to prosecute a CFAA violation, who do they go after? Was Claude the one responsible for all of the hacking?
> I was not expecting to end up with the ability to read strangers' brainwaves and send them electric impulses in their sleep. But here we are.
Almost out of a Phillip K Dick novel
This feels like a reason to buy the device to me? I would want to block all of the data going to the cloud and would only want operations happening locally. But the MQTT broadcast then allows me to create a local only integration in Home Assistant with all of the data.
What's the real risk profile? Robbers can see you are asleep instead of waiting until you aren't home?
I have not implemented MQTT automations myself, but it's there a way to encrypt them? That could be a nice to have
Sounds like you cannot control which MQTT endpoint it is headed to? It just goes to the server of the device. Assuming you could modify the firmware, you could program it to send to a local MQTT.
Simpler just update your local network dns so whatevercompany.brain.com redirect to your local 10.0.0.3 mqtt
Name the company, hiding it is irresponsible
Author doesn’t spell out why they are not naming them, but my guess is they are trying to not promote the product to malicious actors who would be interested in the sleep data of others.
I guess that’s not a huge problem, though, since all users are presumably at least anonymous.
less sleep data, i imagine, and more the whole “send remote electrical impulses” thing
It’s probably safe to assume they are all like that.
This guy bought an internet connected sleep mask so it's not surprising that it was collecting all kinds of data, or that it was doing it insecurely (everyone should expect IoT anything to be a security nightmare) so to me the surprising thing about this is that the company actually bothered to worry about saving bandwidth/power and went through the trouble of using MQTT. Probably not the best choice, and they didn't bother to do it securely, but I'm genuinely impressed that they even tried to be efficient while sucking up people's personal data.
Meanwhile streaming everyone's data, negating any benefit.
huh, not sure if life imitates snark and bull https://medium.com/luminasticity/great-products-of-illuminat...
"The ZZZ mask is an intelligent sleep mask — it allows you to sleep less while sleeping deeper. That’s the premise — but really it is a paradigm breaking computer that allows full automation and control over the sleep process, including access to dreamtime."
or if this is another scifi variation of the same theme, with some dev like embellishments.
That is the premise of HypnoSpace Outlaw, a neat game about 90s internet nostalgia and scifi.
Well that’s a brand new sentence.
But not a beautiful sentence.
the shared MQTT credentials pattern is unfortunately super common in budget IoT. seen the exact same thing in smart plugs and air quality sensors. the frustrating part is per-device auth is not even hard to set up, mosquitto supports client certs and topic ACLs with minimal config. manufacturers skip it because per-device key provisioning adds a step to the assembly line and nobody wants to think about key management. so they hardcode one set of creds and hope nobody runs strings on the binary.
This smells like bullshit to me, although I am admittedly not experienced with Claude.
I find it difficult to believe that a sleep mask exists with the features listed: "EEG brain monitoring, electrical muscle stimulation around the eyes, vibration, heating, audio." while also being something you can strap to your face and comfortably sleep in, with battery capacity sufficient for several hours of sleep.
I also wonder how Claude probed bluetooth. Does Claude have access to bluetooth interface? Why? Perhaps it wrote a secondary program then ran that, but the article describes it as Claude probing directly.
I'm also skeptical of Claude's ability to make accurate reverse-engineered bluetooth protocol. This is at least a little more of an LLM-appropriate task, but I suspect that there was a lot of chaff also produced that the article writer separated from the wheat.
If any of this happened at all. No hardware mentioned, no company, no actual protocol description published, no library provided.
It makes a nice vague futuristic cyperpunk story, but there's no meat on those bones.
Yes, it is very lacking in details. The Claude output would have been interesting, or a few logs or protocol dumps.
The lack of detail makes me suspect the truth of most of the story.
A lot of BLE peripherals are very easy to probe. And there are libraries available for most popular languages that allow you to connect to a peripheral and poke at any exposed internals with little effort.
As for the reverse engineering, the author claims that all it took was dumping the strings from the Dart binary to see what was being sent to the bluetooth device. It's plausible, and I would give them the benefit of the doubt here.
https://www.kickstarter.com/projects/selepu/dreampilot-ai-gu...
Found that in seconds. EEG, electrical stimulation, heat, audio, etc. Claims a 20 hour battery.
As to the Claude interactions, like others I am suspicious and it seems overly idealized and simplified. Claude can't search for BT devices, but you could hook it up with an MCP that does that. You can hook it up with a decompiler MCP. And on and on. But it's more involved than this story details.
That appears to be more than a centimeter thick, and not particularly flexible. It's more like ski goggles than a sleep mask.
So yeah, a product exists that claims to be a sleep mask with these features. Maybe someone could even sleep while wearing that thing, as long as they sleep on their back and don't move around too much. I remain skeptical that it actually does the things it claims and has the battery life it claims. This is kickstarter after all. Regardless, this would qualify as the device in question for the article. Or at least inspiration for it.
Without evidence such as wireshark logs, programs, protocol documentation, I'm not convinced that any of this actually _happened_.
Claude, or any good agent, doesn't need MCP to do things. As long as it has access to a shell it can craft any command that it needs to fulfill its prompt.
There are no shell commands to do what is described. I could get Claude to interact with BLE devices, but it did it by writing and running various helper applications, for instance using the Bleak library. So I guess not an MCP per se.
I was originally going to ask something similar, but from a different angle.
These blog posts now making the rounds on HN are the usual reverse engineering stories, but made a lot more compelling simply because they involve using AI.
Never mind that the AI part isn't doing any heavy lifting and probably just as tedious as not using AI in the first place. I am confused why the author mentions it so prominently. Past authors would not have been so dramatic and just waved their hands that they had some trial and error before finding out how the app is built. The focus would have been on the lack of auth and the funny stuff they did before reporting it to the devs.
>Since every device shares the same credentials and the same broker, if you can read someone's brainwaves you can also send them electric impulses.
Amazing.
As an aside, it seems cool that the bar to reverse engineering has lowered from all the LLMs. Maybe we'll get to take full control of many of these "smart" devices that require proprietary/spyware apps and use them in a fully private way. There's no excuse that any such apps solely to interact with devices locally need to connect to the internet, like dishwasher.
https://www.jeffgeerling.com/blog/2025/i-wont-connect-my-dis...
It's disappointing to see. It doesn't take much work to configure a MQTT server to require client certificates for all connections. It does require an extra step in provisioning to give each device a client certificate. But for a commercial product, it's inexcusably negligent.
Then there's hardening your peripheral and central device/app against the kinds of spoofing attacks that are described in this blog post.
If your peripheral and central device can securely [0] store key material, then (in addition to the standard security features that come with the Bluetooth protocol) one may implement mutual authentication between the central and peripheral devices and, optionally, encryption of the data that is transmitted across that connection.
Then, as long as your peripheral and central devices are programmed to only ever respond when presented with signatures that can be verified by a trusted public key, the spoofing and probing demonstrated here simply won't work (unless somebody reverse engineers the app running on the central device to change its behaviour after the signature verification has been performed).
To protect against that, you'd have to introduce server-mediated authorisation. On Android, that would require things like the Play Integrity API and app signatures. Then, if the server verifies that the instance of the app running on the central device is unmodified, it can issue a token that the central device can send to the peripheral for verification in addition to the signatures from the previous step.
Alternatively, you could also have the server generate the actual command frames that the central device sends to the peripheral. The server would provide the raw command frame and the command frame signed with its own key, which can be verified by the peripheral.
I guess I got a bit carried away here. Certainly, not every peripheral needs that level of security. But, into which category this device falls, I'm not sure. On the one hand, it's not a security device, like an electronic door lock. And on the other hand, it's a very personal peripheral with some unusual capabilities like the electrical muscle stimulation gizmo and the room occupancy sensor.
[0]: Like with the Android KeyStore and whichever HSMs are used in microcontrollers, so that keys can't be extracted by just dumping strings from a binary.
Interesting project. Here's a thought which I've always had in the back of my mind, ever since I saw something similar in an episode of Buck Rogers (70s-80s)! Many people struggle with falling asleep due to persistent beta waves; natural theta predominance is needed but often delayed. Imagine an "INEXPENSIVE" smart sleep mask that facilitates sleep onset by inducing brain wave transitions from beta (wakeful, high-frequency) to alpha (8-13 Hz, relaxed) and then theta (4-8 Hz, stage 1 light sleep) via non-invasive stimulation. A solution could be a comfortable eye mask with integrated headphones (unintrusive) and EEG sensors. It could use binaural beats or similar audio stimulation to "inject" alpha/theta frequencies externally, guiding the brain to a tipping point for abrupt sleep onset. Sensors would detect current waves; app-controlled audio ramps from alpha-inducing beats to theta, ensuring natural predominance. If it could be designed, it could accelerate sleep transition, improve quality, non-pharmacological.
So are the brain waves the cause or the effect?
Are beta waves a sign that my mind is racing and wide awake, or are they the reason?
What’s your proposed mechanism for how audio waves would induce brain waves?
the headlines these days
"smart sleep mask :D - what next, smart toilet seats? Oh, wait...
Dudes so stupid being tied to tech everywhere.
Won't they sue for the reverse engineering?
On what grounds could they sue?
cyberpunk
> For obvious reasons, I am not naming the product/company here, but have reached out to inform them about the issue.
Coward. The only way to challenge this garbage is "Name and Shame". Light a fire under their asses. That fire can encourage them to do right, and as a warning to all other companies.
My guess is this is Luuna https://www.kickstarter.com/projects/flowtimebraintag/luuna
Doesn't disclosing this to the world at the same time as you disclose it to the company immediately send hundreds of black hats to their terminals to see how much chaos they can create before the company implements a fix?
Perhaps the author is not a coward, but is giving the company time to respond and commit to a fix for the benefit of other owners who could suffer harm.
but is giving the company time to respond and commit to a fix for the benefit of other owners who could suffer harm.
If that's the case then they should have deferred this whole blog post.
It took me 30 seconds with ChatGPT by saying:
Identify the kickstarter product talked around in this blog post: (link)
To think some blackhat hasn't already did that is frankly laughable. What I did was like the lowest of low-bars these days.
Put the product name in the title & maybe it sends thousands instead of hundreds of blackhats…
We often treat doxxing the same way, prohibiting posting of easily discovered information.
So your plan is to let the blackhats in the know attack user devices, rather than send out a large warning to "Quit using immediately"?
If we applied this similar analogy to a e.coli infection of foods, your recommendation amounts to "If we say the company name, the company would be shamed and lose money and people might abuse the food".
People need to know this device is NOT SAFE on your network, paired to your phone, or anything. And that requires direct and public notification.
And ChatGPT hallucinated a misleading answer that you are confidently regurgitating.
their original message said "my guess", not ChatGPT's, talk about responsible disclosure...
I did consider naming, but they were very responsive to the disclosure and I was not entirely familiar with potential legal implications of doing so. (For what it's worth, it is not Luuna)
Please name 50 other companies it's not.
It's good that they were responsive in the disclosure, but it's still a mark of sloppiness that this was done in the first place, and I'd like to know so I can avoid them.
I don't see estim mentioned on that website, but I do see a comparison chart with 4 other competitors with similar capabilities to the one you linked.
What makes you think this is the one?
https://meta.wikimedia.org/wiki/Cunningham%27s_Law
I said a guess, not absolute.
Even if naming and shaming doesn't work, I sure want to know so I can always avoid them for myself and my family. Thanks for the call-out and the educated guess.
EEG devices can cost a lot to own personally as well.
The other side of owning equipment like this is it still could be useful for some for personal and private use.
EEG is very useful for accurate sleep tracking.
Presumably they’ll be named and shamed after they’ve been given a chance to fix things.
Without a brand name, how can we verify this is real?
Without any skin in the game with your username, why should we take anything you say seriously?
Interesting position in a thread about the dangers of exposing yourself to the internet.