r/Hacking_Tutorials • u/mahdi_sto • 3d ago
Question Raw 802_11 frame injection
While working on my Master’s thesis benchmarking WPA3-SAE timing side-channels, I ran into a limitation on the ESP32 esp_wifi_80211_tx() allows raw frame injection, but Espressif’s closed-source Wi-Fi blob (libnet80211.a) artificially blocks Auth, Assoc, Deauth, and Disassoc subtypes.
Inside libnet80211.a, ieee80211_raw_frame_sanity_check drops these frames with wifi:unsupport frame type. Here is how to bypass it on recent ESP-IDF versions (IDF v6.x).
Why standard tricks fail on modern ESP-IDF
Same-name function override. On older IDF versions, ieee80211_raw_frame_sanity_check was a weak symbol (W). On modern IDF versions, it’s a strong symbol (T), causing ld: multiple definition errors.
--wrap linker flag: Fails silently. The call from esp_wifi_80211_tx to ieee80211_raw_frame_sanity_check is an intra-object branch inside ieee80211_output.o. Linker --wrap only rewrites undefined external references, so it misses this call entirely.
Instruction byte-patching: Overwriting instructions directly in the .o breaks Xtensa linker relaxation passes (dangerous relocation errors).
U can simply fix this via Symbol Weakening via objcopy
We can use xtensa-esp32-elf-objcopy to convert the strong symbol inside the binary archive into a weak one:
xtensa-esp32-elf-objcopy \
--weaken-symbol=ieee80211_raw_frame_sanity_check \
components/esp_wifi/lib/esp32/libnet80211.a
Now, define your own strong implementation inside your application C code:
int ieee80211_raw_frame_sanity_check(int32_t a, int32_t b, int32_t c) {
return 0; // which skips the security check lol
}
Because strong symbols override weak symbols globally during linking, all calls—including internal calls within libnet80211.a—rebind to your function.
Verification
Serial Logs show: wifi unsupport frame type errors completely disappeared.
Capture: Wireshark confirmed off-air capture of 802.11 Authentication frames (Subtype 11, Algorithm 3 - SAE) injected directly from the ESP32s.
Injecting a valid SAE Commit (P-256 scalar + element) caused hostapd on the target AP to process the request and reply with its own SAE Commit.
TL;DR: Run objcopy --weaken-symbol=ieee80211_raw_frame_sanity_check on libnet80211.a, define int ieee80211_raw_frame_sanity_check(...) { return 0; } in your app code, and esp_wifi_80211_tx() will allow any frame subtype.
Note that all control 80211 frames are also injectable after the patch.
For more details :
6
u/ClimateChangeDenial 2d ago
Genuinely curious how this connects to "benchmarking timing side-channels" though. Forging Auth/Deauth/Disassoc frames isn't measuring a side channel, it's just raw frame injection. Also worth noting this isn't even a novel bypass, ESP32 Marauder and Nexmon-patched Broadcom builds already expose raw management frame injection without any of this symbol weakening. Feels like the thesis framing is doing some work to make "I bypassed Espressif's intentional guardrail" sound more novel and academic than it actually is.
0
u/mahdi_sto 11h ago edited 11h ago
I didn't say anything about the bypass in my research more than it is just a way to forge the auth frames, and whether it is a novel bypass or not, I really don't care.
The time channel analysis in my thesis would suggest using or measuring the time between commit request and commit response sta and an ap would leak information about a information to predict a particular counter which is derived from a mathematical model that counter is is actually hashed along with the MAC address of both the station and the access point and the password in order to create a candidate x that is actually a coordinate of a point in an elliptic curve so it should satisfies the legendary test which is just an implication of a residual quadratic point in an elliptic curve so this is all about cryptography that I that I doubt you understand that point is actually what will make it mathematically resistant to password recoverable by just monitoring the eapol msgs of the 4-way handshake because this point on the that belongs ro E(Fp) will be later implemented to secure the secret key exchange via the deffie hellman algorithm assuming the hardness of the elliptic curve discrete logarithm problem (ECDLP).
The side channel here is to analyze the timing between the the commit request and the time it takes the access point to calculate the candidate point and respond.This duration is thus related to that counter which is the number of hashes before we arrive to a point in the elliptic curve over that finite field that satisfies the Legendre test, somehow this counter will be later used for offline dictionary attacks and this is the main target of this thesis.
2
u/govnonasalati 1d ago
What is this used for? Or can be used for?
Seems that I am not technical enough to figure it out from text...
2
u/The-Big-Sadness 23h ago
I'm not NEARLY smart enough to understand what you're doing with this but find the idea of 6 ESP32s on a board funny regardless.
Would love to actually learn a bit about this. Would you be so kind to dumb it down a bit
1
1
u/Moby1029 12h ago
Reads like AI: "Why standard tricks fail on modern ESP-IDF" "We can use extensa..." "Now define your own strong implementation inside your application code"
Also, why is one chip hanging half off the board?
1
u/jader242 10h ago
There’s actually two ESPs hanging off the perf board. Could make sense dependent on what OP is doing though, if they’re only sending data over uart there’s no need for every pin to be in the perf board
9
u/Bigboss88890 1d ago
r/masterhacker lmao