hcxtools
hcxtools copied to clipboard
ZerBea
feature request: add NONCE ERROR CORRECTIONS to hcxpmktool
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?
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.
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.
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.
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
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?
hcxdumptool was used to capture the traffic
the hash was converted using hcxpcapngtool -o capture_0005.pcapng
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.
Confirmed. Works in wifite2 v2.7.0 also. password recovered with both "hashcat" and "cowPatty".
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.
Please ask bitmask
*80
*a2
*c0
In "8...a...c"value, How much NONCE they will compensate
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.
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.
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.
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.
@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
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.
Data packet loss, not always in last character
Packet loss means that an entire packet got lost and not only a single byte,
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!
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
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
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
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
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 !
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.
@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
@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
@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