Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reverse engineering ESP32 Wi-Fi driver: the road ahead

esp32-open-mac.be

Post reply on HN
Print view View original

31–40 of 66 posts

Re: Reverse engineering ESP32 Wi-Fi driver: the road ahead

#31

Post by [deleted] »

jononor wrote: post #29
echoangle wrote: post #20

Earlier quoted context omitted.

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

[deleted]

Re: Reverse engineering ESP32 Wi-Fi driver: the road ahead

#32

Post by janice1999 »

robert_foss wrote: post #23
jononor wrote: post #2

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

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.

Re: Reverse engineering ESP32 Wi-Fi driver: the road ahead

#33

Post by linuxlizard »

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…

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.

Re: Reverse engineering ESP32 Wi-Fi driver: the road ahead

#34

Post by toast0 »

Rinzler89 wrote: post #24
rfoo wrote: post #18

Earlier quoted context omitted.

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

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.

Re: Reverse engineering ESP32 Wi-Fi driver: the road ahead

#36

Post by yjftsjthsd-h »

opengears wrote: post #16

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

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.

Re: Reverse engineering ESP32 Wi-Fi driver: the road ahead

#37

Post by utensil4778 »

opengears wrote: post #16

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.

Re: Reverse engineering ESP32 Wi-Fi driver: the road ahead

#38

Post by hildenae »

margorczynski wrote: post #35

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.

Re: Reverse engineering ESP32 Wi-Fi driver: the road ahead

#39

Post by hildenae »

mschuster91 wrote: post #8
pelorat wrote: post #6

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.

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?

Re: Reverse engineering ESP32 Wi-Fi driver: the road ahead

#40

Post by echoangle »

iamflimflam1 wrote: post #22
perbu wrote: post #21

Earlier quoted context omitted.

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

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.
Post reply on HN