At the 38th Chaos Communications Congress, [Frostie314159] and [Jasper Devreker] gave us a nice update on their project to write an open-source WiFi stack for the ESP32. If you’re interested in the ESP32 or WiFi in general, they’ve also got a nice deep dive into how that all works.
On the ESP32, there’s a radio, demodulator, and a media access controller (MAC) that takes care of the lowest-level, timing-critical bits of the WiFi protocol. The firmware that drives the MAC hardware is a licensed blob, and while the API or this blob is well documented — that’s how we all write software that uses WiFi after all — it’s limited in what it lets us do. If the MAC driver firmware were more flexible, we could do a lot more with the WiFi, from AirDrop clones to custom mesh modes.
The talk starts with [Jasper] detailing how he reverse engineered a lot of Espressif’s MAC firmware. It involved Ghidra, a Faraday cage, and a lucky find of the function names in the blob. [Frostie] then got to work writing the MAC driver that he calls Ferris-on-Air. Right now, it’s limited to normal old station mode, but it’s definite proof that this line of work can bear fruit.
This is clearly work in progress — they’ve only been at this for about a year now — but we’ll be keeping our eyes on it. The promise of the ESP32, and its related family of chips, being useful as a more general purpose WiFi hacking tool is huge.
Anyone see contact other than matrix? I.e. a github, IRC? I’d be interested in reaching out to these folks, but matrix is such a pain. Well, mostly I’m interested in finding out what their code looks like.
There you go : https://github.com/esp32-open-mac/, done in Rust.
I was present at the presentation. Great work but a lot remains to be done.
Bummer. Rust makes it kinda useless for the two groups that were basically begging for something like this :-/.
It looks like a lot of the core is in C, so maybe something is workable.
Hi, while the MAC stack I work one is written in Rust, we also have a driver written in C, which we’ll expand in the future, that allows raw TX and RX and can be used for implementing protocols as well.
The swadgefolk just need basically the broadcast-style ESP-NOW, that’s what I saw so I think it will work.
I’m pretty sure that the reverse engineering will be applicable to other languages. Maybe for the blobs, a static recompilation circa Ocrina of time or Touhou 1?
https://github.com/esp32-open-mac/esp32-open-mac/commit/3405d26e4c64a3395ccfb91b8e9e3e65c4d299e0 is link from a blog post of theirs. Probably close to where you need to be?
I’d settle for being able to use all legal ESSIDs and passwords. I don’t remember which one was the problem, but I ended up having to create a whole separate ESS so that devices running Espressif’s crappy stack could get onto my network.
Uh, the Pico doesn’t have wifi? (Pico-W doesn’t count, that uses a separate wifi module).
Is it possible for you to cram more jingoistic buzzwords in your comment?
The Pico-W also uses a software stack that isn’t open source. It just comes with a license that allows you to use it on the RP2040, so if you take that board design, swap the RP2040 with the new RP2350 and use the wifi you violate the license.
Why start with the esp32? Tjt doesn’t make sense to me. Why not start with the esp8266 working in the nonos sdk, and then once that’s working port to the esp32?
Because the ESP32 is actually relevant.
The esp32 has more runway left than the 8266. In that it will likely be supported longer and the authors work will be useful longer. Also afaik the WiFi in the esp32s2/s3 cores is reasonably close to the esp32
This could be huge if it gives us cheaper WifiBroadcast hardware for drones and such…