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.
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.
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?
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.
"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."
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.
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.
jononor|1 year ago
robert_foss|1 year ago
echoangle|1 year ago
DeathArrow|1 year ago
fjfaase|1 year ago
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.
linuxlizard|1 year ago
pabs3|1 year ago
pantalaimon|1 year ago
ajb|1 year ago
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.
K0balt|1 year ago
It seems like they would have everything to gain and nothing to lose from this?
Anyone shed any light on the motivations here?
ta988|1 year ago
jesprenj|1 year ago
pabs3|1 year ago
SillyUsername|1 year ago
05|1 year ago
pabs3|1 year ago
https://wiki.debian.org/Firmware/Open
opengears|1 year ago
utensil4778|1 year ago
yjftsjthsd-h|1 year ago
rhadware|1 year ago
[deleted]
pelorat|1 year ago
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.
tecleandor|1 year ago
"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."
DeathArrow|1 year ago
So if an entity is Chinese we are sure they are thiefs.
ZiiS|1 year ago
mschuster91|1 year ago
margorczynski|1 year ago
hildenae|1 year ago