If you’ve ever tested Aircrack against a packet capture containing a handshake from a network whose WPA/WPA2 passphrase is known, you may have sometimes frowned at the “Passphrase not in dictionary” message. One possibility for this is noted on the (excellent) Aircrack website – http://www.aircrack-ng.org/doku.php?id=aircrack-ng#wpa_wpa2_handshake_analysis_fails. Essentially Aircrack hasn’t parsed the handshake from the capture correctly because there is too much “noise”. If Aircrack picks packets from different 4-way handshake exchanges then the passphrase will not be found, even if it’s in the dictionary. A tool called “wpaclean” (which is included in Backtrack) tidies up four-way handshake captures but, in my experiments, it didn’t always work so I wrote an alternative clean-up script, called William, that gives you more control. The usage is:

william.sh <output_file> <input_file> [<input_file_2>...] [<mth_packet_2> [<nth_packet_1>]] [-f | -a] [-A <dict_file>] [-d]

m mth second packet of 4-way handshake (default 1)
n nth first packet of 4-way handshake that precedes the chosen second packet (default 1)
-f seek first message from start of capture working forwards
-a pair up ALL message 1s that precede the chosen message 2 (multiple output files)
-A run aircrack-ng against output files using the supplied dictionary file
-d don't skip duplicate packets
--help extra help

William is a bash script. If I’d known how it would turn out, I would have chosen another programming route, but never mind, it still works as a proof of concept. Let me explain how it works, which in turn will explain what the switches do. Here’s a messy capture file from attempts to crack the WPA2 key of a client using Airbase as a rogue access point. (In my experiments, using Airbase against clients as opposed to sniffing legitimate 4-way handshakes tended to make noisier capture files.) As a client-side attack, only the first 2 of the 4 messages in the 4-way handshake were captured (but that’s enough for Aircrack to work on):

The first EAPOL frame is selected, which Wireshark informs us is the first of the 4 messages in the 4-way handshake. Note the “WPA Key Nonce” value. Now let’s move to the second EAPOL frame:

The “WPA Key Nonce” is exactly the same. So the packet was either transmitted twice or recorded twice, which can happen when you’re sniffing on an interface that’s also engaged in active testing. Let’s move to the third EAPOL frame:

Now the “WPA Key Nonce” is different, so this constitutes a second attempt at sending a first handshake message. Now let’s look at the first instance of a second message in the 4-way handshake:

It turns out that there have been 14 unique first packets sent up to this point so the question is, which of them does this second message correspond to? Park that problem for now and note the “WPA Key MIC” value above instead. Let’s move to the next second message:

It’s apparently the same – no surprise, given what we saw earlier. But it turns out the third instance of the second handshake message is the same too.  And so is the fourth, the fifth, the sixth…When all these first and second handshake messages are mixed up, it’s no wonder that Aircrack can sometimes produce false negatives. When I ran wpaclean it picked the 14th (i.e. the last) first message and the 1st second message. In other words it picks the first instance of a second message and works backwards to pick the first handshake message. Perfectly reasonable – but in this particular case Aircrack failed to find the passphrase from this pairing. Like Aircrack, wpaclean’s logic is fixed, so I wrote William to give you more options. The default is that it works just like wpaclean, as there’s nothing wrong with its logic. If you use the -f switch, however, William picks the first handshake message by working forwards from the start of the capture.

The n and m switches give you the freedom to try out your own pairings. If you run William with a single number 2 (i.e. william.sh <out_file> <in_file> 2) it picks the 2nd instance of a second handshake message and works backwards to find the first handshake message. The second message is always counted forwards from the start of the capture file. If you run William with the numbers 2 4, it picks the 4th first handshake message working backwards from the 2nd instance of a second handshake message. Adding -f to this would count the 4th first message from the start of the capture file. The –help switch gives more examples.

If you think about it, the second message of the handshake must correspond to one of the first messages that preceded it (assuming the capture is complete). So William informs you of how many unique first messages there were as a guide. If you select the -a option, William will generate capture files that pair the chosen second message with all the preceding first messages (working backwards from the second message), each file containing a different pairing. This brute-force method should succeed, assuming the passphrase is in your dictionary, but it will be more time-consuming.

AUTOMATED AIRCRACK

If you use the -A switch followed by the path to a dictionary file, William will run all output files through Aircrack automatically. It’s especially worth running this with -a because William will run Aircrack as the message pairs are written to file, so you may find the passphrase without having to wait for all the combinations to be generated. A successful screenshot follows:

DUPLICATES

As noted above, it’s possible that your capture file contains duplicate messages. By default, duplicates are ignored when counting the packet positions. If you use the -d option, duplicates are not ignored, i.e. the nth first packet and mth second packet are counted based entirely on their order of appearance in the file. As before, the second message is always counted forwards from the start of the capture file and the direction in which the first message is counted is set by the presence or absence of -f. The -d option won’t have much practical effect, it’s really just for experimentation.

THE NEED FOR A CORRECT SSID

When Aircrack parses a capture file, it first looks for the SSID of the network(s) whose traffic has been sniffed, and if it doesn’t find any it gives up. Why? Because the SSID is used with the passphrase to generate the Pairwaise Master Key. So even if you have the correct first and second handshake packets, without the correct SSID Aircrack will fail. William looks for packets that disclose the SSID based on the BSSID of the chosen second EAPOL message. If for some reason you’re unlucky enough to miss this, the script will ask you for a SSID and create a fake probe response packet to satisfy Aircrack.

INPUT

Multiple input files can be specified. If you’ve used Airodump with –write wpa, for example, it’s best to run William with the input wpa*.cap.

OUTPUT

The output file is the first parameter. If the -a switch has been used, the output filenames include a number to distinguish them. The number is an ordinal reflecting the position of the first message in the capture file so, as William works backwards from the second message, the number starts high and counts down to 1.

THE REAL WORLD

On a pentest job, outside the comfort of a known test environment, if Aircrack tells you the password isn’t in the dictionary, you have to believe it. Hopefully this posting will give you a few more ideas and you may want to run a few iterations of William just in case. I would suggest the following order, using -A <dictionary_file> each time:

1. Try REVERSE mode to mimic wpaclean (default, don’t specify -f or -a)
2. Try FORWARD mode with -f
3. Run ALL mode with -a

DOWNLOAD

Download v.0.1

NODS

This script is an extension of wpaclean and owes everything to the fantastic Wireshark command-line toolset, specifically tshark, mergecap and text2pcap.