hckrnws
The ultimate long term solution --- refuse to buy any home product that defies local control.
If a wifi password is required to make full use of the device, I will return it.
If some users want to sacrifice security and privacy for "convenience", that's on them. But if you want to sell me the product, at least provide the option to decline without loss of functionality. Otherwise, no sale.
As an example, I refuse to buy a doorbell camera that doesn't support RTSP.
> As an example, I refuse to buy a doorbell camera that doesn't support RTSP.
This is a good example of conflicting security requirements.
Not wanting the video to go to the cloud is fine, but most cameras with RTSP enabled allow any other device on the network to trivially get the camera stream, and sometimes also control the camera. This is why some camera companies require you jump through hoops to unlock RTSP - I don't like it but I can see why they do it.
This is one reason I've come to believe it's necessary that every device must see a totally different network universe from every other, able only to see the local controller server. (This is how I ended up playing with on AP video relays in my profile, as an effort to see what's involved). Things like multicast discovery is cool, but an absolute privacy and security disaster area.
but most cameras with RTSP enabled allow any other device on the network to trivially get the camera stream, and sometimes also control the camera.
Not a real concern when the network is fully under my control. I can easily restrict access as I see fit.
I surrender all control when I give up my wifi password and allow similar access to somebody's network located somewhere on the internet. Further access can be (and has been) granted to others without user knowledge or consent. For example:
https://arstechnica.com/tech-policy/2022/07/amazon-finally-a...
You can - but will you? And you are in the tiny minority of people who understand what that even means. The vast majority of humans have better things to do with their life than figure out how to secure their personal network. (I'm not saying they are too stupid to figure out how - just that they have better things to do with their time)
The vast majority of humans have better things to do with their life than figure out how to secure their personal network.
Sure. But this doesn't have to be an either/or choice.
It's possible to make it easy for those willing to surrender all privacy and control without making it impossible for those who don't.
Example: Amcrest cameras are just fine with being restricted to the local network. If you ask nicely and order direct, they'll even give you a discount.
We need a system so pervasive that if you order random devices from aliexpress they use it, and they cannot cause trouble because they're properly contained. It's not enough for you to have good security, you need to know your neighbours do too.
My vision of how this should work can be inferred from https://github.com/atomirex/umbrella Essentially in the future wherever we have WiFi APs those should also be media SFUs (and probably MQTT brokers or similar) where each client will only see the AP and things the applications running on the AP have explicitly allowed, including streams piped opaquely from anywhere else.
The idea that being connected to WiFi means ability to see other devices and the public internet needs to stop being the default.
Per-device WiFi auth/identity can help with IoT device isolation.
that is the wrong take. We need to protect the people who have better things to do.
People who have better things to do, won't want rtsp
What they do want though is their privacy protected. They shouldn't have to think about why or how they want it protected, they should just have it done for them.
Exactly, this stuff needs to be made the easy default.
Right now domestic IoT and Home Assistant are like Windows Mobile and Symbian prior to the iPhone: proof that something interesting and useful is possible in the domain, but requiring an enthusiast level of investment in knowledge and time to maintain and operate.
Were I a billionaire I would be attempting to launch the Android (in the original intended sense) of IoT to solve that.
Matter, specifically matter over thread, is pretty much the right solution for the end devices.
>The vast majority of humans have better things to do with their life than figure out how to secure their personal network.
One might hope this to be the case, but there are mountains of evidence to the contrary.
>I'm not saying they are too stupid to figure out how
Never fear. I'm here to say it so that you don't have to. Most are too stupid.
One overlooked variable here is that price is a huge consideration factor into IoT acceptance. Convenience is one thing, but having to pay 10x more is another.
China(up to now, now with tariffs stuff... who knows) has been exceptional in that they produced IoT devices for many use cases at very reasonnable prices. Want a water leak detector that's zigbee connected? that's only 5 bucks. if I want to buy one from a "western" company(still produced in china) it instantly gets marketed to a premium market and costs 10x or 20x more.
They have no incentive to make their products work in pure local when companies like Tuya provide SDKs, chips, and frameworks at a low price and easy entry barrier. But of course that locks into their ecosystem.
It's possible that a company making an open toolkit with easy integration for esp32/etc could gain enough traction to get many devices to use that, but at this point it's unlikely.
As for HA... I love it and run it locally, but it's not for the faint of heart. And spending dozens of hours modifying devices and configuration to get everything running is a priviledge few have the skills, time and knowledge to do.
As always... this is a case of "the only incentive is money and hence the system will lock itself".
Wouldn't it be great if the EU could force these companies to surrender local control?
Basically full local home assistant support or I'm not buying. Some products start to have badge on the box.
I've been doing this for years, but it's hard work trying to get information on how bad these devices could spy on you - before you buy them
I just guess now and make sure the company has a good returns policy
it's hard work trying to get information on how bad these devices could spy on you
The orange flag is when setup requests my wifi password.
But the big red flag for me is when configuration fails without unfettered WAN access. In this case, the product goes back in the box. If you allow this, you allow anything. Someone else effectively owns the device.
An easy test for this --- simply unplug your network from the WAN modem and see what happens.
For the most part I just stick to zigbee devices and I can be sure they're fully under my local control because their only gateway to the network is the zigbee modem attached to my Raspberry Pi running Home Assistant. Sometimes requires messing with some quirks to get the full functionality I need out of them, but the community is pretty good about supporting most devices out of the box.
> If a wifi password is required to make full use of the device, I will return it.
This is one of my favourite uses of OpenWRT, or any other firmware that gives you proper control over the router - for WiFi-networked IoT devices, I set up a separate wireless network with no WAN/LAN access and client isolation. I can connect to the device, but it can't connect to WAN, any other devices on the IoT network, or my LAN.
Of course this won't work for cloud-tethered devices, but many will expose their functionality directly over network.
Can you tell me which one you arrived on in your research? I would like a local controlled doorbell camera
Amcrest. See my post below (or above).
Not OP, but I ended up with Reolink.
> If a wifi password is required to make full use of the device, I will return it.
By that logic, you will not buy any "smart" devices
A camera doorbell, in your example, need wifi password so that it can stream video.
A smart lightbuld need wifi connection to change brightness or color.
Without wifi connection, it will lose a part of functionality
Philips Hue and many other similar smart light bulbs connects to my zigbee network with no Wi-Fi needed. It's remarkably simple to control them from Home Assistant, which I can run on a fully isolated home network. When my Internet gave out for two weeks (the perils of living in a forest) lots of stuff became inconvenient, but my smart light bulbs continued to work perfectly.
The point is not wifi. Wifi is just a protocol, like zigbee, or lora, etc.
Giving something wifi password is different from giving something internet access, they are not inclusive. You just add it to your local network without giving it internet access
In your case, does your smart bulb still have same functionality if you dont add it to your zigbee network ?
There are camera doorbells with PoE.
Thinking that through with PoE and Ethernet. Outside of MAC address white listing, how does one protect one's local Internet from being jacked in from the doorbell, externally?
Wired encryption and auth?
"MACsec (802.1AE) and EAPOL (802.1X)", https://forum.openwrt.org/t/macsec-802-1ae-with-802-1x-eapol...
So wrong.
There are protocols like zwave, zigbee, and possibly others that not only not need wifi passwords, they don't even need an IP address.
That's simply not true.
There are plenty of smart devices (including lighbulbs, sensor movements, and what not)t hat use bluetooh, or protocols like Zigbee that enable all kind of functionality without wifi password.
I believe he meant connectinon to the cloud of service provider.
The result of this process is that the air purifier boosts when the air quality inside drops.
I feel like that is something that doesn’t or at least shouldn’t require a string of IoT devices, apps, wireless communication and hubs. Why not leave all of that out and just attach an air quality sensor to the air purifier and a small LCD to adjust the settings?
The light in my hallway turns on automatically when I walk past. No cloud, no HomeAssist, no WiFi, no Zigbee, no apps, no batteries to change. Just a motion sensor hardwired to the light fixture. Hasn’t failed me once in the past ten years. Works great even if the network goes down.
While the author gave a contrived need of controlling this device like the others, they may be simplifying their motivations for the purpose of focusing the article.
homeassistant allows you to perform follow on work or even long term analysis. For example the author could use the information to decide what times of day during which seasons are best for airing out the house (more popular in Europe than North America), or if air quality dips happen to coincide with their leaky clothes dryer spewing fibers and soap particles out into the home, or when they cook on their gas range, etc.
Some people just like to explore and discover. Low threat information is nice these days.
> Just a motion sensor hardwired to the light fixture. Hasn’t failed me once in the past ten years.
Funny you mention that, because I'm putting in smart movement sensors to make sure the lights don't come up at night in the garage where the dog sleeps, but also so that I can force the light on for a long period, when I'm doing some work in the same area. People have different needs/expectations.
AQ sensors add cost. I've also never seen a reliable AQ sensor on a air filter. I have several Coway which go into turbo mode at random times and a couple of others that never go above fan speed 1, even when my dedicated AQ sensor shows elevated PM2.5.
A dumb device without leds/screens/connectivity that I can control with a smart plug via HA is much easier to deal with.
For vendors of ESP32-based IoT devices:
Give a man a fish, and you feed him for a day.
For owners of ESP32-based IoT devices:
Teach a man to fish, and you feed him for a lifetime.
blog author: https://x.com/jmswrnr
Doesn't he have Bluesky? I refuse to use twitter.
Edit: whoever downvotes this can rot in hell :D
You can avoid using Twitter web or app by using a (hopefully self hosted) Nitter instance.
No, just don't use Twitter please. It is still a website owned by a world destroying fascist.
I wonder if it would be possible to figure out which pins are connected to what on the device's board and just flash the thing completely with ESPHome and write a custom yaml config for it, rather than adapting the existing vendor firmware.
It's certainly possible. Tracing the MCUs IO lines to LEDs/buttons/relays etc on a PCB is usually pretty straightforward.
I have just finished doing this and writing replacement firmware for the Aqara E1 series of Zigbee switches, after getting fed up with them not supporting basic Zigbee binding functionality.
Amazing. I have the Aqara Z1s and it has the SI labs MG24 chip. Ive always wanted to reflash it because I believe it supports thread at a hardware level.
It would be really easy. I'm not sure why the author has gone through so much effort to hide what filter this is, but I'm assuming J2 is the blower power output and J3 is touchpad controls.
I've done exactly this on my own air filter, and it's about 200 lines of config. The hardest part is mapping binary outputs to a percentage:
switch:
- platform: gpio
pin: GPIO21
id: fan_low
interlock_wait_time: 250ms
interlock: &interlock_group [fan_low, fan_mid, fan_high, fan_turbo]
- platform: gpio
pin: GPIO25
id: fan_mid
interlock_wait_time: 250ms
interlock: *interlock_group
- platform: gpio
pin: GPIO22
id: fan_high
interlock_wait_time: 250ms
interlock: *interlock_group
- platform: gpio
pin: GPIO17
id: fan_turbo
interlock_wait_time: 250ms
interlock: *interlock_group
output:
- platform: template
id: fan_speed_output
type: float
write_action:
- lambda: |-
id(fan_low).turn_off();
id(fan_mid).turn_off();
id(fan_high).turn_off();
id(fan_turbo).turn_off();
auto light = ((AddressableLight*)id(status_light).get_output());
for (int i = 6; i <= 9; i++) {
light->get(i).set(Color::BLACK);
}
if (state < 0.24) {
} else if (state < 0.26) {
id(fan_low).turn_on();
light->get(6).set(Color(255,0,0,0));
} else if (state < 0.51) {
id(fan_mid).turn_on();
light->get(7).set(Color(255,0,0,0));
} else if (state < 0.76) {
id(fan_high).turn_on();
light->get(8).set(Color(255,0,0,0));
} else {
id(fan_turbo).turn_on();
light->get(9).set(Color(255,0,0,0));
}
light->schedule_show();
fan:
- platform: speed
name: "Filter Speed"
output: fan_speed_output
speed_count: 4
id: my_fanOn top of that, it looks like it would be relatively easy to spoof the cloud server and make the device believe that there is a firmware update available to then feed it esphome, a bit like the switchbota hack.
That would've been my go-to, and has been with most of the other "smart" devices in my house.
Very nice article!
Every time I was part of a team designing IoT devices, there would be a slightly more security-focused engineer who would manage to have some level of protection for the boot. I'm surprised there was no resistance here to dump and reflash the firmware. Why would they not even bother encrypting the flash? How common is that?
It would have been nice to give the product name.
> I'm surprised there was no resistance here to dump and reflash the firmware.
Some devices are purchased because their firmware is easy to replace. Upcoming regulations on IoT cybersecurity might make it harder to sell such devices. ESP32-based devices have been successful in several niches, https://hn.algolia.com/?query=esp32
Great article - enjoyed it a lot!
re: the notes on the use of the device keys (stored in the K/V store), assuming that they are per device would seem the most obvious vs that they are global. Global keys would be written in the main app body in my experience, not the KV store (but that doesn't mean people have not done unusual things here of course!).
I also want to share some feedback on the complexity of managing per device keys these days and the risks - there are lots of easy to use tools that per device keys like this much simpler to do in 2025 than 2015 and cloud platforms that take in CSV files and return very similar messages... Typically a security model for a device such as an air purifier can be easily defined as not having device encryption enabled if it has per-device keys on as the impact of breaching a single device remains compartmentalized to a single edge component and in this case, just a purifier (vs a car or something that explodes!). Not that I agree with this, but corporate security can! Device encryption causes lots of problems in factories that are often best 'ignored' if the product can afford it.
Per another comment, god bless ESP32 developers once the EU rule kicks in in August... !
Oh oh - what EU rule?
EU CRA (Cyber Resilience Act), https://www.venable.com/insights/publications/2024/01/prepar...
Lovely write up - easy to follow!
Wonder why the company didnt just go with a standardised solution - seems more cost effective than rolling their own!
I've seen a number of ESP32 IoT devices here on HN, and I haven't heard many of them use firmware encryption with an eFuse.
In this case, it would have been pretty hard to create a certificate if you couldn't read the firmware.
But, also pretty impressed at the same time. I think this is the first Hacker News article I've read about an ESP32 IoT device which has any encryption at all.
Even if they use firmware encryption, the footprint for most of the ESP32 packages is really easy to desolder and replace with a fresh one under your control with basic tools. This option is harder if the ESP32 is speaking some digital protocols to various devices, but having re-brained another air purifier myself they often are just flipping some GPIO lines to signal different components to turn on. Easy in that case to just stare at it for a bit then re-flash or replace and re-flash the ESP32 with your own firmware.
You should not need to hack something you bought in order to use it. The "rent seeking" economy needs to be regulated or forbidden.
Nice writeup and very comprehensive! I've done some ESP32 development in the past and I vowed to always use an open protocol and allow users to connect devices to their own servers, if I ever made a product based on it.
You really went through the whole reverse engineering process end to end, I know that must have been a ton of work to not only reverse engineer it but also to write everything up!
> For better or worse, the engineers behind the service decided not to implement a standard protocol like DTLS.
> We're not certain if each device has its own unique private key, but whether it does or not, both have downsides ... If all devices share the same firmware private key, the attacker needs to reverse engineer just a single device to MITM attack any other devices.
If anything, this article further highlights that security on these type of devices isn't as rigorous as other consumer electronics like laptops or smartphones. Anyone using smart devices should look into DD-WRT, OpenWrt, Tomato, or Asuswrt-Merlin and isolate these devices in their own VLAN away from the rest of your private network.
If anything, devices of that nature should have local control via Bluetooth LE, and not require some crappy proprietary cloud
Agreed, the ideal solution would be to control these devices without being on your home network at all.
I’ve got a power station (Ugreen) with an ESP32 that I’d also love to connect to HomeAssistant, instead of their app which provides me no benefit.
This is definitely beyond my capabilities at this point but it could be interesting to go through a similar process once mentally ready.
Imagine a mental price tag alongside IoT cybersecurity label, https://arstechnica.com/information-technology/2023/07/the-c...
"US Cyber Trust Mark" - I can trust the server is in Room 641A and they added microphones and cameras to my smart plug.
It's not. Get a usb-serial cable. Open it up, attach that, load Tasmota firmware. Takes a little bit of fiddling to figure out which gpio goes to which relay sometimes, but once you've gotten the pattern you can upload it so others don't have to figure it out next time.
This is a great article, but I really hate the fact that we have to rely on weak security to make our devices consumer-friendly/usable. I'm looking forward to the EU passing some law that says that devices should work locally as well, and then everything can just be Zigbee. I love Zigbee.
For initial RE, I'd highly suggest jadx-gui over dex2jar+jd-gui it has a lot of nice feature
Not only that, jadx operates on dex files directly and the conversion from dex to regular JVM classes can sometimes be lossy. So you tend to get better decompilation with jadx vs dex2jar and any regular Java decompiler.
> No Cap device found!
Of course, in 2025 this means "I really did find a device!"
Top notch work and writeup. Many Thanks.
I couldn't do 10% of this, and don't wish to spend a part of my life wrestling with gadgets like this. Simply will not buy. Also simply will avoid most all social media.
As far as I can tell it doesn't mention which air purifier.
Knowing that might help influence purchasing decisions for those also interested in a "sleek" air purifier that contains an ESP32.
I highly suspect that this is a Levoit air purifier. I recently purchased a Levoit 300S and had the same issue. The VeSync app connects the device directly over the internet and you can control it via an API on their domain with a username and password. Your air purifier is then a backdoor to your home network. I just put it on a guest network now rather than go through this.
I suspect hiding the manufacturer/model was very much on purpose, they blurred the markings on the PCB and hid the domain name for the manufacturer's API calls (and in the console logs as well).
I agree, hopefully it helps not getting the article taken down because its a very good primer on getting any ESP based device locally working.
I guess that is on purpose. After all the article could easily be rewritten as a successful attack on the manufacturer infra using a private key extracted from a device.
So the Authors Home Assistant Integration could be at risk to stop working quite quickly...
The recent drama around the unitree robot being effectively a beachhead on network has made me much more wary of connecting anything. Think I’ll stick to tasmota and zigbee going forward
Can you tell me more about the Unitree drama?
https://news.ycombinator.com/item?id=43604706
Upon gaining access to the CloudSail API, which they did using a recovered API key, they could:
List all connected devices and their IP addresses
Establish remote tunnels to those devices
Access the robot dog’s web interface with no authentication
Use the robot’s cameras for live surveillance
Log in via SSH using default credentials (pi/123)
Move laterally within internal networks to which the robot is connectedGreat article and great website. I love that every external link showed a favicon like image next to it.
Awesome journey! Thank you for having me … I learned a lot.
Fantastic article.
Makes me want to do the same on some devices I have.
Crafted by Rajat
Source Code