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

41–50 of 66 posts

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

#41

Post by treflop »

MadnessASAP wrote: post #26
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?

While many wifi cards have open driver interfaces they still have closed basebands (the software that actually drives the RF hardware) this is usually done for a combination of intellectual property and regulatory reasons. That is, they get to keep their secrets and the user can't make the radio do something it's not licensed to do. These devs are aiming to open up the baseband of the ESP32 which allow for all kinds…

You can already do those interesting hacks with some electrical engineering knowledge.

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.

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

#42

Post by iamflimflam1 »

echoangle wrote: post #40
iamflimflam1 wrote: post #22

Earlier quoted context omitted.

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.

Ah, makes more sense.

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

#43

Post by ctz »

hildenae wrote: post #39
mschuster91 wrote: post #8

Earlier quoted context omitted.

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?

Chinese wall

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

#44

Post by crote »

LukeShu wrote: post #28
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?

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

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

#45

Post by lostemptations5 »

ta988 wrote: post #27
K0balt wrote: post #25

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? Anyone…

Really often that's because they license it from a third party and they are not allowed to.

Bingo :)

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

#46

Post by jononor »

crote wrote: post #44
LukeShu wrote: 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…

The proponents of open firmware and open hardware that I know consider built-in firmware as bad-but-slightly-better-than-updatable. Slight better because it is theoretically easier to validate, as one does not need to take into account firmware updates when doing so. But still something that is ideally avoided.

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.

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

#47

Post by AshamedCaptain »

linuxlizard wrote: post #33
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.

Even printing the call stack as they are doing is already very risky; some judges may argue that this is not strictly necessary.

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

#48

Post by makapuf »

echoangle wrote: post #20
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…

What would the performance be like though? Would you want to use a ESP32 for watching Videos? Would that be doable?

I know its not exactly what you mean but here is video download, decoding, and video signal generation on a bare esp32 (no Graphical chip) : https://github.com/rossumur/espflix

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

#49

Post by makapuf »

toast0 wrote: post #34
Rinzler89 wrote: post #24

Earlier quoted context omitted.

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.

See also: Nintendo and IP protection.

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

#50

Post by ssl-3 »

crote wrote: post #44
LukeShu wrote: 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…

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 time in every aspect of life, and I'm not willing to die on this particular hill.)

Post reply on HN