feature request: add NONCE ERROR CORRECTIONS to hcxpmktool

[RaduNico]

I've encountered the following hash for which hashcat and hcxpmktool seem to disagree on what the correct PSK is.

WPA*02*c344678f5dffe6b2adb6e2bfbcf9a3d5*5a59ef3d5a0d*00082286fbfb*6950686f6e65202d204b4f5a*96c4775604afb7eaa46c9d91404e756f44ac5ca383a6345aacf2474d81a9a095*0103007502010a000000000000000000014647b5667f88fce5260ec391153c1dc0055c83b5226a3ff0dd6a09bcdc2f191c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*a0

Running hashcat on this hash result in hashcat returining 12345678 as the PSK for it, while hcxpmktool -l <hash> -p 12345678 is returning MIC not confirmed with a status return code of 2.

Is this a hashcat bug?

[ZerBea]

Interesting case, because I have no idea what's going on, yet. We take the hash from Yesterday:

$ hcxpmktool -l WPA*02*039e9239445d7895309a3b92118d9a2f*482cd00afa2c*dc5360ad926f*4c6576692042792047656f726765*aedd076acec4b077786a3eea7d0ec51a6d0f8377d285ca10e3f8a38bd8170b16*0103008702010a000000000000000000015ac167d0bbbdcf3d23eff8d9ef3c532d8fe5e7f2f217a62f1da3e270d268888c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002830260100000fac040100000fac040100000fac023c00010000000000000000000000000000000000*02 -p 12345678

HASH FORMAT.: EAPOL (WPA*02)
ESSID.......: Levi By George
MAC_AP......: 482cd00afa2c
MAC_CLIENT..: dc5360ad926f
PSK.........: 12345678
PMK.........: 2a4e469fdfb79f8d98b706ef659069f42e2dfe09557e4a534c8c43c9e2cc2e29 (calculated)
KEY VERSION.: WPA2
NONCE AP....: aedd076acec4b077786a3eea7d0ec51a6d0f8377d285ca10e3f8a38bd8170b16
NONCE CLIENT: 5ac167d0bbbdcf3d23eff8d9ef3c532d8fe5e7f2f217a62f1da3e270d268888c
PTK.........: 3223638bdc6bc27fc7fda2be3a4cbadf609829b96f6e00482cd00afa2cdc5360 (calculated)
KCK.........: 3223638bdc6bc27fc7fda2be3a4cbadf (calculated)
KEK.........: 609829b96f6e00482cd00afa2cdc5360 (calculated)
MIC.........: 039e9239445d7895309a3b92118d9a2f (confirmed)
PMKID.......: d236e7e399ffcca22f0e6f5bffa0f481 (calculated)

hcxpmktool confirmed the PSK

$ echo "WPA*02*039e9239445d7895309a3b92118d9a2f*482cd00afa2c*dc5360ad926f*4c6576692042792047656f726765*aedd076acec4b077786a3eea7d0ec51a6d0f8377d285ca10e3f8a38bd8170b16*0103008702010a000000000000000000015ac167d0bbbdcf3d23eff8d9ef3c532d8fe5e7f2f217a62f1da3e270d268888c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002830260100000fac040100000fac040100000fac023c00010000000000000000000000000000000000*02" > test.hc22000

$ hashcat -m 22000 test.hc22000 -a3 12345678
hashcat (v6.2.6-597-g2d6035982) starting
...
Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 22000 (WPA-PBKDF2-PMKID+EAPOL)
Hash.Target......: test.hc22000
Time.Started.....: Wed Jun 21 07:55:26 2023 (0 secs)
Time.Estimated...: Wed Jun 21 07:55:26 2023 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Mask.......: 12345678 [8]
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:       93 H/s (0.41ms) @ Accel:64 Loops:256 Thr:32 Vec:1
Recovered........: 1/1 (100.00%) Digests (total), 1/1 (100.00%) Digests (new)
Progress.........: 1/1 (100.00%)
Rejected.........: 0/1 (0.00%)
Restore.Point....: 0/1 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidate.Engine.: Device Generator
Candidates.#1....: 12345678 -> 12345678
Hardware.Mon.#1..: Temp: 42c Fan:  0% Util: 60% Core:2850MHz Mem:10802MHz Bus:16

Started: Wed Jun 21 07:55:25 2023
Stopped: Wed Jun 21 07:55:27 2023

hashcat confirmed the PSK

$ hcxhashtool -i test.hc22000 --john=test.john

OUI information file..........: /home/zerobeat/.hcxtools/oui.txt
OUI entries...................: 33772
total lines read..............: 1
valid hash lines..............: 1
EAPOL hash lines..............: 1
EAPOL written to john.........: 1

$ john --no-log --mask=1234567?d --format=wpapsk-opencl --pot=john.wpa.pot test.john
Device 1@tux1: NVIDIA GeForce RTX 4080
Using default input encoding: UTF-8
Loaded 1 password hash (wpapsk-opencl, WPA/WPA2/PMF/PMKID PSK [PBKDF2-SHA1 OpenCL])
Note: Minimum length forced to 8 by format
LWS=256 GWS=4980736 (19456 blocks) 
Press 'q' or Ctrl-C to abort, 'h' for help, almost any other key for status
Warning: Only 10 candidates buffered, minimum 4980736 needed for performance.
12345678         (Levi By George)     
1g 0:00:00:00  16.67g/s 166.7p/s 166.7c/s 166.7C/s Dev#1:38°C 12345671..12345677
Use the "--show" option to display all of the cracked passwords reliably
Session completed. 

john confirmed the PSK

Same procedure with the new hash:

$ hcxpmktool -l WPA*02*c344678f5dffe6b2adb6e2bfbcf9a3d5*5a59ef3d5a0d*00082286fbfb*6950686f6e65202d204b4f5a*96c4775604afb7eaa46c9d91404e756f44ac5ca383a6345aacf2474d81a9a095*0103007502010a000000000000000000014647b5667f88fce5260ec391153c1dc0055c83b5226a3ff0dd6a09bcdc2f191c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*a0 -p 12345678

HASH FORMAT.: EAPOL (WPA*02)
ESSID.......: iPhone - KOZ
MAC_AP......: 5a59ef3d5a0d
MAC_CLIENT..: 00082286fbfb
PSK.........: 12345678
PMK.........: a90370759a18f98616fd23b76f98c06011b7efbfa3c2ac0c56281e407d5a1d3b (calculated)
KEY VERSION.: WPA2
NONCE AP....: 96c4775604afb7eaa46c9d91404e756f44ac5ca383a6345aacf2474d81a9a095
NONCE CLIENT: 4647b5667f88fce5260ec391153c1dc0055c83b5226a3ff0dd6a09bcdc2f191c
PTK.........: ab5b0ebba465ddda172de0e9600c7539a2227f196f6e0000082286fbfb5a59ef (calculated)
KCK.........: ab5b0ebba465ddda172de0e9600c7539 (calculated)
KEK.........: a2227f196f6e0000082286fbfb5a59ef (calculated)
MIC.........: c344678f5dffe6b2adb6e2bfbcf9a3d5 (not confirmed)

hcxpmktool doesn't confirm the PSK

$ echo "WPA*02*c344678f5dffe6b2adb6e2bfbcf9a3d5*5a59ef3d5a0d*00082286fbfb*6950686f6e65202d204b4f5a*96c4775604afb7eaa46c9d91404e756f44ac5ca383a6345aacf2474d81a9a095*0103007502010a000000000000000000014647b5667f88fce5260ec391153c1dc0055c83b5226a3ff0dd6a09bcdc2f191c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*a0" > test.hc22000

$ hashcat -m 22000 test.hc22000 -a3 12345678
hashcat (v6.2.6-597-g2d6035982) starting
...
c344678f5dffe6b2adb6e2bfbcf9a3d5:5a59ef3d5a0d:00082286fbfb:iPhone - KOZ:12345678

Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 22000 (WPA-PBKDF2-PMKID+EAPOL)
Hash.Target......: test.hc22000
Time.Started.....: Wed Jun 21 08:02:13 2023 (0 secs)
Time.Estimated...: Wed Jun 21 08:02:13 2023 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Mask.......: 12345678 [8]
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:       69 H/s (0.49ms) @ Accel:8 Loops:256 Thr:256 Vec:1
Recovered........: 1/1 (100.00%) Digests (total), 1/1 (100.00%) Digests (new)
Progress.........: 1/1 (100.00%)
Rejected.........: 0/1 (0.00%)
Restore.Point....: 0/1 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidate.Engine.: Device Generator
Candidates.#1....: 12345678 -> 12345678
Hardware.Mon.#1..: Temp: 39c Fan:  0% Util: 20% Core:2505MHz Mem:10802MHz Bus:16

Started: Wed Jun 21 08:02:12 2023
Stopped: Wed Jun 21 08:02:13 2023

hashcat confirm the PSK

$ hcxhashtool -i test.hc22000 --john=test.john

OUI information file..........: /home/zerobeat/.hcxtools/oui.txt
OUI entries...................: 33772
total lines read..............: 1
valid hash lines..............: 1
EAPOL hash lines..............: 1
EAPOL written to john.........: 1

$ john --no-log --mask=1234567?d --format=wpapsk-opencl --pot=john.wpa.pot test.john
Device 1@tux1: NVIDIA GeForce RTX 4080
Using default input encoding: UTF-8
Loaded 1 password hash (wpapsk-opencl, WPA/WPA2/PMF/PMKID PSK [PBKDF2-SHA1 OpenCL])
Note: Minimum length forced to 8 by format
LWS=256 GWS=311296 (1216 blocks) 
Press 'q' or Ctrl-C to abort, 'h' for help, almost any other key for status
Warning: Only 10 candidates buffered, minimum 311296 needed for performance.
0g 0:00:00:00  0g/s 1000p/s 1000c/s 1000C/s Dev#1:39°C 12345671..12345677
Session completed. 

john doesn't confirm the PSK, too.

To make sure that the hash line is correct (hcxpcapngtool bug?), could you add the dump file, please? You can remove all frames except BEACON, EAPOL M1 and EAPOL M2 to make sure the has line is converted correctly.

[ZerBea]

I'll contact Atom (hashcat) to figure out, what went wrong. My suspect is the hash line calculated by hcxpcapngtool - but I'm not sure without analyzing the dump file.

[ZerBea]

I got it!

The difference between hashcat and hcxpmktool and hashcat is that hashcat is doing NONCE ERROR CORRECTIONS (NC) https://hashcat.net/forum/thread-6361.html

hcxpcapngtool converted the MESSAGEPAIR to hashcat, but due to a packet loss, NONCEERROR CORRECTION is mandatory to recover th PSK.

Neither hcxpmktool nor john doing NC, so both will not get the PSK. If you do NC by hand, hcxpmktool and jtr get the correct PSK

received ANONCE: 96c4775604afb7eaa46c9d91404e756f44ac5ca383a6345aacf2474d81a9a095 corrected ANONCE: 96c4775604afb7eaa46c9d91404e756f44ac5ca383a6345aacf2474d81a9a094

$ hcxpmktool -l WPA*02*c344678f5dffe6b2adb6e2bfbcf9a3d5*5a59ef3d5a0d*00082286fbfb*6950686f6e65202d204b4f5a*96c4775604afb7eaa46c9d91404e756f44ac5ca383a6345aacf2474d81a9a094*0103007502010a000000000000000000014647b5667f88fce5260ec391153c1dc0055c83b5226a3ff0dd6a09bcdc2f191c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*a0 -p 12345678

HASH FORMAT.: EAPOL (WPA*02)
ESSID.......: iPhone - KOZ
MAC_AP......: 5a59ef3d5a0d
MAC_CLIENT..: 00082286fbfb
PSK.........: 12345678
PMK.........: a90370759a18f98616fd23b76f98c06011b7efbfa3c2ac0c56281e407d5a1d3b (calculated)
KEY VERSION.: WPA2
NONCE AP....: 96c4775604afb7eaa46c9d91404e756f44ac5ca383a6345aacf2474d81a9a094
NONCE CLIENT: 4647b5667f88fce5260ec391153c1dc0055c83b5226a3ff0dd6a09bcdc2f191c
PTK.........: 67f573d3b32cb364c29b9c5823364b6f3e04616d6f6e0000082286fbfb5a59ef (calculated)
KCK.........: 67f573d3b32cb364c29b9c5823364b6f (calculated)
KEK.........: 3e04616d6f6e0000082286fbfb5a59ef (calculated)
MIC.........: c344678f5dffe6b2adb6e2bfbcf9a3d5 (confirmed)
PMKID.......: 9c53c1e57e70c6cc9cf4e45cd459c082 (calculated)

hcxpmktool confirmed the PSK (using the corrected ANONCE)

$ john --no-log --mask=1234567?d --format=wpapsk-opencl --pot=john.wpa.pot test.john
Device 1@tux1: NVIDIA GeForce RTX 4080
Using default input encoding: UTF-8
Loaded 2 password hashes with no different salts (wpapsk-opencl, WPA/WPA2/PMF/PMKID PSK [PBKDF2-SHA1 OpenCL])
Note: Minimum length forced to 8 by format
LWS=256 GWS=155648 (608 blocks) 
Press 'q' or Ctrl-C to abort, 'h' for help, almost any other key for status
Warning: Only 10 candidates buffered, minimum 155648 needed for performance.
12345678         (iPhone - KOZ)     
1g 0:00:00:00  14.29g/s 142.9p/s 142.9c/s 285.7C/s Dev#1:52°C 12345671..12345677
Use the "--show" option to display all of the cracked passwords reliably
Session completed. 

john confirmed the PSK (using the corrected ANONCE)

All tools (hashcat with NC), john (without NC), hcxpmktool (without NC) doing exactly what expected.

I'll add a notice to help, that hcxpmktool not doing NC.

I'll leave this open to remind me to check if it is possible to add NC on CPU to hcxpmktool, because it will slow down us.

[ZerBea]

I changed the head line, because it is more a feature request than a bug.

Now I test if we can add at least NC = 8.

The impact is huge, because it will slow us down by factor 32 (8 + 8 + 8 + 8), because we have to calculate the PTK 32 times and the MIC times instead of one time: BIG ENDIAN ROUTER NC + 8 BIG ENDIAN ROUTER NC - 8 LITTLE ENDIAN ROUTER NC + 8 LITTLE ENDIAN ROUTER NC - 8

[ZerBea]

Adding NC will take awhile. The entire tools must be refactored.

[RaduNico]

Do you still require the initial capture which generated this hash?

[ZerBea]

No, that is not necessary, because I know what's going on:

packet loss during capturing hcxpcapngtool converted the hash and detected MESSAGEPAIR CONDITION a0 (bin: 10100000 = nonce-error-corrections mandatory)

In detail:

000 = M1M2 challenge
0 = reserved
0 = no ap-less attack
1 = LITTLE ENDIAN ROUTER detected
0 = BIG ENDIAN ROUTER not detected
1 = not replaycount checked (set to 1) - replaycount not checked, nonce-error-corrections mandatory

PSK can be only confirmed/recovered by a tool that does NONCE ERROR CORRECTIONS (like hashcat).

explanation of the MESSAGEPAIR field:

bitmask of EAPOL hash line (WPA*02) message pair field:
2,1,0:
 000 = M1+M2, EAPOL from M2 (challenge)
 001 = M1+M4, EAPOL from M4 (authorized) - usable if NONCE_CLIENT is not zeroed 
 010 = M2+M3, EAPOL from M2 (authorized)
 011 = M2+M3, EAPOL from M3 (authorized) - unused
 100 = M3+M4, EAPOL from M3 (authorized) - unused
 101 = M3+M4, EAPOL from M4 (authorized) - usable if NONCE_CLIENT is not zeroed
3: reserved
4: ap-less attack (set to 1) - nonce-error-corrections not required
5: LE router detected (set to 1) - nonce-error-corrections required only on LE
6: BE router detected (set to 1) - nonce-error-corrections required only on BE
7: not replaycount checked (set to 1) - replaycount not checked, nonce-error-corrections mandatory

Which tool was used to capture the traffic? Which command line options are used to convert the hash?

[RaduNico]

hcxdumptool was used to capture the traffic the hash was converted using hcxpcapngtool -o capture_0005.pcapng

[ZerBea]

Thanks for the information. Now we know that hcxdumptool and hcxpcapngtool are working as expected. We gt a hash and hashcat was able to recover the PSK (with NC). hcxpmktool and JtR couldn't recover the PSK, because both do not NC.

Conclusion: hcxpmktool should get NC.

[kimocoder]

Confirmed. Works in wifite2 v2.7.0 also. password recovered with both "hashcat" and "cowPatty".

[ZerBea]

Doing NC is a little bit tricky (on CPU), because we need several load balancers: PBKDF2 load balancer MD5 load balancer (WPA1) SHA1 load balancer (WPA2) SHA256 load balancer (WPA2 key version 3) HMAC SHA1 load balancer (WPA1 WPA2) AES128-CBC load balancer (WPA2 key version 3)

Additional we need a good (fast) data base.

All together == complete new design of hcxpmktool.

[LLH-l]

Please ask bitmask 80
a2
*c0 In "8...a...c"value, How much NONCE they will compensate

[ZerBea]

As of today all hcxtools only detect if NC is possible and hcxdumptool give a suggestion about the value. This is done by comparing different EAPOL M1 and/or EAPOL M3 messages. This will only be possible if the dump file contain more than one different EAPOL M1 and/or EAPOL M3 messages. If an AP increase its ANONCE, hcxpcapngtool is able to detect a packet loss and hashcat is able to compensate it. If a packet loss is detected, hcxpcapngtool set bit 5, 6, 7 (of the MESSAGE PAIR FIELD) dependent on the type of the router (BE/LE):

4: NC (set to 1) - nonce-error-corrections deactivated on M1M2ROGUE, M2M3E3 and M3M4E3
5: LE router detected (set to 1) - nonce-error-corrections required only on LE
6: BE router detected (set to 1) - nonce-error-corrections required only on BE
7: NC (set to 1) - nonce-error-corrections activated

This bitmask is explained in help:

$ hcxpcapngtool --help
bitmask of EAPOL hash line (WPA*02) message pair field:
2,1,0:
 000 = M1+M2, EAPOL from M2 (challenge)
 001 = M1+M4, EAPOL from M4 (authorized) - usable if NONCE_CLIENT is not zeroed 
 010 = M2+M3, EAPOL from M2 (authorized)
 011 = M2+M3, EAPOL from M3 (authorized) - usable by option --all
 100 = M3+M4, EAPOL from M3 (authorized) - usable by option --all
 101 = M3+M4, EAPOL from M4 (authorized) - usable if NONCE_CLIENT is not zeroed
3: reserved
4: NC (set to 1) - nonce-error-corrections deactivated on M1M2ROGUE, M2M3E3 and M3M4E3
5: LE router detected (set to 1) - nonce-error-corrections required only on LE
6: BE router detected (set to 1) - nonce-error-corrections required only on BE
7: NC (set to 1) - nonce-error-corrections activated

Hashcat evaluate this bits to handle NC exactly.

$ hashcat --help
 --nonce-error-corrections  | Num  | The BF size range to replace AP's nonce last bytes   | --nonce-error-corrections=16

Additional hcxpcapngtool give an advice: REPLAYCOUNT gap (suggested NC)...........: 1

The value can be used with hashcat "--nonce-error-corrections=". Please notice that this suggestion is an approximate value only, because it highly depend on the quality of the dump file.

[ZerBea]

BTW: I'm still undecided to add NC to hcxpmktool, because this tool is not a cracking tool. Hashcat and JtR can do this a hundred thousand better and faster. The only purpose of hcxpmktool is to detect if a MESSAGE PAIR exactly matched to a given PSK/PMK.

[ZerBea]

To decrypt WPA it is mandatory to calculate a PTK that is exactly part of the same AUTHENTICATION sequence (session) as the 4way handshake. A matching MESSAGE PAIR that is exactly part of this AUTHENTICATION sequence (session) is mandatory too.

In other words: If you have had calculated a PTK that is not part of the same session as the handshake, it is impossible (!) to decrypt the traffic.

BTW: Injection thousands of stupid DEAUTHENTICATION frames to (possible) get a handshake will prevent to get the mandatory data from the same session. DEAUTHENTICATION (total).................: 6915 https://github.com/ZerBea/hcxtools/issues/245#issuecomment-1437083043

and you get a warning:

Warning: too many deauthentication/disassociation frames detected!
That can cause that an ACCESS POINT change channel, reset EAPOL TIMER,
renew ANONCE and set PMKID to zero.
This could prevent to calculate a valid EAPOL MESSAGE PAIR
or to get a valid PMKID.

[ZerBea]

Some information about NC: NC is implemented to hashcat to possible compensate a packet loss during capturing a 4way handshake. However, this should not be the norm under any circumstances! The highest priority is to capture everything that is needed to recover the PSK without the need to use NC. Every tool in the workflow (converting to hash format, GPU cracker, decrypt traffic) will possible fail, if the dump file is crappy due to packet losses. Unfortunately this is mostly the case if passive dumpers are used to capture the traffic.

[LLH-l]

@ZerBea Data packet loss, not always in last character If this group is no M1 or M3 situation How to detect the NONCE field and compensate in the correct field position e,g Or No M3

5887    Jan  2, 2017 14:50:02.263688000     1   1   c86506005b8970ff7604348c818e262d3fa54ccb030a087f6d07397443f2e1ff
6078    Jan  2, 2017 14:50:09.030724000     2   1   30c5c31418a16285142b50ad7a92ea48adb9491848c7231ee70f9c3c1e1c7870

e,g Or No M1

6078    Jan  2, 2017 14:50:09.030724000     2   1   30c5c31418a16285142b50ad7a92ea48adb9491848c7231ee70f9c3c1e1c7870
6079    Jan  2, 2017 14:50:09.033800000     3   2   c86506005b8970ff7604348c818e262d3fa54ccb030a087f6d07397449f2e1ff

How to confirm compensation at a certain field position

[ZerBea]

Take a look at this example: A dump file contain one M1 MESSAGE, one M2 MESSAGE and one M1 MESSAGE

1 M1  30c5c31418a16285142b50ad7a92ea48adb9491848c7231ee70f9c3c1e1c7870
2 M2  c86506005b8970ff7604348c818e262d3fa54ccb030a087f6d07397443f2e1ff
3 M1  30c5c31418a16285142b50ad7a92ea48adb9491848c7231ee70f9c3c1e1c7878

we know that on some LE routers the ANONCE increase (BE routers are different)

we got xx70 and xx78 at the ending
all EAPOL packets with xx71, xx72, xx73, xx74, xx75, xx76, xx77, got lost

Not all routers use this mechanism. Some increment the REPLAYCOUNTER, some of them increment the SEQUENCE NUMBER, some of the do a mix of all.

hashcat will now calculate MESSAGE PAIRs with the following ANONCE SNONCE combinations to calculate the PTK (and later on the MC) by the formulas as explained here: https://www.ciscopress.com/articles/article.asp?p=370636&seqNum=6

30c5c31418a16285142b50ad7a92ea48adb9491848c7231ee70f9c3c1e1c7870 c86506005b8970ff7604348c818e262d3fa54ccb030a087f6d07397443f2e1ff
30c5c31418a16285142b50ad7a92ea48adb9491848c7231ee70f9c3c1e1c7871 c86506005b8970ff7604348c818e262d3fa54ccb030a087f6d07397443f2e1ff
30c5c31418a16285142b50ad7a92ea48adb9491848c7231ee70f9c3c1e1c7872 c86506005b8970ff7604348c818e262d3fa54ccb030a087f6d07397443f2e1ff
30c5c31418a16285142b50ad7a92ea48adb9491848c7231ee70f9c3c1e1c7873 c86506005b8970ff7604348c818e262d3fa54ccb030a087f6d07397443f2e1ff
30c5c31418a16285142b50ad7a92ea48adb9491848c7231ee70f9c3c1e1c7874 c86506005b8970ff7604348c818e262d3fa54ccb030a087f6d07397443f2e1ff
30c5c31418a16285142b50ad7a92ea48adb9491848c7231ee70f9c3c1e1c7875 c86506005b8970ff7604348c818e262d3fa54ccb030a087f6d07397443f2e1ff
30c5c31418a16285142b50ad7a92ea48adb9491848c7231ee70f9c3c1e1c7876 c86506005b8970ff7604348c818e262d3fa54ccb030a087f6d07397443f2e1ff
30c5c31418a16285142b50ad7a92ea48adb9491848c7231ee70f9c3c1e1c7877 c86506005b8970ff7604348c818e262d3fa54ccb030a087f6d07397443f2e1ff
30c5c31418a16285142b50ad7a92ea48adb9491848c7231ee70f9c3c1e1c7878 c86506005b8970ff7604348c818e262d3fa54ccb030a087f6d07397443f2e1ff

At least, one of this combinations lead to a PTK that calculate the correct MIC of the M2.

The same applies to M3 or combinations om M1 and M3, e.g.: A dump file contain two M3 MESSAGEs and one M2 MESSAGE

1 M3  30c5c31418a16285142b50ad7a92ea48adb9491848c7231ee70f9c3c1e1c7870
2 M2  c86506005b8970ff7604348c818e262d3fa54ccb030a087f6d07397443f2e1ff
3 M3  30c5c31418a16285142b50ad7a92ea48adb9491848c7231ee70f9c3c1e1c7878

A dump file contain one M1 MESSAGE, one M2 MESSAGE and one M3 MESSAGE

1 M3  30c5c31418a16285142b50ad7a92ea48adb9491848c7231ee70f9c3c1e1c7870
2 M2  c86506005b8970ff7604348c818e262d3fa54ccb030a087f6d07397443f2e1ff
3 M1  30c5c31418a16285142b50ad7a92ea48adb9491848c7231ee70f9c3c1e1c7878

NC can be controlled via hascat "nonce-error-corrections" option.

[ZerBea]

Data packet loss, not always in last character Packet loss means that an entire packet got lost and not only a single byte,

[ZerBea]

The entire process: crappy dumpfile (heavy packet loss) -> hcxpcapngtool detect packet loss (and router type) and set NC bit in MESSAGE PAIR field -> hashcat use default NC +- 8 (can be over written by nonce-error-corrections)

It is mandatory that the dump file is uncleaned!

[LLH-l]

NONCE sequence calculation is NC=16 e.g

M1 NONCE : a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4ae0
M3 NONCE : a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4aef

This need NC+14 Or NC-14

a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4ae1
a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4ae2
a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4ae3
a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4ae4
a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4ae5
a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4ae6
a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4ae7
a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4ae8
a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4ae9
a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4aea
a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4aeb
a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4aec
a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4aed
a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4aee

If set to NC=8, it seems be a incomplete compensate

[ZerBea]

Correct, but that depend on the exact(!) timestamp of the M2.

M1 ANONCE : a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4ae0
M2 SNONCE
M3 ANONCE : a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4aef

NC should be at least 16

M1 ANONCE : a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4ae1
M2 SNONCE
M1 ANONCE : a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4aee

NC should be at least 14

But in that case it should be greater due to a possible packet loss:

M1 ANONCE : a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4ae1
M1 ANONCE : a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4aee
M1 ANONCE : packet loss xxef
M1 ANONCE : packet loss eef0
M2 SNONCE

[ZerBea]

By default hashcat takes the ANONCE of the hash line: a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4ae8 and do back by 8 a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4ae7 a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4ae6 a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4ae5 a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4ae4 a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4ae3 a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4ae2 a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4ae1 and do up by 8: a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4ae9 a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4aea a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4aeb a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4aec a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4aed a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4aee a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4aef a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d4af0

[ZerBea]

Just to mention that: NC is possible not only on the last byte - it is possible on the entire ANONCE. nonce-error-corrections=65535

a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72d0000 -> a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7c72dffff

That applies to BE routers, too:

a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb700004ae9 -> a6a718d38e7d9e26b05eb5b0f1589b7b0805d0392204869b76c2ddb7ffff4ae

[LLH-l]

NC is possible not only on the last byte - it is possible on the entire ANONCE.

Avoid this situation happening Seems need use excellent capture tool hcxdumptool !

[ZerBea]

To avoid missing packets it is mandatory to use an active dumper. This dumper must be able to detect a packet loss and it must be able to request the missing packets. A sensitive WiFi adapter connected to a high gain antenna is mandatory, too. TX power of this WiFi adapter is meaningless.

[LLH-l]

@ZerBea If not told which position requires NC, Needs to perform NC loop compensation, need check two position This will double increase number NC

e.g This need check 2 diff positions NC compensation WPA*TYPE*MIC*MACAP*MACCLIENT*ESSID*966706a3b4b6c9cd6935caa72e5718af51b71a577aa84421d6a3e362ffe203ff*EAPOL*80

[ZerBea]

@LLH-l that is absolutely correct and hashcat default is:

do NONCE ERROR CORRECTION on LE up 8
do NONCE ERROR CORRECTION on LE down 8
do NONCE ERROR CORRECTION on BE up 8
do NONCE ERROR CORRECTION on BE down 8

[LLH-l]

@ZerBea Seems need improve detection router type e.g

0_(1266).cap Is BE type

0_(1751).cap Is LE type

They should be BE type or LE type But now setting it to *8 This will detect 2 positions NC

[ZerBea]

I'll check it.

[ZerBea]

I pushed and update. Please test.

[LLH-l]

I pushed and update. Please test.

Only need In the hash mask identification is LE or BE type They can accuracy lock this position NC up or down counting work

e.g,... use hcxpcapngtool --all --nonce-error-corrections=1024 -o Lock each hash NC position Only need to tell them this position NC 0_(1266).cap is BE type

WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27ba4c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*c2
WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*c0

0_(1751).cap is LE type

WPA*02*4a08cb172358d4946a34e814f132c9a7*246968f2403e*086266d94aff*54502d4c494e4b5f34303345*435c89d091bebeea7b2f475f4588ed2dd3df5c48985f0f463477743ec8294cee*0103007502010a000000000000000000024273aafff876c482db085fab6a19c2f8ed97bc22e0dfdb5a554913abf98e19f6000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*a2
WPA*02*4a08cb172358d4946a34e814f132c9a7*246968f2403e*086266d94aff*54502d4c494e4b5f34303345*435c89d091bebeea7b2f475f4588ed2dd3df5c48985f0f463477743ec8294ced*0103007502010a000000000000000000024273aafff876c482db085fab6a19c2f8ed97bc22e0dfdb5a554913abf98e19f6000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*a0

0_(2469).cap is LE type

WPA*02*e6486fe0ad50c0ae96704424a99282e0*d0c7c021c638*5cf5daedc887*54502d4c494e4b5f43363338*6d6c3ed57d765afe7d833a0d6c9eb28b823e34c1ae480dcc44cfd4818d377b0f*0203007502010a0010000000000000000174e1a70a8f570a8854464460b9f6cfb5fb59253629b59b512573a8c9736e648f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020c00*a2
WPA*02*e6486fe0ad50c0ae96704424a99282e0*d0c7c021c638*5cf5daedc887*54502d4c494e4b5f43363338*6d6c3ed57d765afe7d833a0d6c9eb28b823e34c1ae480dcc44cfd4818d377b0e*0203007502010a0010000000000000000174e1a70a8f570a8854464460b9f6cfb5fb59253629b59b512573a8c9736e648f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020c00*a0

e.g If router type cannot be confirmed NC will need to be performed in 2 different positions

WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*80
WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*82

[LLH-l]

For example, using hcxpcapngtool --all --nonce-error-corrections=1024 -o Among , M1M2E2 cannot lock the NC position, This will execute NC in 2 different positions

0_(1266).cap

WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27ba4c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*c2
WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*80

0_(2469).cap Among, M2M3E2, not locked NC position, This will execute NC in 2 different positions Among, M1M2E2 not execute NC,

WPA*02*e6486fe0ad50c0ae96704424a99282e0*d0c7c021c638*5cf5daedc887*54502d4c494e4b5f43363338*6d6c3ed57d765afe7d833a0d6c9eb28b823e34c1ae480dcc44cfd4818d377b0f*0203007502010a0010000000000000000174e1a70a8f570a8854464460b9f6cfb5fb59253629b59b512573a8c9736e648f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020c00*22
WPA*02*e6486fe0ad50c0ae96704424a99282e0*d0c7c021c638*5cf5daedc887*54502d4c494e4b5f43363338*6d6c3ed57d765afe7d833a0d6c9eb28b823e34c1ae480dcc44cfd4818d377b0e*0203007502010a0010000000000000000174e1a70a8f570a8854464460b9f6cfb5fb59253629b59b512573a8c9736e648f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020c00*00

[ZerBea]

I'l check it, but this will take some time, because this is a real problem.

[LLH-l]

I'l check it, but this will take some time, because this is a real problem.

If data packet cannot be confirmed to is LE or BE type Bitmask tells them,this need NC execution in 2 different positions

WPA*TYPE*MIC*MACAP*MACCLIENT*ESSID*NONCE*EAPOL*80
WPA*TYPE*MIC*MACAP*MACCLIENT*ESSID*NONCE*EAPOL*82

If can in data packet confirmed it is LE type Only need in LE byte position execute NC

WPA*TYPE*MIC*MACAP*MACCLIENT*ESSID*NONCE*EAPOL*a0
WPA*TYPE*MIC*MACAP*MACCLIENT*ESSID*NONCE*EAPOL*a2

If can in data packet confirmed it is BE type Only need in BE byte position execute NC

WPA*TYPE*MIC*MACAP*MACCLIENT*ESSID*NONCE*EAPOL*C0
WPA*TYPE*MIC*MACAP*MACCLIENT*ESSID*NONCE*EAPOL*C2

NC default parameters by third-party tools themselves determined

[ZerBea]

Problem at the moment is the detection of big NC values without a performance impact. But I think I can find a solution.

[ZerBea]

Let me explain the problem:

$ tshark -r '0_(1266).cap' -Y "eapol" -T fields -e frame.time -e wlan_rsna_eapol.keydes.nonce
Jul 22, 2016 13:49:53.753680000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.753680000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.753680000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.756238000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.761358000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.769552000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.769556000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.770580000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.772112000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.774158000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.776208000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.780304000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.810512000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:54.381958000 CEST    825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26
Jul 22, 2016 13:49:54.388624000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27ba4c4130
Jul 22, 2016 13:49:54.388612000 CEST    0000000000000000000000000000000000000000000000000000000000000000

Jul 22, 2016 13:49:53.753680000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.753680000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.753680000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.756238000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.761358000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.769552000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.769556000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.770580000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.772112000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.774158000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.776208000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.780304000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:53.810512000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:54.381958000 CEST    825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26
Jul 22, 2016 13:49:54.388624000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27ba4c4130

calculated MESSAGE PAIRS:
Jul 22, 2016 13:49:53.753680000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:54.381958000 CEST    825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26

Jul 22, 2016 13:49:53.753680000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:54.381958000 CEST    825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26

Jul 22, 2016 13:49:53.753680000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:54.381958000 CEST    825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26
....
Jul 22, 2016 13:49:53.810512000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130
Jul 22, 2016 13:49:54.381958000 CEST    825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26

until this MESSAGE PAIR, we can't calculate NC, because all ANONCE are equal!

this is the first MESSGAE PAIR with a different ANONCE - we can calculate NC
Jul 22, 2016 13:49:54.381958000 CEST    825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26
Jul 22, 2016 13:49:54.388624000 CEST    0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27ba4c4130

Now we have to go back on all MESSAGE PAIRS to recalculate the NC. On big dump files, this will have a huge performance impact

[ZerBea]

I think I have a solution:

$ hcxpcapngtool "0_(1266).cap" -o test.22000 --nonce-error-corrections=1024 --all
$ cat test.22000
WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27ba4c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*42
WPA*02*cafcf130da1cb137c7f549c5771b0ac5*0810787623da*ec89f56e53b4*4e6574636f7265*825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26*010300970213ca001000000000000000010b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27ba4c41300b83fd16376ddede6d7e1f1a2ac954c2268a0900000000000000000000000000000000000000000000000000000000000038060cc1cc48705bb8ec93cf63b874f5b43adc14baf0544902351268f3909a03aab64b546e6a3735b986fc623bad3adb136449ce0c5dbfda91*13
WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*80
WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*80
WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*80
WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*80
WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*80
WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*80
WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*80
WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*80
WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*80
WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*80
WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*80
WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*80
WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*80

If ENDIANESS is detected: WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27ba4c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*42

If MESSAGE PAIR is M2M3E3 WPA*02*cafcf130da1cb137c7f549c5771b0ac5*0810787623da*ec89f56e53b4*4e6574636f7265*825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26*010300970213ca001000000000000000010b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27ba4c41300b83fd16376ddede6d7e1f1a2ac954c2268a0900000000000000000000000000000000000000000000000000000000000038060cc1cc48705bb8ec93cf63b874f5b43adc14baf0544902351268f3909a03aab64b546e6a3735b986fc623bad3adb136449ce0c5dbfda91*13

remaining MESSAGE PAIRS, eg; WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27b84c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*80

Now you can filter the wanted MESSAGE PAIRs either by bash tools.

e.g. get hash line(s) containing router ENDIANESS LE:

$ cat test.22000 | grep "4.$"
WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27ba4c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*42

or get hash line(s) EAPOL M2M3E3

$ cat test.22000 | grep 13$
WPA*02*cafcf130da1cb137c7f549c5771b0ac5*0810787623da*ec89f56e53b4*4e6574636f7265*825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26*010300970213ca001000000000000000010b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27ba4c41300b83fd16376ddede6d7e1f1a2ac954c2268a0900000000000000000000000000000000000000000000000000000000000038060cc1cc48705bb8ec93cf63b874f5b43adc14baf0544902351268f3909a03aab64b546e6a3735b986fc623bad3adb136449ce0c5dbfda91*13

or via hashcat directly:

$ hashcat --help | grep message
     --hccapx-message-pair      | Num  | Load only message pairs from hccapx matching X       | --hccapx-message-pair=2

This is a solution without any performance impact.

[LLH-l]

e.g. get hash line(s) containing router ENDIANESS LE: WPA*02*1c31b50f51590c0231d973de52fc0dbd*0810787623da*ec89f56e53b4*4e6574636f7265*0b83fd16376ddede6d7e1f1a2ac954c2f5e2a99b51d10e8087285a27ba4c4130*0103007502010a00000000000000000000825341aad4fdd0538cea871fed74f1bca81a518f7454c9ef9b4511c2b2a16d26000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*42

If I want know it belongs to LE or BE type How determine this hash is LE instead of BE

[ZerBea]

bitmask:

bitmask of EAPOL hash line (WPA*02) message pair field:
2,1,0:
 000 = M1+M2, EAPOL from M2 (challenge)
 001 = M1+M4, EAPOL from M4 (authorized) - usable if NONCE_CLIENT is not zeroed 
 010 = M2+M3, EAPOL from M2 (authorized)
 011 = M2+M3, EAPOL from M3 (authorized) - usable by option --all
 100 = M3+M4, EAPOL from M3 (authorized) - usable by option --all
 101 = M3+M4, EAPOL from M4 (authorized) - usable if NONCE_CLIENT is not zeroed
3: reserved
4: NC (set to 1) - nonce-error-corrections deactivated on M1M2ROGUE, M2M3E3 and M3M4E3
5: LE router detected (set to 1) - nonce-error-corrections required only on LE
6: BE router detected (set to 1) - nonce-error-corrections required only on BE
7: NC (set to 1) - nonce-error-corrections activated

MESSAGE PAIR == 0x42 == 0b01000010

bit: 76543210
val: 01000010

....0010
010 = M2+M3, EAPOL from M2 (authorized)

0100....
6: BE router detected (set to 1) - nonce-error-corrections required only on BE

You can use galculator to calculate hex -> binary.

[ZerBea]

Maybe I haven't mentioned this: If you override hcxpcapngtool's automatic by --nonce-error-corrections=1024 it is mandatory to use it on hashcat too (--nonce-error-corrections=1024).

[LLH-l]

Maybe I haven't mentioned this: If you override hcxpcapngtool's automatic by --nonce-error-corrections=1024 it is mandatory to use it on hashcat too (--nonce-error-corrections=1024).

Hmm...parameter is relatively large, goal is convert all message pairs Yeah..new bitmask is more accurate

I test hashcat NC It seems that hashcat must add NC parameters to work ?... If NC parameters not specified, hashcat NC cannot work ? At least, I currently use hashcat test is this Maybe your test will more professional I not have deeper test it

[ZerBea]

hashcat default NC is +- 8 on BE and +-8 on LE Everything else can be controlled by hashcat --nonce-error-corrections=x As long as the quality of the dump files is good, mostly the combination of hcxpcapngtool (default) and hashcat default is working fine. On poor quality dump files (recorded by passive dumpers) the automatic fails on both (hcxpcapngtool and hashcat), In that case NC is mandatory on both tools.

In other words, NC is a mechanism to handle poor quality dump files, but goal should be (in every case) to record high quality dump files. A poor quality dump file always(!) requires manual analysis. No automatic, no matter how good, can restore lost packets.

[LLH-l]

@ZerBea I checked thousands file Found have 3 file bitmasks still use old version bitmasks a Although it is correct (Router type properties) But if follow new version bitmask, they should is 2 (Router type)

3_7844.pcap It seems should is bitmask " *80 "

Please check a0.zip

[ZerBea]

Thanks for reporting this. Please try latest commit.

[LLH-l]

If a file packet is confirmed BE type, then all conversion hash bitmasks should use " 4 " But now it behavior no e.g... 0_(1179).cap bitmasks BE type

WPA*02...........*82
WPA*02...........*80
WPA*02...........*42

It should be like this Each a hash bitmasks should be "4" , mark router type in each hash

WPA*02...........*42
WPA*02...........*40
WPA*02...........*42

LE and BE.zip

[ZerBea]

That is not feasible. To look "in the future" several additional stages are mandatory which will make hcxpcapngtool incredible slow. This should explain why. We take the dump file you mentioned above as example:

$ tshark -r '0_(1179).cap' -Y "eapol" -T fields -e frame.time -e wlan_rsna_eapol.keydes.msgnr -e wlan_rsna_eapol.keydes.nonce
Oct 15, 2016 05:06:50.070674000 CEST    1   b2bf4541b49e3e16a7083dc8cd8e50cb2178eb4c7ec7eb2b4cef0948bd69e4e2
Oct 15, 2016 05:06:50.080382000 CEST    2   0c5f9d068be4a0d8f938c9c02701c7f71fde7f7afbd010bd7a1617a642c8e9be
Oct 15, 2016 05:06:50.082962000 CEST    3   b2bf4541b49e3e16a7083dc8cd8e50cb2178eb4c7ec7eb2b4cef0948bd69e4e2
Oct 15, 2016 05:06:50.552466000 CEST    3   b2bf4541b49e3e16a7083dc8cd8e50cb2178eb4c7ec7eb2b4cef0948c069e4e2

hcxdumptool calculate the MASSAGEPAIRs in chronological order

At the time we got an M2 (05:06:50.080382000) we got only one M1. The MP is 80 At the time we got an M3 (05:06:50.082962000) we got only one M1 and the NONCE is the same. The MP is 82 At the time we got a second M3 (05:06:50.552466000) we already got an M1 and a M3. The NONCE is different. The MP is 42.

Also it is not feasible on hcxdumtool attacks in the case when hcxdumptool spoof the AP MAC, but use a different NONCE. And it is not feasible if the AP renewed its NONCE due to massive stupid DEAUTHENTICATIONs.

Please notice, we are talking about a mechanism to handle crappy dump files. If you really want to waste your GPU time on this kind of files, I strongly recommend: select the best handshake (by hand) and feed it to hashcat - use hashcat with high nonce error corrections value or feed all handshakes to hashcat and use hashcat nonce error corrections=0

[ZerBea]

BTW: You're overestimating NC:

$ time hashcat -m 22000 42.22000 wordlist.psk
...
Started: Thu Dec 14 16:08:57 2023
Stopped: Thu Dec 14 16:08:59 2023

real    0m2,462s
user    0m0,311s
sys 0m0,385s

$ time hashcat -m 22000 80.22000 wordlist.psk
...
Started: Thu Dec 14 16:09:54 2023
Stopped: Thu Dec 14 16:09:56 2023

real    0m2,469s
user    0m0,399s
sys 0m0,372s

[LLH-l]

If want thoroughly optimize NC Minimize performance impact from NC for example

8   Oct 31, 2021 15:08:03.592593000 1   da2e38942fd15ba442521fc94f5c62d3c5a9e1015896f540603ad7ec22214ec7    f0:1b:6c:f4:be:e0
13  Oct 31, 2021 15:08:03.720318000 3   da2e38942fd15ba442521fc94f5c62d3c5a9e1015896f540603ad7ec22214ec7    f0:1b:6c:f4:be:e0
15  Oct 31, 2021 15:08:03.721543000 4   0000000000000000000000000000000000000000000000000000000000000000    14:e6:e4:50:17:1c
2313    Oct 31, 2021 15:08:14.598488000 1   da2e38942fd15ba442521fc94f5c62d3c5a9e1015896f540603ad7ec22214ec8    f0:1b:6c:f4:be:e0
2316    Oct 31, 2021 15:08:14.736621000 4   0000000000000000000000000000000000000000000000000000000000000000    14:e6:e4:50:17:1c
2322    Oct 31, 2021 15:08:15.147260000 1   da2e38942fd15ba442521fc94f5c62d3c5a9e1015896f540603ad7ec22214ec9    6c:1e:d7:45:85:a5
2323    Oct 31, 2021 15:08:15.150051000 2   f84bbdd895e94656e6100e01f85bd34ff517aac892fd75f6306f96636f83f80e    14:e6:e4:50:17:1c
2329    Oct 31, 2021 15:08:15.285550000 3   da2e38942fd15ba442521fc94f5c62d3c5a9e1015896f540603ad7ec22214ec9    6c:1e:d7:45:85:a5
4275    Oct 31, 2021 15:08:24.130233000 1   da2e38942fd15ba442521fc94f5c62d3c5a9e1015896f540603ad7ec22214eca    f0:1b:6c:f4:be:e0
4277    Oct 31, 2021 15:08:24.131410000 1   da2e38942fd15ba442521fc94f5c62d3c5a9e1015896f540603ad7ec22214eca    f0:1b:6c:f4:be:e0

When NC+8 and -8, it should skip different authentication NONCE

  Proposal skip diff authentication NONCE
da2e38942fd15ba442521fc94f5c62d3c5a9e1015896f540603ad7ec22214ec8
da2e38942fd15ba442521fc94f5c62d3c5a9e1015896f540603ad7ec22214ec7
da2e38942fd15ba442521fc94f5c62d3c5a9e1015896f540603ad7ec22214eca

Although this is ideal, but it difficult achieve

[ZerBea]

There is only one way to minimize performance impact from NC: Make sure that there is absolutely no packet loss during capturing. If you accept a packet loss you've got to live with a performance impact (in every case). Than get the best handshake and run hashcat with NC = 0

You have this choices:

1. hcxpcapngtool get best handshake or get all handshakes
2. hashcat use default NC, deactivate NC (nonce-error-corrections=0), set NC (nonce-error-corrections=x)
3. a combination of 1 and 2

Absolutely no tool can make this decision for you. That require AI. Adding AI to hcxpcapngtool or to hashcat is far beyond the scope. In other words: If you choose the automatic / default options you let hcxpcapngtool and hashcat decide what to do. If you override this by --all an nonce-error-corrections you must decide which hashes should be tested with what NC. For sure, I can add "a gray scale" with thousands of functions and options to handle every case between 1, 2 and 3, but this let the code explode and the performance impact will be huge.

For example: I run hcxpcapngtool --all & hashcat --nonce-error-corrections=0 in mode 22000 and hashcat --nonce-error-corrections=1024 in mode 22001 For me this is the best procedure to analyze dump files and to improve hcxtools. Something else may apply to you.