[HN Gopher] Hacking a Smart Home Device (2024)
___________________________________________________________________
Hacking a Smart Home Device (2024)
Author : walterbell
Score : 297 points
Date : 2025-04-15 03:12 UTC (19 hours ago)
(HTM) web link (jmswrnr.com)
(TXT) w3m dump (jmswrnr.com)
| hilti wrote:
| Awesome journey! Thank you for having me ... I learned a lot.
| paranoidrobot wrote:
| 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.
| rx_tx wrote:
| 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).
| timc3 wrote:
| 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.
| deanc wrote:
| 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.
| rickdeckard wrote:
| 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...
| hxii wrote:
| 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.
| walterbell wrote:
| Imagine a _mental price tag_ alongside IoT cybersecurity label,
| https://arstechnica.com/information-technology/2023/07/the-c...
| blitzar wrote:
| "US Cyber Trust Mark" - I can trust the server is in Room
| 641A and they added microphones and cameras to my smart plug.
| NoMoreNicksLeft wrote:
| 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.
| bschwindHN wrote:
| 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!
| walterbell wrote:
| 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
| brettermeier wrote:
| Doesn't he have Bluesky? I refuse to use twitter.
|
| Edit: whoever downvotes this can rot in hell :D
| walterbell wrote:
| https://bsky.app/profile/jmswrnr.com
| ajot wrote:
| You can avoid using Twitter web or app by using a (hopefully
| self hosted) Nitter instance.
| simgt wrote:
| 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.
| walterbell wrote:
| _> 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
| timc3 wrote:
| Fantastic article.
|
| Makes me want to do the same on some devices I have.
| lewj wrote:
| 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!
| Oxodao wrote:
| For initial RE, I'd highly suggest jadx-gui over dex2jar+jd-gui
| it has a lot of nice feature
| grishka wrote:
| 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.
| jqpabc123 wrote:
| 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.
| 123pie123 wrote:
| 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
| jqpabc123 wrote:
| _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.
| connicpu wrote:
| 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.
| mrheosuper wrote:
| > 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
| afroboy wrote:
| I believe he meant connectinon to the cloud of service
| provider.
| pelario wrote:
| 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.
| marci wrote:
| There are camera doorbells with PoE.
| zeta0134 wrote:
| 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.
| 63stack wrote:
| 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.
| dzikimarian wrote:
| Basically full local home assistant support or I'm not buying.
| Some products start to have badge on the box.
| fidotron wrote:
| > 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.
| jqpabc123 wrote:
| _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...
| bluGill wrote:
| 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)
| fidotron wrote:
| 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.
| NoMoreNicksLeft wrote:
| >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.
| jqpabc123 wrote:
| _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.
|
| https://amcrest.com/
| bluGill wrote:
| that is the wrong take. We need to protect the people who
| have better things to do.
| dd_xplore wrote:
| People who have better things to do, won't want rtsp
| bluGill wrote:
| 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.
| fidotron wrote:
| 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.
| walterbell wrote:
| Per-device WiFi auth/identity can help with IoT device
| isolation.
| mzajc wrote:
| > 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.
| fcpk wrote:
| 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?
| VladVladikoff wrote:
| Can you tell me which one you arrived on in your research? I
| would like a local controlled doorbell camera
| jqpabc123 wrote:
| Amcrest. See my post below (or above).
| fullstop wrote:
| Not OP, but I ended up with Reolink.
| Havoc wrote:
| 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
| simonjgreen wrote:
| Can you tell me more about the Unitree drama?
| walterbell wrote:
| 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 connected
| harg wrote:
| 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.
| ddeck wrote:
| 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.
| wezdog1 wrote:
| 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.
| stereo wrote:
| On 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.
| MadnessASAP wrote:
| That would've been my go-to, and has been with most of the
| other "smart" devices in my house.
| alright2565 wrote:
| 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_fan
| mrlambchop wrote:
| 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... !
| your_challenger wrote:
| Great article and great website. I love that every external link
| showed a favicon like image next to it.
| z3t4 wrote:
| You should not need to hack something you bought in order to use
| it. The "rent seeking" economy needs to be regulated or
| forbidden.
| systemtest wrote:
| 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.
| cheschire wrote:
| 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.
| viraptor wrote:
| > 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.
| turtlebits wrote:
| 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.
| stavros wrote:
| 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.
| robertlagrant wrote:
| > No Cap device found!
|
| Of course, in 2025 this means "I really did find a device!"
| CommenterPerson wrote:
| 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.
| lgunsch wrote:
| 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.
| gh02t wrote:
| 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.
| smjburton wrote:
| > 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.
| vsviridov wrote:
| If anything, devices of that nature should have local control
| via Bluetooth LE, and not require some crappy proprietary cloud
| smjburton wrote:
| Agreed, the ideal solution would be to control these devices
| without being on your home network at all.
___________________________________________________________________
(page generated 2025-04-15 23:01 UTC)