Reverse engineering ESP32 Wi-Fi driver: the road ahead
esp32-open-mac.be
esp32-open-mac.be
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.
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.
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?
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.
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.)
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.
Note that neither the framerate not resolution would be something to write home about. We're talking abot an aging MCU here.
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.
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.
If you were referring to the intricacies of the driver and how it might apply elsewhere, that's fair.
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.
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 seems like they would have everything to gain and nothing to lose from this?
Anyone shed any light on the motivations here?
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.
So if an entity is Chinese we are sure they are thiefs.
[1] https://www.bunniestudios.com/blog/2014/from-gongkai-to-open...
[2] https://www.bunniestudios.com/blog/2013/the-12-gongkai-phone...
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
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.
"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."