Tutorial: WPA Packet Capture Explained

Version: 1.05 December 15, 2009
By: darkAudax

Files linked to this tutorial: wpa.full.cap wpa.bad.passpharse.cap

This is quick and dirty explanation of two sample WPA capture files. The first file (wpa.full.cap) is a capture of a successful wireless client WPA connection to an access point. The second file (wpa.bad.key.cap) is a capture of a wireless client attempting to use the wrong passphrase to connect to the AP.

This tutorial is a companion to the How to Crack WPA/WPA2 tutorial.

The Wiki links page has a WPA/WPA2 section. The best document describing WPA is Wi-Fi Security - WEP, WPA and WPA2. This is the link to download the PDF directly.

To view the capture, use Wireshark to open it then “View” then “Expand All”. This shows all the sections and fields expanded. You will need to scroll through the fields for each packet to locate the ones mentioned. See this FAQ entry to learn how to use Wireshark.

The captures were done using an Ralink RT73 chipset and airodump-ng as the capture program.

Being able to read a capture file is an important skill to learn and build on. It allows you to troubleshoot a connection if you are having problems. By understanding this capture, you can then compare it to a live capture and hopefully find out what is going wrong.

Use this file: wpa.full.cap

This is the access point (AP) Beacon. It announces the presence and capabilities of the AP.

If you look at the “Vendor Specific” attributes, you can see the WPA attributes:

This is a Probe Request packet. This is the client looking for the AP. You will notice that the destination MAC is all “FF”s which is a broadcast address. Plus, you will see that the SSID in the packet is also set to broadcast.

If the AP does not respond to this, you might see the SSID set to the AP SSID. This is what is called a directed Probe Request. The packet capture does not include an example of this.

This is a Probe Response packet. This is the AP responding to the client. It has a source MAC of the BSSID and a destination MAC of the client. The packet informs the client about what capabilities it supports such as transmission speeds plus other relevant capabilities.

These are open authentication system packets.

The client sends an authentication request packet …:

… and the AP responds with an authentication acceptance packet:

These are the association packets. Essentially this joins the client to the network.

The client sends an association request packet …

… and the AP responds with an association response packet:

These are the four “handshake” WPA packets. These are the four critical packets required by aircrack-ng to crack WPA using a dictionary.

Notice that the AP initiates the four-way handshake by sending the first packet. The first pair of packets has a “replay counter” value of 1. The second pair has a “replay counter” value of 2. Packets with the same “replay counter” value are matching sets. If you have only one packet for a specific “replay counter” value then you are missing it from the capture and packet you do have cannot be used by aircrack-ng. That is why sometimes you have four EAPOL packets in your capture but aircrack-ng still says there are “0” handshakes. You must have matching pairs.

There are some other items to point out if you are analyzing a capture looking for a valid capture. EAPOL packets 1 and 3 should have the same nonce value. If they don't, then they are not part of the matching set. Aircrack-ng also requires a valid beacon. Ensure this beacon is part of the same packet sequence numbers. For example, if the beacon packet sequence number is higher then the EAPOL packet sequence numbers from the AP, the handshake will be ignored. This is because the aircrack-ng “resets” handshake sets when association packets and similar are seen.

IEEE 802.11 → Frame Control → Flags → DS Status Flag: The direction flags show “FROM DS” or “TO DS” depending on the packet. Meaning coming from the AP or going to it.

Packet 8:

Packet 9:

Packet 10:

Packet 11:

These are data packets to/from the wireless client to the LAN via the AP. You can view the TKIP Parameters field to confirm that WPA is used for these packets:

So you should now be able to do the same tests with your cards and see what is different.

Use this file: wpa.bad.passpharse.cap

This is the access point (AP) Beacon. It announces the presence and capabilities of the AP.

If you look at the “Vendor Specific” attributes, you can see the WPA attributes:

This is a Probe Request packet. This is the client looking for the AP. You will notice that the destination MAC is all “FF”s which is a broadcast address. Plus, you will see that the SSID in the packet is also set to broadcast.

If the AP does not respond to this, you might see the SSID set to the AP SSID. This is what is called a directed Probe Request. The packet capture does not include an example of this.

This is a Probe Response packet. This is the AP responding to the client. It has a source MAC of the BSSID and a destination MAC of the client. The packet informs the client about what capabilities it supports such as transmission speeds plus other relevant capabilities.

These are open authentication system packets. The client sends an authentication request packet and the AP responds with an authentication acceptance packet.

Packet 4:

Packet 5:

These are the association packets. Essentially this joins the client to the network.

The client sends an association request packet …

… and the AP responds with an association response packet.

Up to this point, you will notice that the packets are identical between a successful and failed connection.

These are the first two of four “handshake” WPA packets. The AP sends out a packet with information that it expects the wireless client to send back properly encrypted with passphrase. Since the wireless client is using the wrong passphrase, it is incorrect.

Notice that the AP initiates the four-way handshake by sending the first packet.

Packet 8:

Packet 9:

These are really just repeats of packets 8 and 9. The AP is giving the wireless client a chance to correctly answer. It never does. Thus the next packet (16) is a deauthentication packet.

Notice that the AP initiates the four-way handshake by sending the first packet. Each pair has successive “replay counter” values.

Packet 10:

Packet 11:

Packet 12:

Packet 13:

Packet 14:

Packet 15:

Since the wireless client never successfully proved it had the correct passphrase, the AP now deauthenticates the client. Effectively throwing it off the AP:

In Wireshark, use “eapol” as a filter. This will show only handshake packets and is useful for analyzing why you don't have the full handshake.