So you want to play with Wi-Fi? It’s dangerous to make frames alone. Take this
cybersecurity.blog.aisec.fraunhofer.de> 3.1.1 ath9k/ath9k-htc (The good Atheros)
> [...] Another major limitation of the hardware this driver supports is its limitation to 2.4GHz 802.11 b/g, with most devices also supporting n and/or draft-n.
This is wrong. ath9k is not limited to 2.4GHz. I have two dual-band ath9k cards with 5GHz support: 168c:002a (AR9280) and 168c:0030 (AR9380). Both are still available on ali.
I don't think it's wrong as much as poorly worded in that 2.4 GHz was only supposed to apply to the b/g section not be carried over past the comma. The section continues on to describe the limitations of n support which are unrelated to frequencies the hardware supports pointing out e.g. beamforming frames from ac (5 GHz only) can't be put out the radio.
Why not use dedicated hardware such as an ESP32 microcontoller?
Why not read the very first sentence of the article ?
This article aims to be the collected wisdom of everything I learned while trying to fuzz the Wi-Fi stack of Espressifs esp8266.Ok.
I might have missed something but why can’t an ESP32 or some other microcontroller be used as a hardware tool to more easily construct low level frames?
The ESP32 would still be connected to a Linux machine to control it.
I’m not a security researcher so I don’t know how this work is normally done. My simplistic take is if the OS and drivers make some of this hard I would look for a simpler environment that I had more control over.
Or it that too naive an approach?
Author here - there are two main problems with directly constructing frames on an esp: first, espressif only very recently opened up the wifi stack to a point where raw frame construction is supported and even this has some limitations on which frame types are supported. There is an, erhm, liberated API on older SDKs that supports some more frametypes, but both cannot be used to construct encrypted frames (which is kind of reasonable, I assume that encryption is done purely in hardware).
Second, the more practical limitation comes from the fuzzing objective: esps are slowwwww, and the testcase throughput is abysmal; especially if you factor in that the firmware is essentially a black box and the usual coverage-guidance used in modern fuzzing simply does not work on a device that constrained.
So yeah - constructing frames on the esp would be the smart thing to do, figuring out how to do this efficiently (and fully automated) is however not trivial at all. FWIW, hooking the board up to a computer via serial is also not enough, the fuzzer needs some way to hard reset devices (that is, pull the reset pin to ground or powercycle or both). We use some extra microcontrollers we had lying around for that, however we needed to make some custom PCBs to make that work reliable.
Edit: also, to clarify, the esp8266 is even more limited than the esp32. There is no officially supported way to construct raw frames on the 8266, and in/out connections other than wifi are limited to fairly low speed UART (no JTAG, etc..).
Thanks. That makes a lots of sense.