Hacker News new | past | comments | ask | show | jobs | submit login
Reverse engineering ESP32 Wi-Fi driver: the road ahead (esp32-open-mac.be)
192 points by redfast00 39 days ago | hide | past | favorite | 63 comments



Very cool project. I think efforts like these are among the most promising to get a FOSS WiFi cards. Because these WiFi-capable MCUs are: designed to be generally programmable, have quite a lot of open documentation, are available for purchase in both small and large quantities, have s availability over long time-frames (10 years), can tap into the larger community knowledge-base. This is in contrast to the more specialized chips that dedicated WiFi cards use.


The ESP32 is 802.11n over 2.4ghz with no MIMO, so the bandwidth will always be bad.


They're popular in battery powered IOT type devices where BW is not a huge concern.


If you want bandwidth on an ESP32z you've chosen the wrong hardware in all senses.

If you were referring to the intricacies of the driver and how it might apply elsewhere, that's fair.


What would the performance be like though? Would you want to use a ESP32 for watching Videos? Would that be doable?


Not great by modern standards... The standard ESP32 supports 802.11n, but only 2.4 GHz (not 5). So theoretical rates maybe up to 40-50 Mbps. In tests that I have seen people do on ESP32 they have reported practical speeds of 5-10 Mbps. Which is basically just in the typical range for Full HD video.

The ESP32-C6 has WiFi 6 support and 5 GHz, so theoretically that can be order of magnitude faster. But it might have completely different hardware and require separate reverse engineering. And practical speeds will still be limited compared to dedicated WiFi hardware.


ESP32-C6 does not have 5GHz, only WiFi 6 at 2.4GHz.. ESP32-C5 has 5GHz but its still in beta :)


I mean that's plenty for an esp. if you have a data intensive use you should pick a different platform.


Agreed. What would you even do with 50Mb/s on an ESP32? That would be a TON of telemetry, or you'd have to be trying to network proxy or something.


I know its not exactly what you mean but here is video download, decoding, and video signal generation on a bare esp32 (no Graphical chip) : https://github.com/rossumur/espflix


You can do that today with the closed source wifi driver. This is not something limited by the wifi performance.

Note that neither the framerate not resolution would be something to write home about. We're talking abot an aging MCU here.


It’s a dual core MCU that runs at around 240MHz.

One of the main limitation tends to be to be around pushing pixels to the screen - most displays are serial (SPI) based which tops out at 80Mhz.

The other limitation is a lack of hardware video decoding. Some of the latest ESP32 chips are RISCV based and have SIMD instructions which can improve decode performance.

But if you pick an easy to decode codec (MJPEG) is popular. The you can get decent performance with the size of displays available.

https://youtu.be/2NLblyCvJBU?si=_c-ycaS4cNZEJBaD


I understood the parent coment as wanting to build a WIFI card, i. e. the ESP32 connects to the WIFI and transfers the data to a connected computer over PCIe or so. The ESP32 would have to do no decoding of the payload, only transfer the packets to the PC.


Ah, makes more sense.


What do you mean by FOSS Wi-Fi cards? Aren't there lots of open source drivers for Wi-Fi cards?


While many wifi cards have open driver interfaces they still have closed basebands (the software that actually drives the RF hardware) this is usually done for a combination of intellectual property and regulatory reasons. That is, they get to keep their secrets and the user can't make the radio do something it's not licensed to do.

These devs are aiming to open up the baseband of the ESP32 which allow for all kinds of interesting hacks, and probably all kinds of opportunities to run afoul of your countries laws regard spectrum use.

I do foresee some cases not entirely unlike the Flipper Zero arising from this but still wholeheartedly support it.


You can already do those interesting hacks with some electrical engineering knowledge.

What this is going to allow is what Flipper Zero did: allow you to do something that was already possible but now it only costs money instead of requiring education.


This is about ESP32, it does not run Linux. And doesn’t have a WiFi card, the WiFi hardware is part of the MCU. It’s single processor is tasked with running both the user application as well as the 'baseband' or MAC layer


With it reverse engineered, you could write software for the ESP32 to have it become the only fully open WiFi card for a Linux host.


They're talking about open-source firmware, I would guess.


Exactly. And if that is managed, perhaps the codebase can be further adapted on the future to actually open hardware.


There are no newer-than-803.11n cards that are usable with a Linux-libre kernel (which doesn't load binary blobs).


The whole "no binary blob" argument has always felt very arbitrary to me.

Everyone seems fine with read-only firmware permanently burned into chips during production. It is part of the hardware, so it would be silly to treat it like software. Most people seem fine with firmware stored on in-device flash chips. It's basically the same story as before, only it might in some cases be able to update that firmware.

But then you get to devices which store their firmware in-memory and it's suddenly a problem - even if it's exactly the same software the device would otherwise be loading from a ROM area or flash chip. Why the sudden shift? And then there are even people who are fine with their CPU executing its burned-in microcode, but updating that very same microcode with a blob during bootup is suddenly a deadly sin? I just don't get it.

I get the appeal of a system which only runs open-source code and which is provably free of any kind of backdoors or restrictions, but that fight was already lost when Intel's 8086 and Motorola's 68k entered the market. I don't think there has ever been a truly "free" computer which wasn't a toy project, so why intentionally kneecap your daily compute experience?


If someone sells me a device with some firmware on it, they presumably had acquired a transferable license for that software. They then transferred it to me on sale. When I bought a used pickup truck, I did not need Ford to sell me a new license for the engine control unit.

If I buy a piece of hardware that has absolutely zero software on it, then I have to go get a license from someone else to use hardware that I "own". Even though in the case of a WiFi card that piece of hardware is purpose built and has exactly one single function.


The proponents of open firmware and open hardware that I know consider built-in firmware as bad-but-slightly-better-than-updatable. Slight better because it is theoretically easier to validate, as one does not need to take into account firmware updates when doing so. But still something that is ideally avoided.

Yes, the struggle for libre hardware has generally been a losing one. But electronic devices are just getting more and more important, so it is just as important a mission as ever.


We are not fine with any proprietary firmware or hardware, but we have to be realistic, use the hardware we have and open up as many layers as we can, one step at a time.


For me, the distinction is simple.

Binary blobs in software are incompatible with the GPL, and can't be included in the Linux kernel.

Binary blobs in firmware, meanwhile, can exist entirely on the hardware. There isn't any licensing issue because there is nothing to license.

(And, sure. That's an incomplete solution if truly libre hardware is the goal.

But we humans accept and deal with incompetent solutions all the time in every aspect of life, and I'm not willing to die on this particular hill.)


Autoderp: "incompetent" was supposed to be "incomplete"


I wonder if they use any of the decompiler tools that are available. There is decompiler support for the Xtensa esp32 instruction in ghidra version 11.0. I also guess that rev.ng, which uses QEMU as its disassembler, could be used for decompiling as QEMU has support for the Xtensa esp32 instructions as well.

My experience with decompilers is that are not 100% perfect and that the output often still needs a lot of clean-up. I tried rev.ng on a binary written in assembler that used a register based calling convention (not stack based) and rev.ng produced a huge file many times the size you would expect from the assembler input. It seems that decompiler can only do the most trivial step of the reverse engineering process.


Decompiling the microcode blob might run afoul of intellectual property laws. A clean room implementation needs to be done without reading any of the product's actual code.


Clean room design [1] comes down to one team reverse engineering the code and translate that to some high-level specification and let another team write the code based on that high-level specification. This still allows the use of a decompiler by the first team.

[1] https://en.wikipedia.org/wiki/Clean_room_design


Even printing the call stack as they are doing is already very risky; some judges may argue that this is not strictly necessary.


One of the posts mentioned they use Ghidra and Qemu forks for their work.


All the newer ESP32 MCUs are RISC-V based if that may help


Interesting. 53286 accesses is a lot, I wonder if some of this is writing firmware to another processor, or writing a table. Some may also be busy waiting on status bits.

It would be interesting to see what the minimal subset of the 53286 is, which can be automated using the Delta Debugging algorithm, but it would first be necessary to figure out if there were any necessary waits during the writing process. Also blindly deleting stuff may produce a system that, even if it works, isn't a good citizen of the RF spectrum.


It baffles me that a company like espressif wouldn’t publish complete API specs of their radio hardware . I could see why they may not want their proprietary source out there, as it might make it easier for competitors to make similar chips, but what is the downside to enabling someone to write software particular to your hardware?

It seems like they would have everything to gain and nothing to lose from this?

Anyone shed any light on the motivations here?


Really often that's because they license it from a third party and they are not allowed to.


Bingo :)


Does a FOSS wifi driver for esp8266 already exist or is it in the making?


They are working on it, the post is about what they still have to do.


The post is about esp32.


I need _Bluetooth_ OBEX support on ESP32 and Espressif's standard lib doesn't provide it. Is this project going to look at issues like these too?


The BT stack is based on Bluedroid, so that’s open source (up to the driver I’d guess); see here https://github.com/espressif/esp-idf/tree/master/components/...


Some other examples of open WiFi firmware here:

https://wiki.debian.org/Firmware/Open


Does this mean we could get open source (hardware) WiFi cards for our Linux Notebooks based on ESP32 in the future?


No, and you don't want that in the first place. With an ESP32 you'd be pretty lucky to get more than 10 or 20mbps in ideal conditions. It's also 2.4GHz only.


Depends on what you mean? The ESP32 isn't open hardware, so on that front, no. But could this potentially let you make an open source card that used the ESP32, absolutely. In fact, you can do that already, it'll just be using some closed source firmware. And replacing that firmware with FOSS is what this is about.


So this appears to be a clean reversing effort, for what - legal reasons?

Espressif Systems is a Chinese company and probably stole half the code in the firmware anyways. No one will blame you if you stick the stick the firmware in Ghidra.


First paragraph:

"This will enable features that the current, closed source ESP32 Wi-Fi implementation does not have, for example 802.11s mesh networking. It will also improve the auditability of the code."


Mesh is such a cool technology that seems to be reserved to high end HW, and bringing it to ESP32 would be amazing!


>Espressif Systems is a Chinese company and probably stole half the code in the firmware anyways.

So if an entity is Chinese we are sure they are thiefs.


The thing is, China as a culture does have a completely different attitude towards intellectual property. For them, copying is not theft, it's acknowledge of something's quality. Andrew "bunnie" Huang has written (at least) two articles with more details [1][2].

[1] https://www.bunniestudios.com/blog/2014/from-gongkai-to-open...

[2] https://www.bunniestudios.com/blog/2013/the-12-gongkai-phone...


> copying is not theft, it's acknowledge of something's quality

This is a common misconception. It is true that they don't think it is theft once it's widely available (even in underground community), but it's not because "copying is acknowledge of something's quality". This is one of the usual excuses.

A better phrasing would be: modern (post-1980s) Chinese people [1] care more about who is able to build the thing, not who is able to invent / design. They happily (and knowingly) steal your design and after a few iterations build it better and think it's totally legit because you failed to prevent them from stealing your design and you also can't build it better.

And the annoying part is, turns out, after copying all they can steal they surprisingly can invent, too.

[1] It's not yet a culture


Isn't this exactly the MO of post-war Japanese industry? Copy everything from the west for the local market, then improve and make it better and cheaper then seel it in their market for profits?


Also the MO of early US industrialism. Copy everything from the UK and Europe, make it better and cheaper, apply it to local conditions, etc, etc. Only start supporting international patents when you've got lots of patents that warrant protection.


See also: Nintendo and IP protection.


Copying isn't theft (though it may still be illegal). Theft is "dishonest appropriation of property belonging to another with the intention to permanently deprive the other of it."

So if I steal your wallet, your phone or your car that's theft because you no longer have access to it and I do.

If I copy a book, a CD, a DVD, a document or a chip the original owner still has it. That doesn't mean there's no prejudice or that it's legal but it's not theft.


The people they copied it from would.


If you got enough (wo)manpower you can also do a cleanroom RE using a decompiler - one team decompiles and writes documentation about how the chip works, the second team writes a driver based on that doc.


Does this way to write an implementation have a name?


Chinese wall


Have you tried utilizing a strong LLM like ChatGPT or Claude to help you out? I've seen some really interesting examples of using it to decompile code to a very readable format.


As other comments have mentioned - they do not want to decompile the source, they want a clean-room-implementation.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: