What this tool does
Builds a single line in hashcat's -m 22000 (WPA-PBKDF2-PMKID+EAPOL) format from a captured PMKID or a captured 4-way handshake — the format hashcat expects in a .hc22000 file for cracking a WPA/WPA2 passphrase.
Why the EAPOL field needs more than the key descriptor
EAPOL Handshake Decoder expects input starting at the key descriptor type byte. This tool expects 4 bytes more before that — the true 802.1X header (protocol version, type, length) — because that header is part of what the MIC is computed over. Leaving it out, or guessing those bytes, would produce a hash line that looks plausible but silently fails to crack against the real passphrase.
Why the MIC is zeroed inside the EAPOL field
The hash line carries the real captured MIC in its own field — but inside the EAPOL frame bytes that follow it, those same 16 bytes are zeroed out. That's intentional: hashcat recomputes a candidate MIC over the frame for each password it tries and compares it against the real one stored separately. If the real MIC were left in place inside the frame too, there'd be nothing to compare against.
Where Message 1 and Message 2 each contribute
A PMKID needs no handshake at all — it's a single value an AP sometimes sends unprompted. A full handshake needs two messages because the fields come from different places: ANonce is generated by the AP and only appears in Message 1, while the MIC and the raw EAPOL frame bytes come from Message 2 — the first message in the exchange the client actually signs.
FAQ
What if I only have a PMKID, not a full handshake?
Use the PMKID mode — it only needs the PMKID value itself plus the AP/client MAC addresses and ESSID, no handshake messages required.
Does this support WPA3 or SAE captures?
No — this covers the classic WPA/WPA2 4-way handshake and PMKID path only (message pair M1+M2). WPA3's SAE exchange is a different protocol; see WPA2 vs WPA3 Security Explained for why.
Is my data uploaded anywhere?
No — everything happens entirely in your browser. Nothing is sent to a server.