What this does
Parses a WPA/WPA2 EAPOL-Key frame from raw hex — the exact byte-level structure defined for the 4-way handshake — and identifies which of the four handshake messages it is based on its Key Information flags (Install, Key ACK, Key MIC, Secure), decoding the nonce, MIC, key length, and other fields along the way. Entirely in your browser.
Why the same field layout produces four different messages
Every EAPOL-Key frame in the 4-way handshake shares an identical byte layout — the same fields in the same order and size, always. What changes between the four messages is a specific combination of bits in one 2-byte Key Information field, plus which direction the frame travels (AP→client or client→AP) and which fields are actually meaningful at that point (Message 1's nonce is the AP's ANonce; Message 2's is the client's SNonce). Recognizing the message from its flags is exactly what packet analysis tools like Wireshark do automatically, and exactly what this tool does explicitly and visibly.
FAQ
What exactly should I paste in — a whole packet capture?
Just the EAPOL-Key frame body, starting at the Descriptor Type byte (0xFE for RSN/WPA2, 0x02 for older WPA1) — not the outer 802.11 or EAPOL header that precedes it. In Wireshark, this corresponds to the bytes starting at the "802.1X Authentication" → "Key Descriptor Type" field, which you can select and copy as hex.
Why do only four specific combinations of flags count as valid messages?
The 4-way handshake's four messages are each defined by a specific, documented combination of the Install, Key ACK, Key MIC, and Secure flags — it's how a capture tool or an implementation identifies which step of the handshake a given frame represents without needing any other context. A frame with a combination outside those four patterns either isn't part of a standard 4-way handshake, or belongs to a different EAPOL-Key exchange (like group key rotation) this tool doesn't specifically model.
Can this tool crack a WiFi password from a handshake?
No — it only decodes the frame's structure into readable fields. Actually deriving a passphrase from a captured handshake requires the MIC verification step against candidate passphrases, which needs the full 4-way exchange (specifically messages 1 and 2, which contain both nonces) and is what dedicated tools like hashcat or aircrack-ng are built for.
Why does Message 3 have both Install and Secure set, but Message 1 has neither?
Message 1 is the very first frame of the handshake — nothing has been installed or secured yet, since the client hasn't even derived its pairwise keys at that point. By Message 3, the AP has confirmed the client can compute the correct keys (via Message 2's MIC) and is now instructing the client to install the pairwise key and switch to secure communication, which is exactly what those two flags signal.
Does this tool validate the MIC to confirm the frame is authentic?
No — it decodes the MIC field's raw bytes but doesn't attempt to verify them, since that requires the derived session keys, which requires the full passphrase and both nonces. It's a structural decoder, not an authentication or cracking tool.
Try it yourself
For the full 4-way handshake exchange and why it's structured this way, see WPA2 4-Way Handshake Explained.