Hacking a Smart Home Device (2024)

jmswrnr.com

317 points by walterbell 11 days ago


jqpabc123 - 11 days ago

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.

systemtest - 11 days ago

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.

walterbell - 11 days ago

For vendors of ESP32-based IoT devices:

  Give a man a fish, and you feed him for a day.
> My intentions were solely to upgrade the smart device I've purchased to integrate with my smart home system. Doing so does not affect any other instances of this product or its cloud services.. sensitive product-specific data, such as private keys, domains, or API endpoints, have been obfuscated or redacted.

For owners of ESP32-based IoT devices:

  Teach a man to fish, and you feed him for a lifetime.
> Creating an open-source project to de-cloud and debug smart home products; I've learned much more about the technical aspects.. I put a massive amount of effort into creating [this post].. probably more than.. the project itself. It would be amazing to receive feedback on the format!

blog author: https://x.com/jmswrnr

harg - 11 days ago

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.

simgt - 11 days ago

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.

mrlambchop - 11 days ago

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

lewj - 11 days ago

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!

lgunsch - 11 days ago

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.

z3t4 - 11 days ago

You should not need to hack something you bought in order to use it. The "rent seeking" economy needs to be regulated or forbidden.

bschwindHN - 11 days ago

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!

smjburton - 11 days ago

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

hxii - 11 days ago

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.

stavros - 11 days ago

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.

Oxodao - 11 days ago

For initial RE, I'd highly suggest jadx-gui over dex2jar+jd-gui it has a lot of nice feature

robertlagrant - 11 days ago

> No Cap device found!

Of course, in 2025 this means "I really did find a device!"

CommenterPerson - 11 days ago

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.

paranoidrobot - 11 days ago

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.

Havoc - 11 days ago

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

your_challenger - 11 days ago

Great article and great website. I love that every external link showed a favicon like image next to it.

hilti - 11 days ago

Awesome journey! Thank you for having me … I learned a lot.

timc3 - 11 days ago

Fantastic article.

Makes me want to do the same on some devices I have.