New parameter: --nonce-error-corrections

[atom]

I just wanted to do quick writeup on the new --nonce-error-corrections feature for WPA/WPA2 cracking in hashcat v3.40+x. 

Afaik hashcat is the first WPA/WPA2 cracker that addresses this feature but everyone who is using tcpdump, wireshark, tshark, airodump, besside or pyrit to capture the handshake should continue reading.

In a perfect world a valid AP Nonce / Replay-Count combinations for M1 looks like this (over time):

• NONCE = 0x.......1a, RC = 1
  
• NONCE = 0x.......1b, RC = 2
  
• NONCE = 0x.......1c, RC = 3
  

The problem is the real world. On here, not all AP do it like that. While we were validating some of the captures from the users who reported problems we found out that there's some AP which do the following instead:

• NONCE = 0x.......1a, RC = 1
  
• NONCE = 0x.......1b, RC = 1
  
• NONCE = 0x.......1c, RC = 1
  

That alone wouldn't be a problem, because it does not hinder a valid connection from a station to the AP. The problem is only for us who capture the handshake from the air (Note: The time between those packets can be less than a second). Such a case can occur if, for example because of bad signal, the station missed the first M1 from the AP. So this is a physical problem, not a problem of the protocol or the software.

For us who are passively capturing all the packets from air we'd think we got all the packets if, for example, the entire M1-M4 handshake has been recorded (with the correct RC!). From now on we assume the client was able to connect to the station and save the handshake. So everything looks fine. The problem is, with the changed behavior of the AP as described above this technique is flawed! 

The problem is if the first packet M1 was _not_ received by the station (but by us who capture the traffic) and at the same time a second packet M1 (Note: also M1) was received by the station (but this time not by us). From a passive side, we have no way to find out about this case just by looking at M2, M3 and M4. This leads us to the main problem: We can never crack the password, even with the correct passphrase!

The good news is, if the packets we've captured are of type 0, 1, 2 or 5 (which is usually the case) we can correct this error with almost no overhead using latest hashcat beta. Since the process of validating the handshake (which involves the use of the AP nonce) happens after the PBKDF2 computation it will not affect the cracking performance much. We will simply add a few virtual nonce's (with the goal to hit the correct one) on the fly, you will not notice it. Another good news is that we know that we will always have to count upwards, because whenever a client receives a new M1 packet it has to drop the older one.

The new parameter --nonce-error-corrections gives the user a way to configure the number of virtual nonce's generated inside the kernel. The default is set to 16 but if you want to turn it off you can set it to 0. The value 16 means, do an additional 16 tries of the validation, each time with the AP nonce increased by one. 

The result is the following:

• ./hashcat -m 2500 large_test1.hccapx wordlist.txt --nonce-error-corrections  0, cracked: 1898/13933
  
• ./hashcat -m 2500 large_test1.hccapx wordlist.txt --nonce-error-corrections 16, cracked: 1911/13933
  
• ./hashcat -m 2500 large_test2.hccapx wordlist.txt --nonce-error-corrections  0, cracked: 2021/12437
  
• ./hashcat -m 2500 large_test2.hccapx wordlist.txt --nonce-error-corrections 16, cracked: 2026/12437
  

Maybe we'll do a 3.41 release just for that feature, not sure yet.

- atom

[royce]

For future searchers, note that later work does incur a small performance penalty (perhaps in the 8-12% range?) at the previous default of 16 due to adding support for big-endian architectures, so the default was dropped from 16 to 8.