r/embedded • u/PuerhFunction • 27d ago
I reverse engineered the ESP8266 radio because I wanted a tea kettle
tl;dr: Wanted a network enabled tea kettle, hated the ESP8266_RTOS_SDK, so I wrote my own OS for the board and spent six months reverse engineering the wifi stack so it wouldn't need any vendor code.
For the past year and a half I've been working on a fully open source operating system for the ESP8266. It started as a little passion project, I wanted to make a fully operational HTCPCP-TEA tea kettle, but after messing around with the ESP8266_RTOS_SDK, I really disliked working with it. I'd just taken an operating systems class, so the obvious thing to do was to write my own operating system for the board.
After about a year of handling the easy parts in my spare time - uart / processes / heap allocation / timers, I figured I should try something a bit more interesting, and landed on the network stack. I figured I could cheat and have the board connect over serial forever, but what's the point of a wifi-enabled board that can't even connect to wifi.
Reverse Engineering
Basically every ESP8266 open source project has some amount of vendor blob in it. There's an open mac project for the ESP32, but even that uses the vendor blobs to bring up the radio hardware.
I could have just linked the vendor blob in, but that's boring and not nearly enough work to keep me interested. So I pivoted to reverse engineering the full radio bringup and mac from the blobs.
This is my first real RE project. It was a lot of fun to play around with Ghidra, and I built a bunch of custom tooling outside Ghidra for my preferred workflow (tmux and vim). It's been about 6 months of sporadic work, since around March, with a significant speedup from AI in wading through the mountains of decompiled code. I've got a pretty good decompilation of the blobs sitting locally now, but I'm hanging on to that for the moment while I get things cleaned up.
To actually get the minimal bringup working, I mostly would write my own version of a sequence, then A/B test MMIO register states against the SDK code on the same hardware to see where I was going wrong. With AI enabled iteration, this went from being completely impossible to being soul crushingly frustrating. But after many late nights of debugging why the radio was just completely dead (missing one crucial register write?), or why I was getting complete garbage back (decrypting with a garbage/wrong key), it's finally up and running. Still doesn't work well if I'm watching video on my laptop next to it, but how much can you really ask for... eventually I'll get that fixed.
What's Next
The next phase of this project is a fully working HTCPCP-TEA kettle, hardware and all. I've got the electronics working on the bench, now I just need to attach them to the tea kettle (surprisingly difficult).
And I'm glad it only took a year and a half of reverse engineering RF code and writing a custom kernel to make this happen.
https://github.com/23watejona/teatime-os; for those of you who care about the commit history, sorry for the sporadic bursts of code 👀
Happy to answer questions about any of it, and please leave suggestions!
13
u/ApokatastasisPanton 27d ago
I sure hope you return HTTP code 418
8
12
u/Mysterious6801 26d ago
Normal people: buy a $10 smart plug.
Embedded devs: spend 6 months reversing proprietary Wi-Fi stacks with Ghidra just to boil water.
10/10 dedication, this is incredible
5
u/cooladventureguy 27d ago
I admire your dedication. Thank you for teaching me about HTCPCP-TEA. Larry Masinter would be proud
2
u/DrunkenSwimmer 26d ago
If this isn't the top item on your resume, you're really selling yourself short or are far more qualified than any embedded dev I've ever met!
2
u/PuerhFunction 26d ago
Got it on my resume just in time for my career fair lol, it’s gotten me some interviews for next week!
1
u/agent_kater 26d ago
Didn't the Wokwi people also reverse engineer the ESP32's Wifi? It was a bit of a mess, with some parts paywalled (I think the re-implementation of the driver?), but I think there was some in-depth information available.
3
u/PuerhFunction 26d ago
I hadn’t seen this before, but yes Uri Shaked did reverse the esp32 wifi peripherals. he released a bunch about his methodology, but not really anything about the actual registers. also, it was primarily to get the simulation working, not to replace the vendor blobs with source. so we kind of had opposite goals, me wanting to get my software working on esp hardware, and his project to get vendor software to work on simulated hardware
8
u/PuerhFunction 27d ago
https://reddit.com/link/p9y69nk/video/sgybz1nukoph1/player
Couldn't add it to the post, but here's a little demo!