Hijacking The Sonoff OTA Mechanism

ITEAD’s Sonoff line is a range of Internet-of-Things devices based around the ESP8266. This makes them popular for hacking due to their accessibility. Past projects have figured out how to reflash the Sonoff devices, but for [mirko], that wasn’t enough – it was time to reverse engineer the Sonoff Over-The-Air update protocol.

[mirko]’s motivation is simple enough – a desire for IoT devices that don’t need to phone home to the corporate mothership, combined with wanting to avoid the labor of cracking open every Sonoff device to reflash it with wires like a Neanderthal. The first step involved connecting the Sonoff device to WiFi and capturing the traffic. This quickly turned up an SSL connection to a remote URL. This was easily intercepted as the device doesn’t do any certificate validation – but a lack of security is sadly never a surprise on the Internet of Things.

After capturing the network traffic, [mirko] set about piecing together the protocol used to execute the OTA updates. After a basic handshake between client and server, the server can ask the client to take various actions – such as downloading an updated firmware image.  After determining the messaging format, [mirko] sought to create a webserver in Python to replicate this behaviour.

There are some pitfalls – firmware images need to be formatted slightly differently for OTA updates versus the usual serial upload method, as this process leaves the stock bootloader intact. There’s also the split-partition flash storage system to deal with, which [mirko] is still working on.

Nevertheless, it’s great to see hackers doing what they do best – taking control over hardware and software to serve their own purposes. To learn more, why not check out how to flash your Sonoff devices over serial? They’re just an ESP8266 inside, after all.

25 thoughts on “Hijacking The Sonoff OTA Mechanism

    1. It’s a great business model for IoT device manufacturers/sellers. Collect money for hardware and service, and then move on. I bet they are all careful to never promise indefinite service.

        1. IoT companies if they cared about their customers won’t lock them in or disable their devices if they fold, but would have a exit plan.

          I’m starting an IoT device company. A hope of mine is to decrease the cost of the device to barely over production costs and sell the service. This is the cell phone model; few people buy a full priced phone, preferring instead to pay for the service. This would enable the price of automation to come to people who ordinarily would not be able to afford it, yet still be good revenue for me.

          Something I am committed to is if I have to fold up shop, I will open the source of the server so that if someone else wants to take over they can. I may even open the source day one. Customers are entrusting me with their business and I want to thank them with that trust by being a service they can know will be around for a long time, even if I must close my doors. It’s what I would want for myself.

          I am listening to the complaints people make about IoT, and I intend to do it right. For example the ESP8266 was my initial choice but when I saw it is inherently vulnerable to man in the middle attacks out if went. The thing is basically a toy. Security is a big priority for me. No open ports on the device, all communication runs through TLS and individual messages/updates are also encrypted with AES using individual per device pass phrases, and the servers are going to be highly compartmentalized. It’s what I would want for myself. (Suggestions welcome, if you see flaws with what I said please point them out. I have been reading IoT security best practices though.)

          I believe IoT can be done so that it is a win-win, but the company has to care about its customers and not just the almighty dollar.

  1. All the woes of the IoT, predicted years ago by myself and many others, pretty much go away when you ARE the mother ship. Wanting some automation to help me around my off-grid homestead meant, for me, creating a LAN of things – more or less the same ideas, just no intermediary. Some of the “things” are raspberry pies – for nice web servers with mysql databases and “smart but slow” tasks, some of those with arduino slaves (more sensors and time determinism), some are mere ESP8266 or ESP32. This is woefully underdocumented on my forums, just about enough to let me fix it or improve it, but I expect to fill in more later on as things evolve. Right now, there are just too many webpages (some CGI) controlling things, no real customization for collating the data from or to more than one thing into a single interface, and as of yet, no way to just command things to happen programmatically – I have to log into one of my little websites and say “do it”, for example, let water flow from rain collection to cistern until that fills, if and only if the water isn’t turbid (pollen or algae) in which case pour that on the ground.
    Control the woodstove – sadly there’s no robot to select and stuff wood into it, but it has a servo controlled butterfly valve air intake. Is it cold in here, or out there? Start or stop some air mover. Control various things about the solar system – is there enough spare to charge my Volt if it needs it?

    Still learning how to get this right as a *system* – as a many-decades engineer, there’s no piece I can’t just slap together, but even as a systems guy – it can be hard to predict just what you want even if almost anything is possible…just sayin. Right now “it just grew” and it shows.

    “If you’re so smart, and people want fire that can be fitted nasally, than what color should it be, huh?”

      1. I’ll be sure and publish the project when it reaches general usability. Right now I’m reverse engineering Xantrex’s (was Trace before, now Schneider) sooper sekrit adaptation of some old scada bus to CAN in publish-subscribe that can’t even handle all my controllers and inverters without dying due to collisions – I have to have some of them “just guess” what to do and have other system monitors (one of the pies and arduinos monitors the battery box and controls the water pump and cooling fan on my backup generator too). Which even then won’t quite tell me all I need to know, as it only says things like “I’m delivering this much power here or there from here or that other thing” and nowhere says “there’s this much available” from the panels – it doesn’t know itself until it hits a limit. So, I’m going to have to also hang a few mini-panels that ape the ones in my arrays (in two locations on my ‘stead with different shadow issues) and project from them (via perhaps some ESPs) what I’ve got *to spare*, as the big controllers immediately cut back amps to the batteries (as they should) based on battery voltage (temperature compensated, even). Then that “spare” power – solar tends to be flood or famine – can charge my car, run a distillation rig (water…) or whatever diversion load intelligently, rather than just trying things and seeing if the battery voltage then goes down (clouds come and go…so need a little algo to handle “it’ll be fine on average and the house batteries will be charged at the end of the day”).

        This is all moving me to do the re-design as I mentioned where things can programatically slurp data or send commands among themselves without me surfing to one web page to see some number, then another to press a “Do it” button on a CGI page. I’ll have to decide on how I’ll do the messaging layer on top of the ethernet protocol; I’ll likely use UDP and some high numbered port for that, as I already do for a homebrew “DNS” resolver.

        I’m right now working on a pi based WAP that can “see” all the LAN of things on the wireless side, and my normal LAN on the wired side, not passing messages straight through but making its own website my normal machines can do that scatter-gather thing with (and making it almost unhackable from the side that also hooks to the telco). Yeah, security by obscurity, I know, but it’s quite obscure as is.

        1. Sounds like quite the project! If you haven’t already, I would highly recommend looking at Home Assistant as the ‘controller’. It has native abilities to control lots of stuff, but it can also shell out to do things on demand even if it doesn’t directly support it. The automation engine is also pretty impressive, it’s all open source and written in python. It also stores history, if you are into data gathering.

        2. Your Xantrex issues(yes I know the name has changed, but the quailty hasn’t) are not surprising. I only had problems with the Xantrex stuff I worked with in Haiti.

          I prefer Magnum inverters, since that’s what I had, but the outback stuff also had no issues.

          Somewhere I’ve got the communications protocol for the magnum units if you’d like it. Find me on Thingiverse, and contact me through there.

          I tried contacting them for some clarification as I wanted to build my own auto-start system for the generator I made, so the generator would read the info the magnum sent out and start when the voltage reached a certain threshold. I did end up having a conversation with an engineer, but not surprisingly they never called back. He was also surprised and not happy that I even had the info and asked a few technical questions, likely trying to verify it authenticity.

          I ended up shelving the project when we got solar panels, as auto-start wasn’t necessary then.

  2. I’ve got a few of the in-line devices that I’m too lazy to open up and re-flash. It sounds like I just need to wait a bit longer (maybe just long enough for a few more to arrive from China…)

      1. The theory of secure firmware is very simple, but the practice is very hard. To do it well, you want to ensure that the firmware has a digital signature, that the firmware image signature is checked on each boot, and that when an update is supplied, it also has a valid signature. There should be version information in the firmware, and the device should implement anti-rollback, so that in the event of a firmware update that patches a critical vulnerability, the device will refuse to accept the previous known vulnerable version of firmware. Not doing this leaves the door open to a malicious actors flashing vulnerable code onto the device in order to then exploit it.

        All this requires a bootROM on the chip that can do the signature check before executing any other code, and somewhere secure to store the certificates that can be used to validate the signature and anti-rollback flags. The ESP8266 doesn’t have any of this. In fact, very few IoT grade SoCs have the features that are necessary to ensure they remain secure.

        You also need manufacturers to keep their private keys private, and they’re not always so good at this either.

        There is a downside to all of this though. Doing this properly locks those who’d want to tinker out of the device too. That rather means the hackaday audience wouldn’t be able to do anything with the device either. Unfortunately this is a double edged sword, as the things that allow us to tinker often also allow bad guys to do bad things.

        1. What’s the risk of allowing malicious actors to write bad firmware to one device? Unless the device is vulnerable to man in the middle attacks (like the ESP8266 famously is; that was a deal killer for me) or they control the server, flashing a device means their attack is limited to the one device they have physical access to and no more. If they control the server its game over anyway.

        2. That’s security through obscurity it only works as long as the device is relatively obscure where it’s not likely one will land in the wrong hands.
          Once you have millions of them out in the wild it’s no longer an effective tactic as too many people will be working to break it and eventually someone will find an exploit.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.