Live data from Hacker News

Reverse engineering ESP32 Wi-Fi driver: the road ahead

esp32-open-mac.be

51–60 of 66 posts

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

#51

Earlier quoted context omitted.

>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 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.

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

#52
post #29

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…

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

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

#53
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…

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

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

#54
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…

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

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

#55
post #29

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…

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

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

#56
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.

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

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

#57
post #29

Earlier quoted context omitted.

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…

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.

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

#58
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.

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.

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

#59
post #44
post #28

Earlier quoted context omitted.

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

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.

Post reply on HN