ESP8089 driver firmware blob

[CRImier]

We're using the esp8089 driver that makes use of the ESP-12 on the ZP front board, turning it into a WiFi card (that is connected through SDIO). This driver loads a binary blob into the ESP-12 (through SDIO), the blob then runs on the ESP CPU, handles the low-level WiFi details and talks to the driver through SDIO. Unfortunately, the sources for the binary blob aren't available - likely because of the Espressif's policy on not exposing the low-level WiFi API in order to prevent their public perception from being tarnished when people use Espressif hardware for malicious purposes, + possible patent issues [1].

[1]:

Q from @dreamer : Will Espressif ever get rid of the binary blobs still needed
to use the ESP series?
We would like to see FrostedOS on the esp32, but since this needs fully open
kernel space it's currently not possible.

Sophi: lots of questions about the binary blobs!

Sprite_tm: 'Ever' is a long time... and in general this has been a pretty hard
issue here, as I do think I have some influence on the company direction here.
On the one hand, I'm all for open stuff, as much as possible, yes please!

Sophi: here's another about the blob from @Arsenijs : I've been discussing usage
of ESP8266 as a SDIO WiFi card with people in the DIY smartphone community
(specifically, in regards to the ZeroPhone project, but there are other projects
I know of that currently use SDIO WiFi cards and considered replacements).
There's always a question - what about the binary blob uploaded by the driver?
Speaking mainly about this:
https://github.com/al177/esp8089/blob/master/eagle_fw1.h, as well as the
corresponding .fw2 and .fw3 files.

Are there sources? We haven't managed to find any yet. We've considered putting
a bounty on reverse-engineering the blob, so that we have a WiFi card we can use
internally for people that want to have an open-firmware driven WiFi card, with
all the benefits it brings. However, if the sources could be made accessible,
that'd be awesome. Is there anything we could do about it?

Dreamer: @Sprite_tm yeah I guess "someday maybe" is an answer. but what are the
main motivations to keep these parts closed?

Sprite_tm: On the other hand, there are some risks involved. Especially with the
WiFi stuff: what if your WiFi hardware can actually do much more than the binary
blobs normally allow? We've already seen people make disassociation throwies
with the ESP8266. What if people can disrupt more communications because you
opened up the interface to hardware that allows more than is legally allowed?
You can get stuff like the FCC all of a sudden requiring all WiFi firmware to be
signed so no one can mess around with it.

[...]

Thomas Shaddack: in the age of software-defined radios, do such restrictions
make sense at all?

[...]

Sprite_tm: Also, there are more down-to-earth issues. For instance, we're pretty
sure we have all our patent stuff covered, but what if there's something
patented we've missed, hidden deep in the WiFi hardware? Seeing the bits that
control it directly would make it way more visible. To make it open anyway is a
choice we can make, but I'm just saying it is not entirely consequence-free.

[...]

Arsenijs: Avoiding exposure of patented stuff does make sense, of course

[...]

Arsenijs: But there are already open-firmware WiFi cards (just USB, not WiFi)

[...]

Arsenijs: And the ESP8266 deauth stuff hasn't exactly died down - people just
use the old SDK, it's still possible to do so; and yet ESP8266 is popular as
ever

Sprite_tm: True, but you have to keep the practical in view as well. A SDR still
is pretty expensive, and GnuRadio is all but user-friendly to the newb. When you
can grab an ESP32 devboard for $5, blow some disrupt-everything firmware
inthere, add 2 AAs and hide it somewhere at school/work/..., we all of a sudden
are known as the company that makes those chips that kill your WiFi and endanger
people because they can't call 911 on their WiFi phone.

Sprite_tm :Arsenijs: Exactly, once the ghost is out of the bottle, you can't put
it back again. And that is why we are so hesitant to open-source the drivers.

[...]

1rabbit says:11:10 AM
tbh if you want to do evil stuff the blobs wont stop you

Sprite_tm says:11:11 AM
Thomas: As soon as there's a chip near our price range that has the interface to
the HW entirely open (and given the interface to the HW is as capable as ours),
I'll start advocating to open it up within our company without a thought.

Taken from the ESP Everything HackChat transcript, part 2.

[CRImier]

Questions are:

1. How can we free ourselves from the dangerous consequences of this blob?
   a. not knowing what it actually does
   b. being unable to patch vulnerabilities
   c. being unable to add security-related features (such as MAC address randomization while scanning for networks)
2. If the answer is reverse-engineering, what's the best way to do it? Which documentation/resources can we use?
3. What are the workarounds we can provide?

About workarounds, the main workarounds I currently see are:

1. Using a USB-WiFi card, of those that have open firmware available (as a host-mode USB ports is available on the ZeroPhone)
2. Using another SDIO WiFi chip (designing a pin-compatible module around it) that has an open firmware available
3. Not using the WiFi connectivity (and the module/blob), dropping it altogether
4. Using other kind of connectivity as the main network connection (wired/wireless)

For now, the ZeroPhone project will still use the hardware/software as it is (since it's so far the best solution for getting WiFi with a low cost), but will seek solutions and investigate workarounds.

[NavidMitchell]

There is this if the ESP was switched to the ESP32. https://github.com/espressif/esp-hosted However it still uses the ESP-IDF which is closed source. But at least the ESP code is available.