Reverse engineering ESP32 Wi-Fi driver: the road ahead

Post by pabs3 » Sun, May 26, 2024, 1:43 AM UTC

fjfaase wrote: post #19

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 cle…

Post by ssl-3 » Sun, May 26, 2024, 7:45 AM UTC

ssl-3 wrote: post #50

crote wrote: post #44

Earlier quoted context omitted.

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 th…

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…

Post by jdiff » Mon, May 27, 2024, 11:49 AM UTC

pantalaimon wrote: post #53

DeathArrow wrote: post #9

Earlier quoted context omitted.

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

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