Distinguishing False Password Capture Message Pairs

[LLH-l]

I did an experiment with 1 fake password The AP handshake was captured while attempting to connect using a fake password

`66 Apr 10, 2023 01:39:26.512068000 1 1

68 Apr 10, 2023 01:39:26.517422000 2 1

75 Apr 10, 2023 01:39:27.512838000 1 2

77 Apr 10, 2023 01:39:27.519033000 2 2`

My question is as follows, When there are only m1m2 message pairs in the data packet, is it possible to judge whether the m1m2 message pair is true or false? But right now, there doesn't seem to be a true/false distinction between m1m2 message pairs If it is necessary to implement a true or false judgment, will it be difficult to achieve, or will misjudgment occur due to some reasons

hoped that some false password message pairs can be marked Thanks

Fake password: 123123123

[ZerBea]

This information is already implemented and explained in help menu:

bitmask of 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

$ hcxpcapngtool -o test.22000 "fake password captured AP.cap" $ cat test.22000 WPA*02*9d9843d512d23ca5304c6742f6aea49c*d4ee07441a66*7460fa8cf04a*3131*64da5631ed2a35ed3277803af2f17ba595810fa6f8aa5a5476cc3570d1d10e0c*0103007502010a0000000000000000000164bf69051f801503e8cd5cf2197df6cdf571910d9b63499813f71148b9bcb6a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*00

The MESSAGE PAIR field (containing this information) is located at the end of a WPA02 hash line: `WPA029d9843....00` 00 = M1+M2, EAPOL from M2 (challenge)

or via hcxhashtool: MP M1M2 E2.: challenge

$ hcxhashtool -i test.22000 --info=stdout
SSID.......: 11
MAC_AP.....: d4ee07441a66 (HIWIFI Co., Ltd.)
MAC_CLIENT.: 7460fa8cf04a (HUAWEI TECHNOLOGIES CO.,LTD)
VERSION....: 802.1X-2001 (1)
KEY VERSION: WPA2
REPLAYCOUNT: 1
RC INFO....: NC not required
MP M1M2 E2.: challenge
MIC........: 9d9843d512d23ca5304c6742f6aea49c
HASHLINE...: WPA*02*9d9843d512d23ca5304c6742f6aea49c*d4ee07441a66*7460fa8cf04a*3131*64da5631ed2a35ed3277803af2f17ba595810fa6f8aa5a5476cc3570d1d10e0c*0103007502010a0000000000000000000164bf69051f801503e8cd5cf2197df6cdf571910d9b63499813f71148b9bcb6a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*00

or via hashcat:

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

It is also explained (and how to filter this information) on hashcat's wiki: https://hashcat.net/wiki/doku.php?id=cracking_wpawpa2

Closed, because feature is already implemented.

[LLH-l]

@ZerBea Sorry I still have doubts The password confirms the successful connection with the AP, but after passing the test, it is still a challenge to return the information WPA*02**00 which seems to cause me to not be able to distinguish them Thanks

E.g Password: lb852852

`3015 Jan 29, 2022 12:48:55.545532000 3 2

5899 Jan 29, 2022 12:49:55.454946000 1 1

5996 Jan 29, 2022 12:49:55.569638000 3 2

7746 Jan 29, 2022 12:50:01.235534000 1 1

7756 Jan 29, 2022 12:50:01.251706000 2 1

7764 Jan 29, 2022 12:50:01.263941000 4 2 `

[ZerBea]

BTW: The example dump file was captured Today:

timestamp minimum (GMT)..................: 09.04.2023 19:39:22
timestamp maximum (GMT)..................: 09.04.2023 19:39:27

I wonder why you don't use latest hcxdumptool that distinguish during capturing (from hcxdumptool --help) between challenge and authorization:

Legend
real time display:
 R = + AP is in TX range
 P = + got PMKID
 M = + AP display:     got EAPOL M1M2M3 (AUTHORIZATION)
 M = + CLIENT display: got EAPOL M1M2 (ROGUE CHALLENGE)
 A = + AUTHENTICATION KEY MANAGEMENT PSK

[LLH-l]

@ZerBea Good,thanks I have used hcxdumptool, which is a very good tool, it can immediately detect whether the capture message is authorized However, it is necessary to accelerate its ecological popularization and improve the practicality of tools

[ZerBea]

Well, your doubts were justified. https://github.com/ZerBea/hcxtools/issues/265#issuecomment-1501121635

I try to explain why: This three MESSAGES belong to a single AUTHENTICATION sequence:

7746 Jan 29, 2022 12:50:01.235534000 1 1
7756 Jan 29, 2022 12:50:01.251706000 2 1
7764 Jan 29, 2022 12:50:01.263941000 4 2

We are able to calculate a MESSAGE PAIR from it: M1M2 == challenge The M3 is completely missing (your passive dump tool didn't received it) and we do not know if there are more frames missing. e.g. this might be possible, too:

7746 Jan 29, 2022 12:50:01.235534000 1 1 received by the passive dumptool = challenge
7756 Jan 29, 2022 12:50:01.251706000 2 1 received by the passive dumptool = challenge 
xxxx Jan 29, 2022 12:50:01.261709000 1 1 possible new AUTHENTICATION  but not received by the passive dumptool
xxxx Jan 29, 2022 12:50:01.261710000 2 1 possible new AUTHENTICATION  but not received by the passive dumptool
xxxx Jan 29, 2022 12:50:01.261206000 3 2 possible new AUTHENTICATION  but not received by the passive dumptool
7764 Jan 29, 2022 12:50:01.263941000 4 2 received by the passivedump tool, but we can't proof it because Nonce is zeroed

The M4 has a zeroed WPA Key Nonce so we disregard it:

802.1X Authentication
    Version: 802.1X-2001 (1)
    Type: Key (3)
    Length: 95
    Key Descriptor Type: EAPOL RSN Key (2)
    [Message number: 4]
    Key Information: 0x030a
    Key Length: 0
    Replay Counter: 2
    WPA Key Nonce: 0000000000000000000000000000000000000000000000000000000000000000
    Key IV: 00000000000000000000000000000000
    WPA Key RSC: 0000000000000000
    WPA Key ID: 0000000000000000
    WPA Key MIC: 515b9f803496fc7cbdc9f50f5e394eeb
    WPA Key Data Length: 0

While the dumptool you have used is satisfied (even though the M3 is missing in this authentiication sequence), hcxdumptool detect that is is not present and request it agiain. As a result a complete authentication sequence is stored.

[ZerBea]

However, it is necessary to accelerate its ecological popularization and improve the practicality of tools. I fully agree - that's why this feature is already added in hcxdumptool, hcxpcapngtool, hcxhashtool and hashcat.

[LLH-l]

Using incorrect password capture handshake After converting to 22000 format WPA*02**00

Use the correct password to capture the handshake After converting to 22000 format WPA*02**00

At this point, how do I distinguish between their correct or incorrect hashes WPA*02*00 WPA02**00

[ZerBea]

There is no chance if the M3 is missing and the M4 has a zeroed WPA KEY NONCE in the dump file. hcxpcapngtool is not able to calculate an AUTHORIZATION MESSAGE PAIR. M1 & M2 = CHALLENGE M2 & M3 = AUTHORIZATION M3 & M4 = CONFIRMATION If the M4 has a not zeroed WPA KEY NONCE, hcxpcapngtool can calculate the confirmation by this MESSAGE PAIR M1 & M4 = AUTHORIZATION and CONFIRMATION hcxdumptool will convert this handshake

Your example:

7746 Jan 29, 2022 12:50:01.235534000 1 1
7756 Jan 29, 2022 12:50:01.251706000 2 1
7764 Jan 29, 2022 12:50:01.263941000 4 2 (M4 has a zeroed WPA KEY NONCE: 0000000000000000000000000000000000000000000000000000000000000000

M1 & M2 = CHALLENGE M2 & M3 = impossible to calculate a MESSAGE PAIR because M3 not stored to dump file M3 & M4 = impossible to calculate a MESSAGE PAIR because M3 not stored to dump file M1 & M4 = impossible to calculate a MESSAGE PAIR because M4 has a zeroed WPA KEY NONCE hcxdumptool will convert only the CHALLENGE. It is feasible to use the MIC from the M4 with the zeroed WPA KEY NONCE and the EAPOL DATA from the M2, but this is like a fortuneteller reading chicken bones, because we do not know how many EAPOL frames are missed by the passive dumptool. So hcxpcapngtool will not do this. And even though if I decide to add it, hcxcat can't do it. Take a look at the WPA02 hash line: Mandatory: MAC_AP MAC_CLIENT ESSID MIC ( (is part of M2) NONCE_AP ( (is part of M1) NONCE_CLIENT (is part of M2) EAPOL_M2 There is no field to add a second MIC,because it doesn't make sense because the compare time will be doubled!!!

Now you have 2 choices: The PSK of the CHALLENGE belong to the NETWORK. The PSK of the CHALLENGE does not belong to the NETWORK - you have to recapture a new handshake.

[LLH-l]

@ZerBea Hmm. thanks difficult to determine whether a message pair with only 1m2 is true or false Only by re capturing the m2m3 authorization message pairs

I filtered some files and found that each one contained an m2m3 authorization message pairs But why only generate m1m2 message pairs and abandon those m2m3 authorization message pairs ?

Under the condition of having m1m2 and m2m3, priority should be given to selecting the m2m3 authorization message pair The m2m3 authorization message pairs, time intervals, and replay counters all meet various conditions, and the quality should be very good This makes me very confused

1076 Nov 14, 2015 15:37:53.100884000 1 1 1078 Nov 14, 2015 15:37:53.102918000 2 1 1509 Nov 14, 2015 15:37:54.183826000 1 1 1511 Nov 14, 2015 15:37:54.186374000 2 1 1513 Nov 14, 2015 15:37:54.189460000 3 2

[ZerBea]

In your feature request you mentioned that the time between two EAPOL MESSAGEs is veryy important: https://github.com/ZerBea/hcxtools/issues/250 and I fully agreed - lowest time gap is the on highest rank because we don't know if packets from the passive dumper are missing. I already mentioned that here: Running default option, hcxpcapngtool will always take. the lowest measured values to make sure to convert. https://github.com/ZerBea/hcxtools/issues/250#issuecomment-1493736158

By default option hcxpcapngtool will convert the best (lowest time gap) MESSAGE PAIR. example: 0_(670).cap

1250 13:42:21,082960 1 1 1256 13:42:21,086008 2 1 2801 13:42:28,229902 1 1 2809 13:42:28,241658 2 1 2811 13:42:28,245774 3 2 2813 13:42:28,247806 4 2

M1M2 CHALLENGE == lowest time gap == highest ranking 1250 13:42:21,082960 1 1 1256 13:42:21,086008 2 1

$ hcxpcapngtool -o test.22000 "/tmp/0_(670).cap"
$ cat test.22000
WPA*02*576f76532c5da9cf68ed88ef310b529c*bc4699515a5c*d033112e2d51*54502d4c494e4b5f35413543*5c80725f70fe97dc541a4fdd453faa35fa2f58066ff6b1dcfa5db1cab03c7663*0203007502010a00100000000000000001996034fbd3ecb04c7d9c098d4c6cce4c72626cefb3bd621277b4425f12fbb413000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020c00*a0

If you would like to distinguish you have to convert more hashes than the best one:

$ hcxpcapngtool -o test.22000 "/tmp/0_(670).cap" --all
$ cat test.22000
WPA*02*576f76532c5da9cf68ed88ef310b529c*bc4699515a5c*d033112e2d51*54502d4c494e4b5f35413543*5c80725f70fe97dc541a4fdd453faa35fa2f58066ff6b1dcfa5db1cab03c7663*0203007502010a00100000000000000001996034fbd3ecb04c7d9c098d4c6cce4c72626cefb3bd621277b4425f12fbb413000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020c00*a0
WPA*02*90d1ad0fae77b2bd8ee651ba00a52292*bc4699515a5c*d033112e2d51*54502d4c494e4b5f35413543*5c80725f70fe97dc541a4fdd453faa35fa2f58066ff6b1dcfa5db1cab03c7664*0203007502010a00100000000000000001bbf7efde8109fbdbef6c7b60db0393f1607703baf11788bc22f1e8725e3578d7000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020c00*a2
WPA*02*90d1ad0fae77b2bd8ee651ba00a52292*bc4699515a5c*d033112e2d51*54502d4c494e4b5f35413543*5c80725f70fe97dc541a4fdd453faa35fa2f58066ff6b1dcfa5db1cab03c7664*0203007502010a00100000000000000001bbf7efde8109fbdbef6c7b60db0393f1607703baf11788bc22f1e8725e3578d7000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020c00*a0

Now you can use what ever you want:

$ hcxhashtool -i test.22000 --info=stdout
SSID.......: TP-LINK_5A5C
MAC_AP.....: bc4699515a5c (TP-LINK TECHNOLOGIES CO.,LTD.)
MAC_CLIENT.: d033112e2d51 (Apple, Inc.)
VERSION....: 802.1X-2004 (2)
KEY VERSION: WPA2
REPLAYCOUNT: 1
RC INFO....: NC suggested
MP M1M2 E2.: challenge
MIC........: 576f76532c5da9cf68ed88ef310b529c
HASHLINE...: WPA*02*576f76532c5da9cf68ed88ef310b529c*bc4699515a5c*d033112e2d51*54502d4c494e4b5f35413543*5c80725f70fe97dc541a4fdd453faa35fa2f58066ff6b1dcfa5db1cab03c7663*0203007502010a00100000000000000001996034fbd3ecb04c7d9c098d4c6cce4c72626cefb3bd621277b4425f12fbb413000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020c00*a0

SSID.......: TP-LINK_5A5C
MAC_AP.....: bc4699515a5c (TP-LINK TECHNOLOGIES CO.,LTD.)
MAC_CLIENT.: d033112e2d51 (Apple, Inc.)
VERSION....: 802.1X-2004 (2)
KEY VERSION: WPA2
REPLAYCOUNT: 1
RC INFO....: NC suggested
MP M2M3 E2.: authorized
MIC........: 90d1ad0fae77b2bd8ee651ba00a52292
HASHLINE...: WPA*02*90d1ad0fae77b2bd8ee651ba00a52292*bc4699515a5c*d033112e2d51*54502d4c494e4b5f35413543*5c80725f70fe97dc541a4fdd453faa35fa2f58066ff6b1dcfa5db1cab03c7664*0203007502010a00100000000000000001bbf7efde8109fbdbef6c7b60db0393f1607703baf11788bc22f1e8725e3578d7000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020c00*a2

SSID.......: TP-LINK_5A5C
MAC_AP.....: bc4699515a5c (TP-LINK TECHNOLOGIES CO.,LTD.)
MAC_CLIENT.: d033112e2d51 (Apple, Inc.)
VERSION....: 802.1X-2004 (2)
KEY VERSION: WPA2
REPLAYCOUNT: 1
RC INFO....: NC suggested
MP M1M2 E2.: challenge
MIC........: 90d1ad0fae77b2bd8ee651ba00a52292
HASHLINE...: WPA*02*90d1ad0fae77b2bd8ee651ba00a52292*bc4699515a5c*d033112e2d51*54502d4c494e4b5f35413543*5c80725f70fe97dc541a4fdd453faa35fa2f58066ff6b1dcfa5db1cab03c7664*0203007502010a00100000000000000001bbf7efde8109fbdbef6c7b60db0393f1607703baf11788bc22f1e8725e3578d7000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020c00*a0

Nearly all this old dump files need manual intervention (if you would like to distingush between them).

[ZerBea]

Please take a closer look at the dump file mentioned above:

1250    13:42:21,082960 bc:46:99:51:5a:5c   d0:33:11:2e:2d:51   EAPOL   133 Key (Message 1 of 4)
1251    13:42:21,082934     bc:46:99:51:5a:5c (RA)  802.11  10  Acknowledgement, Flags=........
1252    13:42:21,084544 bc:46:99:51:5a:5c   d0:33:11:2e:2d:51   802.11  26  Deauthentication, SN=280, FN=0, Flags=........
1253    13:42:21,086080 bc:46:99:51:5a:5c   d0:33:11:2e:2d:51   802.11  32  Deauthentication, SN=276, FN=0, Flags=........, SSID=Wildcard (Broadcast)
1254    13:42:21,086006 d0:33:11:2e:2d:51   bc:46:99:51:5a:5c   802.11  33  Action, SN=24, FN=0, Flags=........, Dialog Token=141
1255    13:42:21,086032     d0:33:11:2e:2d:51 (RA)  802.11  10  Acknowledgement, Flags=........
1256    13:42:21,086008 d0:33:11:2e:2d:51   bc:46:99:51:5a:5c   EAPOL   155 Key (Message 2 of 4)
1257    13:42:21,086544     d0:33:11:2e:2d:51 (RA)  802.11  10  Acknowledgement, Flags=........

The attack tool (my suspect is aireplay-ng) injected DEAUTHENTICATION frames directly into the AUTHENTICATION sequence. hcxpcapngtool detected this and show:

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.

I would not waste my GPU time on that.

Funny - for me it looks like the attacker didn't want to get a handshake:

1258    13:42:21,087104 d0:33:11:2e:2d:51   bc:46:99:51:5a:5c   802.11  26  Deauthentication, SN=281, FN=0, Flags=........
1259    13:42:21,088590 bc:46:99:51:5a:5c   bc:46:99:51:5a:5c   802.11  33  Action, SN=1988, FN=0, Flags=....R..., Dialog Token=141
1260    13:42:21,090688 bc:46:99:51:5a:5c   d0:33:11:2e:2d:51   802.11  26  Deauthentication, SN=282, FN=0, Flags=........
1261    13:42:21,092174     d0:33:11:2e:2d:51 (RA)  802.11  10  Acknowledgement, Flags=........
1262    13:42:21,093248 d0:33:11:2e:2d:51   bc:46:99:51:5a:5c   802.11  26  Deauthentication, SN=283, FN=0, Flags=........

Neither the AP nor the CLIENT have had the chance to complete the AUTHENTICATION... .. and injecting DEAUTHENTICATION frames went on and on and on...

[ZerBea]

Procedure on this dump files (packet loss, DEAUTHENTICATION frames injected into AUTHENTICATION sequence, ...): $ hcxpcapngtool -o test.22000 "/tmp/0_(670).cap" --all $ hcxhashtool -i all.22000 -o authorized.22000 --authorized

This is not handled by default options, because it will make hcxpcapngtool slow and more complicated. Linux philosophy: Write programs that do one thing and do it well. (hcxpcapngtool -> convert best or convert all) Write programs to work together. (hcxhashtool or bash tools -> filter what you want) Write programs to handle text streams, because that is a universal interface. (well, hc22000 format is a text stream) If default is not good enough for you, you must use options (dependent on the quality of your dump files) and additional filtering methods (tools).

[LLH-l]

OK thanks Yeah, The time interval between message pairs is very important

[ZerBea]

It is the only constant we can rely on, because we do not know if packets got lost during capturing. But we can assume that the AP renew its EAPOL values and timers if it receive a DEAUTHENTICATION frame, because exactly this is the purpose of this kind of frames. ASSOCIATIONREQUEST ASSOCIATIONRESPONSE M1 DEAUTHENTICATION DEAUTHENTICATION M2

M2 may belong to the AUTHENTICATION sequences started by the ASSOCIATIONREQUEST but it is also possible that it doesn't belong to it. But anyway, it is not a good idea to inject DEAUTHENTICATIONs this way.

[LLH-l]

7746 Jan 29, 2022 12:50:01.235534000 1 1 7756 Jan 29, 2022 12:50:01.251706000 2 1 7764 Jan 29, 2022 12:50:01.263941000 4 2

@ZerBea Although it cannot generate M1M4,

But there is another situation that deserves attention I found many packets containing m1m2m4 for testing, and the recovered password is basically correct Although M3 was not returned, M4 was obtained, and M1M2M4 arrived within the same time group, which basically confirms that the PSK recovered by this hash is correct So, this transformation hash should be considered (authorized) WPA**02

contrary, If there is only M1M2 in the entire data packet without any other messages, it is likely a forged password, and this format is the correct way WPA**00

If are not willing to treat such data packets as (authorized), can use another special code to represent the 22000 format of such data packets after conversion, which can make everyone aware of its internal data structure E.g WPA**04 or WPA**03

[ZerBea]

You mentioned it here: I found many packets containing m1m2m4 for testing, and the recovered password is basically correct I full agree, but it is hashcat (a powerfull GPU hash cracking tool) that detect that tha PSK is basically correct.

hcxdumptool is not a hash cracker. At time of conversation it doesn't know that the hash is correct. It read the dump file and calculate MESSAGE PAIRS from present(!) EAPOL MESSAGE PAIRS. It the EAPOL M3 is not present, there is absolutely no way to calculate an AUTHORIZED MESSAGE PAIR. If the EAPOL M4 is not present, there is absolutels no way to calculate a CONFIRMATION MESSAGE PAIR.

Remember the 4 way handshake: AUTHENTICATION ASSOCIATION M1 RC = 0 M2 RC = 0 M3 RC = 1 M4 RC = 1

If the AUTHENTICATION is not successful, the next AUTHENTICATION SEQUENCE start: AUTHENTICATION ASSOCIATION M1 RC = 0 M2 RC = 0 M3 RC = 1 M4 RC = 1

some APs increment RC some APs increment last byte of ANONCE some APs do both some APs do nothing

But how do we know that an M3 belong to the same AUTHENTICATION SEQUENCE as a M1? We compare the ANONCE: M1 ANONCE must be M3 ANONCE

$ tshark -r wpa-Induction.pcap -Y "eapol" -T fields -e frame.number -e _ws.col.Time -e wlan.ra -e wlan.ta -e wlan_rsna_eapol.keydes.msgnr -e eapol.keydes.replay_counter -e wlan_rsna_eapol.keydes.nonce
87  06:14:51,509261 00:0d:93:82:36:3a   00:0c:41:82:b2:55   1   0   3e8e967dacd960324cac5b6aa721235bf57b949771c867989f49d04ed47c6933
89  06:14:51,510267 00:0c:41:82:b2:55   00:0d:93:82:36:3a   2   0   cdf405ceb9d889ef3dec42609828fae546b7add7baecbb1a394eac5214b1d386
92  06:14:51,515265 00:0d:93:82:36:3a   00:0c:41:82:b2:55   3   1   3e8e967dacd960324cac5b6aa721235bf57b949771c867989f49d04ed47c6933
94  06:14:51,515281 00:0c:41:82:b2:55   00:0d:93:82:36:3a   4   1   0000000000000000000000000000000000000000000000000000000000000000

[ZerBea]

The MESSAGE PAIR field exactly show which parts of the 4way handshake are used to calculate the MESSAGE PAIR

 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

It does not show which EAPOL MESSAGES are present in a dump file. Every thing else is like reading from chicken bones.

[ZerBea]

Your example: 7746 Jan 29, 2022 12:50:01.235534000 1 1 7756 Jan 29, 2022 12:50:01.251706000 2 1 7764 Jan 29, 2022 12:50:01.263941000 4 2

We walk through the conditions that must be met: step 1: 7746 Jan 29, 2022 12:50:01.235534000 1 1 = M1 present

step 2: 7756 Jan 29, 2022 12:50:01.251706000 2 1 = M2 present

step 3: M1 RC == M2 RC if both are in EAPOLTIME GAP, calculate MESSAGE PAIR M1M2 (CHALLENGE) and set MESSAGE PAIR FIELD to 00

step 4: 7764 Jan 29, 2022 12:50:01.263941000 4 2 check SNONCE it is zeroed and we can't calculate M1M4 MESSAGE PAIR

Conclusion: There is only one MESSAGE PAIR M1M2 and that is a CHALLENGE MESSAGE PAIR. hcxpcapngtool is exactly doing what is expected.

BTW: If the M3 is missing, it is possible that other EAPOL frames are missing, too! Who will know how many other packets are missing, too.

[ZerBea]

At a last point: Check the timegap between your example 7756 Jan 29, 2022 12:50:01.251706000 2 1 7764 Jan 29, 2022 12:50:01.263941000 4 2 = 12235 msec

89 06:14:51,510267 00:0c:41:82:b2:55 00:0d:93:82:36:3a 2 0
94 06:14:51,515281 00:0c:41:82:b2:55 00:0d:93:82:36:3a 4 1
= 5014 msec

12235 msec = twice more At time of conversion, you can't be sure that 7764 Jan 29, 2022 12:50:01.263941000 4 2 belong to the same AUTHENTICATION SEQUENCE It is possible that an entire AUTHENTICATION SEQUENCE was not captured by the passive dumper.

[ZerBea]

Another example:

$ tshark -r wpa1-gtk-rekey.pcapng.gz -Y "eapol" -T fields -e frame.number -e _ws.col.Time -e wlan.ra -e wlan.ta -e wlan_rsna_eapol.keydes.msgnr -e eapol.keydes.replay_counter -e wlan_rsna_eapol.keydes.nonce
13  11:17:31,537651230  38:78:62:0c:e7:d2   34:13:e8:62:a3:40   1   1   f94dd68fdb9ffe3d93af9533189058b98beb565795c2bb6255d4ee14c68e4a03
14  11:17:31,550249664  34:13:e8:62:a3:40   38:78:62:0c:e7:d2   2   1   88c3c107fd1ecbbf837168e70f233acb6d60753fce3eea0eda063965b0e39209
15  11:17:31,552998153  38:78:62:0c:e7:d2   34:13:e8:62:a3:40   3   2   f94dd68fdb9ffe3d93af9533189058b98beb565795c2bb6255d4ee14c68e4a03
18  11:17:31,742584045  38:78:62:0c:e7:d2   34:13:e8:62:a3:40   3   3   f94dd68fdb9ffe3d93af9533189058b98beb565795c2bb6255d4ee14c68e4a03
19  11:17:31,744707595  38:78:62:0c:e7:d2   34:13:e8:62:a3:40   3   3   f94dd68fdb9ffe3d93af9533189058b98beb565795c2bb6255d4ee14c68e4a03
20  11:17:31,746555573  34:13:e8:62:a3:40   38:78:62:0c:e7:d2   4   2   0000000000000000000000000000000000000000000000000000000000000000
21  11:17:31,749006084  34:13:e8:62:a3:40   38:78:62:0c:e7:d2   4   3   0000000000000000000000000000000000000000000000000000000000000000

we simulate a packet loss between M2 and M4:

13  11:17:31,537651230  38:78:62:0c:e7:d2   34:13:e8:62:a3:40   1   1
14  11:17:31,550249664  34:13:e8:62:a3:40   38:78:62:0c:e7:d2   2   1
20  11:17:31,746555573  34:13:e8:62:a3:40   38:78:62:0c:e7:d2   4   2
21  11:17:31,749006084  34:13:e8:62:a3:40   38:78:62:0c:e7:d2   4   3

Shall we really confirm such a crap?

[LLH-l]

Can the identity of M4 be confirmed to belong to the M1M2 device sequence by checking its MAC device

If m1m2m4 is detected and they arrive at the message within the same time and meet their conversion conditions, the following new bitmask identification is used to classify these hashes, so that everyone can understand their pre conversion packet structure

We can add another bitmask expression to this type of data packet, bitmask of message pair field: E.g 014 = M1+M2+M4 WPA**03 Or WPA**04

[ZerBea]

Can the identity of M4 be confirmed to belong to the M1M2 device sequence by checking its MAC device

We can add another bitmask expression to this type of data packet, No.

Another example. We simulate a packet loss:

1   16:16:43,519224 1   23
2   16:16:43,520945 2   23
3   16:16:43,547482 4   24

According to your suggestion, this packet this is a confirmed handshake.

Now we take a look at the monitor interface that captured all packets:

1   16:16:43,519224 1   23
2   16:16:43,520945 2   23
3   16:16:43,526387 2   23
4   16:16:43,538720 3   24
5   16:16:43,547482 4   24

Wow, there is another M2 and a M3 between the EAPOL MESSAGES.

We take a closer look at them:

1   16:16:43,519224 1   23  00000000000000000000000000000000    00073d679376a07f283b97128b3ef670d8ac3666fcacc8bef9797d4125ec15fc
2   16:16:43,520945 2   23  f2e72440eb97b022a60ae6ed7910ccd3    57cb758e4132a01b6054784d519aea336b290a0bbf2472474bc6fdcf35e5742a
3   16:16:43,526387 2   23  5eed8e0a1dadfab4e0550cb2407a84f6    57cb758e4132a01b6054784d519aea336b290a0bbf2472474bc6fdcf35e5742a
4   16:16:43,538720 3   24  7607570c7c2f6ac95ae5274531cfc0b6    00073d679376a07f283b97128b3ef670d8ac3666fcacc8bef9797d4125ec15fc
5   16:16:43,547482 4   24  07c7e02f03237403104eb9c620a80d72    0000000000000000000000000000000000000000000000000000000000000000

Again wow: packet 1 and 2 do not belong to the same AUTHENTICATION sequence as packet 3,4,5 packet 2, 3, 4 belong to the same AUTHENTICATION sequence - but packet 3 and 4 are not captured by the passive dumper.

Exactly this is the reason why hcxpcapngtool convert only what is present and doesn't read it from chicken bones.

[ZerBea]

so that everyone can understand their pre conversion packet structure The structure is absolutely clear: THE MESSAGE PAIR field give an exact information what MESSAGE PAIR is converted. Not more and not less.

If a M3 is not present, there is no AUTHENTICATED MESSAGE PAIR If a M4 is zeroed, we can't know if it belongs to the same AUTHENTICATION SEQUENCE as M1 and M2.

If a M4 is not zeroed, we can compare the SNONCE to the SNONCE of the M2:

1   05:27:47,145747 1   1   00000000000000000000000000000000    8578043802f68ed191887a2da9829af12f6a84357780b6725bc95620714c69aa
2   05:27:47,149476 2   1   9b08a67c973ce9fff4226b69d551c583    86050bae2d519d886a2341c7494625feb99ed11f69fec5ac8d4732eba4ab6410
3   05:27:47,153964 4   2   d39a2a70ed363333a98fd4d19daca5c5    86050bae2d519d886a2341c7494625feb99ed11f69fec5ac8d4732eba4ab6410

This is a CONFIRMED AUTHENTICATION.

[ZerBea]

According to your suggestion: 014 = M1+M2+M4 It blow up the hash line:

from:
WPA*02*MIC*MAC_AP*MAC_CLIENT*ESSID*NONCE_AP*EAPOL_CLIENT*MESSAGEPAIR
to
WPA*03*MIC_M2*MIC_M4*MAC_AP*MAC_CLIENT*ESSID*NONCE_AP*EAPOL_CLIENT_M2*EAPOL_CLIENT_M4*MESSAGEPAIR

How should hashcat calculate the PSK? Which MIC should hashcat take? The MIC of M2? Or the MIC of M4? Or the MIC of both?

Please notice that every calculation take GPU time. Doing this twice, it take twice the time. On a big word list 2 hours, instead of one hour.

[ZerBea]

To make that absolutely clear: The only way to confirm a PSK is to to compare the result of PBKDF2 to the PMKID or to the MIC. That is what a GPU hash cracker (hashcat and JtR) is doing - but not a conversion tool (hcxpacpngtool). If you want to confirm a CHALLENGE this can only be done by the MIC of the M2. If you want to confirm a AUTHORIZATION this can only be done by the MIC of the M3 (if the ANONCE of the M1 is the same as the ANONCE of the M3, we can take the MIC of the M2 to confirm the AUTHORIZATION). If you want to confirm an EAPOL M4 this can only be done by the MIC of the M4 (neither implemented in hashcat nor JtR if SNONCE of M4 is zeroed).

PMKID: Compute PMK for this passphrase using: PMK = PBKDF2(HMAC−SHA1, PSK, SSID, 4096, 256) Compute PMKID from the generated PMK using: PMKID = HMAC-SHA1-128(PMK, "PMK Name" | MAC_AP | MAC_STA)

MIC: Compute PMK for this Passphrase using: PMK = PBKDF2(HMAC−SHA1, PSK, SSID, 4096, 256) Derivate PTK from the assumed PMK using: PTK = Hash(PMK||ANonce||SNonce||MAC_AP||MAC_Client) Use generated PTK to compute a MIC for packet 2,3 or 4 of the captured handshake If computed MIC = MIC of the captured packet => PSK guess is correct

There is no (absolutely no!) other way to do this.

[LLH-l]

@ZerBea

It seems that it can be added to the end of the hash Because these data are still important references Through it, can directly see the packet structure

E.g WPA*02*00 13.04.2023 21:59:25 5500 M1M2 WPA*02*00 13.04.2023 21:59:25 5500 M1M2M4

[ZerBea]

Please notice the EAPOL-key timeout can be every value up to 1 second! There is no fixed value. It can be everything between 0.001msec an 999msec: 0.001 ms between M1M2 and M4. 0.01 ms between M1M2 and M4. 0.1 ms between M1M2 and M4. 1 ms between M1M2 and M4. 10 ms between M1M2 and M4. 100 ms between M1M2 and M4. 999 ms between M1M2 and M4.

If there is a deauthentication, a disassociation, a new authentication or a reassociation or an entire new 4way handshake between M1M2 and M4 you end up in an invalid MASSAGE PAIR (impossible to calculate a valid PSK from it). Instead on wasting GPU time on dump files with lost packets it is a thousand times better to recapture and get at least M1M2M3!

[LLH-l]

@ZerBea Yeah ... If there is only m1m2 in the entire data packet, re capturing is the best choice

However, if m1m2m4 is captured and they arrive at the same time, it meets the conversion hash condition,

In theory, this type of message pair is more reliable than only containing m1m2, and although various situations may occur during the capture process, it can still be considered a reliable handshake (at least more so than only m1m2)

So, how can we identify and classify these message hashes containing m1m2m4? But it doesn't seem like this feature is currently available

m1m2 Hash
WPA*00
m1m2m4 Hash
WPA*00

I have conducted some experiments and I would like to share my personal views If the wrong PSK is used to connect to the AP, no matter how the behavior is operated during the capture process, it is impossible to obtain M3 or M4 messages

At the same time, the m1m2m4 situation was captured, and due to various reasons that occurred during the capture process, although there was no m3, at least m4 was returned, If the handshake did not occur, it is impossible for it to receive the m4 message, even if the authentication is revoked during the capture process, which may be caused by the capture tool and not the autonomous behavior of the AP device. Therefore, treating m1m2m4 can still be regarded as an authorization handshake

[ZerBea]

However, if m1m2m4 is captured and they arrive at the same time, it meets the conversion hash condition, No, it does not. If a CLIENT does not receive an EAPOL M3 from the AP it will not(!) establish the keys.

If hcxpcangtool does not receive an EAPOL M3 it will not confirm the CHALLENGE.

Message 1: AP sends to the client his ANONCE. Now the client has everything he needs to create the PTK because he got the ANONCE, it was the only thing that was missing for him.

Message 2: The client sends to the AP his SNONCE with a MIC, the MIC is mainly for the AP to recognize that this message is realy from this client, its like a signature (a high level algorithm signature). Now, after the AP got the message he has everything he needs to create the PTK and that is what he does.

Message 3: The AP sends to the client the GTK because he is going to be his new client. The client get the GTK and install it.

Message 4: The client sends to the AP that everything is OK and installed.

If the wrong PSK is used to connect to the AP, no matter how the behavior is operated during the capture process, it is impossible to obtain M3 or M4 messages

For sure this is possible and can't be detected on packet loss: M1M2 challenge with wrong PSK "12345678" followed by M1M2M3M4 with correct PSK "abcdefgh" the time line looks like this: 1 M1 RC 0 2 M2 RC 0 3 M1 RC 0 4 M2 RC 0 5 M3 RC 1 6 M4 RC 1 zeroed EAPOL M2 and M4 came from the same CLIENT that has a faulty entry in its wpa_SUPPLICANT.conf: Twice the same ESSID but with different PSKs

now packet 3,4 and 5 got lost: 1 M1 RC 0 2 M2 RC 0 6 M4 RC 1 zeroed is this still an authorized handshake ??? CHALLENGE is PSK "12345678" CONFRIMATION is PSK "abcdefgh" All the conditions you mentioned are met, but the MIC of M4 can't be verified with the PTK of M1M2.

...arrive at the same time Please tell me the exact time!

Therefore, treating m1m2m4 can still be regarded as an authorization handshake Neither an AP nor a CLIENT will accept m1m2m4. If EAPOL M3 is missing, the connection will be rejected. Why should hcxpcapngtool accept it?

If you really need M1M2M4 feature (MESSAGE TRIPLE), please add a feature request to hashcat to calculate the PTK from M1M2 and compare it to the MIC of M4. If hashcat add this feature, hcxpcapngtool will convert this MESSAGE TRIPLE.

Please notice: It is very difficult to calculate a valid MESSAGE PAIR. But it's much harder to calculated a valid MESSAGE TRIPLE. The possibility to calculate an invalid MESSAGE TRIPLE in case of a packet loss increases exponentially.

[LLH-l]

@ZerBea I recommend you to give them advice Avoid discussing this topic too fiercely, let's end here very much you explanation Thanks....

[LLH-l]

@ZerBea I still suggest in the following situation If the time interval between message pairs is (<500 milliseconds) Priority should be given to converting messages containing three combinations of m1m2m4, as it is more reliable than combining only m1m2 messages In fact, this situation is likely to occur E.g

89247   Jul 19, 2020 22:05:14.397322000     1   5
89261   Jul 19, 2020 22:05:14.410123000     1   5
89264   Jul 19, 2020 22:05:14.420353000     2   5

186360  Jul 19, 2020 22:28:51.409611000     1   3
186363  Jul 19, 2020 22:28:51.431098000     2   3
186368  Jul 19, 2020 22:28:51.444929000     4   4

Confirm connecting to AP PSK : del

[ZerBea]

First of all please notice: hcxpcapngtool is not(!) a hash cracking tool!!!!!!!! At time of converting the MESSAGE PAIRS it does not(!) know the correct PSK. I'll check the ranking/priority , but I disregard this comment completely: Confirm connecting to AP PSK : yzuvukge

If I understand it right: If an M1M2 and an M1M2M4 is inside the dump file, it should convert only M1M2M4 and disregard M1M2 If only M1M2 is inside the dump file, it should convert M1M2.

Please notice that the MESSAGE PAIR FIELD in both cases will be "WPA02.....*00" because only M1M2 is converted! WPA Key nonce of M4 is zeroed so we can not convert a M1M4 MESSAGE PAIR: WPA Key Nonce: 0000000000000000000000000000000000000000000000000000000000000000 If you take a look at the converted hash line, you can't distinguish between M1M2 and M1M2M4!!!! This is only possible if we have the PSK!!!!

Please notice (important) that the AP renewed its EAPOL TIMERS and EAPOL values between 89264 and 186360 REPLAYCOUNT on AUTHENTICATION SEQUENCE 89247 = 5 missed AUTHENTICATION SEQUENCES 1,2 and 3 between 22:05:14.420353000 and 22:28:51.409611000 REPLAYCOUNT on AUTHENTICATION SEQUENCE 89247 = 3

...as it is more reliable than combining only m1m2 messages No, hashcat is able to reuse PBKDF2: calculate PMK once and compare it to all MICs of all MESSAGEPAIRs

BTW: Its much more reliable to use a tool that make sure to capture an EAPOL M3

[ZerBea]

bitmask of 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

But we have a reserved field.Maybe we can use for this purpose: bit 3 = 1 = M1M2M4 detected. I have to talk about this with Atom from hashcat.

[ZerBea]

BTW: You should know that hcxdumptool/hcxtools is not focused on cracking a single NETWORK! You should also know that hcxpcapngtool is designed to work together with hcxdumptool and hashcat/JtR (and not with passive dumpers). It is also not focused on ACCESSPOINTs. In both cases I recommend to use aircrack-ng!

It is focused to get all PSKs from the entire wpa_supplicant.conf of a CLIENT. Adding your request and using it as default, this capability will get lost!

Does the M1M2M4 problem appear on hcxdumptool (latest git head) pcapng dump files, too?

[LLH-l]

@ZerBea If an M1M2 and an M1M2M4 is inside the dump file, it should convert only M1M2M4 and disregard M1M2 If only M1M2 is inside the dump file, it should convert M1M2. Yeah, Very accurate

Does the M1M2M4 problem appear on hcxdumptool (latest git head) pcapng dump files, too? There should also be a possibility of this happening, but I have not conducted a large-scale inspection of it

But we have a reserved field.Maybe we can use for this purpose: bit 3 = 1 = M1M2M4 detected. I have to talk about this with Atom from hashcat. Good

[ZerBea]

Just tested it on haschat: converted all MESSAGE PAIRS converted M1M2M4 MESSAGE PAIR

all:

$ time hashcat -m 22000 all.22000 -a3 yzuvukge
hashcat (v6.2.6-397-g7a90a3a36) starting
...
98dc6620bcb4bd2b6644950b5172a6d6:f4a59d3a46b4:c81451073925:ChinaNet-LaaS:yzuvukge

Session..........: hashcat
Status...........: Exhausted
Hash.Mode........: 22000 (WPA-PBKDF2-PMKID+EAPOL)
Hash.Target......: all.22000
Time.Started.....: Sat Apr 15 10:04:57 2023 (0 secs)
Time.Estimated...: Sat Apr 15 10:04:57 2023 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Mask.......: yzuvukge [8]
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:       14 H/s (0.77ms) @ Accel:8 Loops:128 Thr:512 Vec:1
Recovered........: 1/2 (50.00%) Digests (total), 1/2 (50.00%) Digests (new)
Progress.........: 1/1 (100.00%)
Rejected.........: 0/1 (0.00%)
Restore.Point....: 1/1 (100.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:1-3
Candidate.Engine.: Device Generator
Candidates.#1....: yzuvukge -> yzuvukge
Hardware.Mon.#1..: Temp: 48c Fan: 33% Util: 89% Core:1835MHz Mem:5005MHz Bus:16

Started: Sat Apr 15 10:04:55 2023
Stopped: Sat Apr 15 10:04:58 2023

real    0m2,909s
user    0m0,630s
sys 0m0,600s

M1M2M4:

$ time hashcat -m 22000 m1m2m4.22000 -a3 yzuvukge
hashcat (v6.2.6-397-g7a90a3a36) starting
...
98dc6620bcb4bd2b6644950b5172a6d6:f4a59d3a46b4:c81451073925:ChinaNet-LaaS:yzuvukge

Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 22000 (WPA-PBKDF2-PMKID+EAPOL)
Hash.Target......: m1m2m4.22000
Time.Started.....: Sat Apr 15 10:06:58 2023 (0 secs)
Time.Estimated...: Sat Apr 15 10:06:58 2023 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Mask.......: yzuvukge [8]
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:       24 H/s (1.46ms) @ Accel:8 Loops:256 Thr:512 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....: yzuvukge -> yzuvukge
Hardware.Mon.#1..: Temp: 60c Fan: 37% Util: 96% Core:1822MHz Mem:5005MHz Bus:16

Started: Sat Apr 15 10:06:57 2023
Stopped: Sat Apr 15 10:07:00 2023

real    0m2,885s
user    0m0,642s
sys 0m0,573s

In both cases, the PSK is recovered and performance is the same.

[LLH-l]

@ZerBea

We still have another solution, add a new parameter and display it at the end of the hash You can still be implemented in you own tools, including changing the priority of M1M2 or M1M2M4 messages conversion logic, This may up lot you time E.g

WPA**02     M1M2m3
WPA**02     M2M3M4
WPA**02     m1M2M3M4

WPA**00     M1M2
WPA**00     M1M2M4

[ZerBea]

I can't add this in a simple way. A check if M3 is missing but M4 is present required a second stage. I have to convert all M1M2 MESSAGE PAIRS. Than, on every M4 I have to go through this entire list to see if M4 RC matches to M2. The impact on pcapng dump files is huge and doubles the time of converting the dump file.

I have to refactor the entire detection of handshakes.

e.g. on your example: 89247 Jul 19, 2020 22:05:14.397322000 1 5 89261 Jul 19, 2020 22:05:14.410123000 1 5 89264 Jul 19, 2020 22:05:14.420353000 2 5

186360 Jul 19, 2020 22:28:51.409611000 1 3 186363 Jul 19, 2020 22:28:51.431098000 2 3 186368 Jul 19, 2020 22:28:51.444929000 4 4

In this example alone I have to go back 97099 packets to the last M1M2. And I have to do this on every new M4.

A hcxdumptool pcapng file has more than one NETWORK inside. I have do do this on every NETWORK, too. The price tag (performance issue) will be very, very high.

[LLH-l]

In fact, the time loss can be ignored, as long as the conversion ideal hash can be achieved, has already been done very good

[ZerBea]

At the moment I'm going 64 packets into the past on every MESSAGE PAIR: https://github.com/ZerBea/hcxtools/blob/master/include/hcxpcapngtool.h#L47

Can you imagine what happens if I have to go > 100000 packets into the past on every MESSAGE PAIR. Can you imagine what that meant to online sites like: https://wpa-sec.stanev.org https://hashcat.net/cap2hashcat/

And there is absolutely no benefit. hashcat has recovered the PSK successfully on --all option: https://github.com/ZerBea/hcxtools/issues/265#issuecomment-1509628442

[ZerBea]

If the time interval between message pairs is (<500 milliseconds) Priority should be given to converting messages This will epically fail if time stamps are zeroed (e.g. by wpaclean):

2   00:00:00,000000 1   1
3   00:00:00,000000 2   1
5   00:00:00,000000 1   170
6   00:00:00,000000 4   171
8   00:00:00,000000 1   78
9   00:00:00,000000 2   78
11  00:00:00,000000 1   73
12  00:00:00,000000 2   82
14  00:00:00,000000 1   35
15  00:00:00,000000 2   36
17  00:00:00,000000 2   6789
18  00:00:00,000000 3   6790
20  00:00:00,000000 1   1
21  00:00:00,000000 2   1
23  00:00:00,000000 2   30
24  00:00:00,000000 3   34

I think I leave hcxpcapngtool as it is. On crappy dump files containing zeroed time stamps, missing frames the user will get a warning and he/she must use --all to get rid of this. As long as hashcat is able to recover the PSK from that crap, that is proofed here: https://github.com/ZerBea/hcxtools/issues/265#issuecomment-1509628442 there is no need to refactor hcxpcapngtool.

[ZerBea]

BTW: from README.md section Requirements

Requirements
--------------
* knowledge of radio technology
* knowledge of electromagnetic-wave engineering
* detailed knowledge of 802.11 protocol
* detailed knowledge of key derivation functions

My approach Dry run on a dump file of unknown origin

$ hcxpcapngtool yzuvukge.pcap
hcxpcapngtool 6.2.9 reading from yzuvukge.pcap...

summary capture file
--------------------
file name................................: yzuvukge.pcap
version (pcap/cap).......................: 2.4 (very basic format without any additional information)
timestamp minimum (GMT)..................: 19.07.2020 15:45:01
timestamp maximum (GMT)..................: 19.07.2020 17:40:08
used capture interfaces..................: 1
link layer header type...................: DLT_IEEE802_11 (105) very basic format without any additional information about the quality
endianess (capture system)...............: little endian
packets inside...........................: 196368
ESSID (total unique).....................: 1
BEACON (total)...........................: 1
BEACON on 2.4 GHz channel (from IE_TAG)..: 11 
ACTION (total)...........................: 20
PROBERESPONSE (total)....................: 948
DISASSOCIATION (total)...................: 1
REASSOCIATIONREQUEST (total).............: 1
REASSOCIATIONREQUEST (PSK)...............: 1
WPA encrypted............................: 1333
EAPOL messages (total)...................: 21
EAPOL RSN messages.......................: 21
EAPOLTIME gap (measured maximum msec)....: 63
EAPOL ANONCE error corrections (NC)......: not detected
REPLAYCOUNT gap (measured maximum).......: 2
EAPOL M1 messages (total)................: 18
EAPOL M2 messages (total)................: 2
EAPOL M4 messages (total)................: 1
EAPOL pairs (total)......................: 18
EAPOL pairs (best).......................: 1
EAPOL M12E2 (challenge)..................: 1

Warning: out of sequence timestamps!
This dump file contains frames with out of sequence timestamps.
That is a bug of the capturing tool.

Information: limited dump file format detected!
This file format is a very basic format to save captured network data.
It is recommended to use PCAP Next Generation dump file format (or pcapng for short) instead.
The PCAP Next Generation dump file format is an attempt to overcome the limitations
of the currently widely used (but very limited) libpcap (cap, pcap) format.
https://www.wireshark.org/docs/wsug_html_chunked/AppFiles.html#ChAppFilesCaptureFilesSection
https://github.com/pcapng/pcapng

Information: no hashes written to hash files

Information: radiotap header is missing!
Radiotap is a de facto standard for 802.11 frame injection and
reception. The radiotap header format is a mechanism to supply
additional information about frames, rom the driver to userspace
applications.
https://www.radiotap.org/

Information: missing frames!
This dump file does not contain undirected proberequest frames.
An undirected proberequest may contain information about the PSK.
It always happens if the capture file was cleaned or
it could happen if filter options are used during capturing.
That makes it hard to recover the PSK.

session summary
---------------
processed cap files...................: 1

My analysis. I can't trust the time stamps

Warning: out of sequence timestamps!
This dump file contains frames with out of sequence timestamps.
That is a bug of the capturing tool.

there are missing EAPOL frames (at least EAPOL M3) due to a packet loss:

EAPOL M1 messages (total)................: 18
EAPOL M2 messages (total)................: 2
EAPOL M4 messages (total)................: 1

there are other missing frames:

Information: missing frames!
This dump file does not contain undirected proberequest frames.
An undirected proberequest may contain information about the PSK.
It always happens if the capture file was cleaned or
it could happen if filter options are used during capturing.
That makes it hard to recover the PSK.

the dump file is stored using a limited format. I should not expect additional information.

Information: limited dump file format detected!
This file format is a very basic format to save captured network data.
It is recommended to use PCAP Next Generation dump file format (or pcapng for short) instead.
The PCAP Next Generation dump file format is an attempt to overcome the limitations
of the currently widely used (but very limited) libpcap (cap, pcap) format.
https://www.wireshark.org/docs/wsug_html_chunked/AppFiles.html#ChAppFilesCaptureFilesSection
https://github.com/pcapng/pcapng

My conclusion: The dump file is really crappy. I don't waste my GPU time running a big list (key space) on it. But I give it a try, running hcxpsktool or a small pattern (mask) or rule. Therefore I use hcxpcapngtool --all /due to heavy packet loss), feed hashcat with it and give it a try.

Everything else is "script kiddie style".

[ZerBea]

It doesn't make sense to add hundreds of lines of additional code (which make hcxpcapngtool slow and more complicated) to take care about crappy dump files. By latest commit, I added some additional information to the status:

EAPOL M4 messages (zeroed NONCE).........: 1

and

Information: missing EAPOL M3 frames!
This dump file does not contain EAPOL M3 frames (possibel packet loss).
It strongly recommended to recapture the traffic or
to use --all option to convert all possible EAPOL MESSAGE PAIRs.

complete status:

$ hcxpcapngtool yzuvukge.pcap
hcxpcapngtool 6.2.9 reading from yzuvukge.pcap...

summary capture file
--------------------
file name................................: yzuvukge.pcap
version (pcap/cap).......................: 2.4 (very basic format without any additional information)
timestamp minimum (GMT)..................: 19.07.2020 15:45:01
timestamp maximum (GMT)..................: 19.07.2020 17:40:08
used capture interfaces..................: 1
link layer header type...................: DLT_IEEE802_11 (105) very basic format without any additional information about the quality
endianess (capture system)...............: little endian
packets inside...........................: 196368
ESSID (total unique).....................: 1
BEACON (total)...........................: 1
BEACON on 2.4 GHz channel (from IE_TAG)..: 11 
ACTION (total)...........................: 20
PROBERESPONSE (total)....................: 948
DISASSOCIATION (total)...................: 1
REASSOCIATIONREQUEST (total).............: 1

REASSOCIATIONREQUEST (PSK)...............: 1
WPA encrypted............................: 1333
EAPOL messages (total)...................: 21
EAPOL RSN messages.......................: 21
EAPOLTIME gap (measured maximum msec)....: 63
EAPOL ANONCE error corrections (NC)......: not detected
REPLAYCOUNT gap (measured maximum).......: 2
EAPOL M1 messages (total)................: 18
EAPOL M2 messages (total)................: 2
EAPOL M4 messages (total)................: 1
EAPOL M4 messages (zeroed NONCE).........: 1
EAPOL pairs (total)......................: 18
EAPOL pairs (best).......................: 1
EAPOL M12E2 (challenge)..................: 1

Warning: out of sequence timestamps!
This dump file contains frames with out of sequence timestamps.
That is a bug of the capturing tool.

Information: limited dump file format detected!
This file format is a very basic format to save captured network data.
It is recommended to use PCAP Next Generation dump file format (or pcapng for short) instead.
The PCAP Next Generation dump file format is an attempt to overcome the limitations
of the currently widely used (but very limited) libpcap (cap, pcap) format.
https://www.wireshark.org/docs/wsug_html_chunked/AppFiles.html#ChAppFilesCaptureFilesSection
https://github.com/pcapng/pcapng

Information: radiotap header is missing!
Radiotap is a de facto standard for 802.11 frame injection and
reception. The radiotap header format is a mechanism to supply
additional information about frames, rom the driver to userspace
applications.
https://www.radiotap.org/

Information: missing frames!
This dump file does not contain undirected proberequest frames.
An undirected proberequest may contain information about the PSK.
It always happens if the capture file was cleaned or
it could happen if filter options are used during capturing.
That makes it hard to recover the PSK.

Information: missing EAPOL M3 frames!
This dump file does not contain EAPOL M3 frames (possible packet loss).
It strongly recommended to recapture the traffic or
to use --all option to convert all possible EAPOL MESSAGE PAIRs.

Information: no hashes written to hash files

Whenever I thought I had found a solution, I ran into another problem on that crappy dump files. From your comment: I still suggest in the following situation If the time interval between message pairs is (<500 milliseconds) https://github.com/ZerBea/hcxtools/issues/265#issuecomment-1509559892 But I cant trust the time stamps of this dump file:

Warning: out of sequence timestamps!
This dump file contains frames with out of sequence timestamps.
That is a bug of the capturing tool.

hcxpcapngtool will never be able to convert this crap by default options - even if I add thousand of lines of code to handle this:

• zeroed time stamps
• negative time stamps
• time resolution only in microseconds (last 3 counts are rounded)
• missing EAPOL frames

Now the user have two options: Use hcxdumptool to recapture the traffic Run hcxpcapngtool --all

[LLH-l]

If you don't want change too much code this seems like very good

89247   Jul 19, 2020 22:05:14.397322000     1   5
89261   Jul 19, 2020 22:05:14.410123000     1   5
89264   Jul 19, 2020 22:05:14.420353000     2   5

186360  Jul 19, 2020 22:28:51.409611000     1   3
186363  Jul 19, 2020 22:28:51.431098000     2   3
186368  Jul 19, 2020 22:28:51.444929000     4   4

E.g

EAPOL M124E2 (challenge)..................: 1
EAPOL M12E2 (challenge)..................: 1

[ZerBea]

$ tshark -r yzuvukge.pcap -T fields -e frame.number -e _ws.col.Time | grep "-"

1857    13:45:26,-00002
7635    13:47:39,-00003
25799   13:53:20,-00002
26049   13:53:26,-00002
28237   13:54:28,-00002
51555   13:58:56,-00003
55713   13:59:43,-00003
66262   14:00:42,-00006
66263   14:00:42,-00003
69677   14:01:07,-00003
71790   14:01:21,-00003
74834   14:02:10,-00002
75370   14:02:17,-00003
80216   14:03:06,-00003
91938   14:05:59,-00001
92052   14:06:00,-00002
105813  14:08:54,-00002
128512  14:14:21,-00009
139557  14:16:44,-00002
139669  14:16:45,-00003
144136  14:17:53,-00003
148617  14:19:09,-00006
149630  14:19:18,-00006
151493  14:19:34,-00001
165103  14:24:32,-00003
184313  14:28:00,-00002
184314  14:28:00,-00006
185561  14:28:34,-00003

[ZerBea]

Exactly that https://github.com/ZerBea/hcxtools/issues/265#issuecomment-1509753542 is not possible with the current handshake detection engine. Only MESSAGE PAIRs are handled (M1M2, M2M3, M3M4 (if M4 nonce is not zeroed) and M1M4 (if M4 nonce is not zeroed) MESSAGE TRIPLEs M1M2M4 (if M4 is zeroed) are not handled, because this is covered by --all option. Adding MESSAGE TRIPLEs, require massive code changes (and there is no benefit compared to --all)

The current engine is based on EAPOL time gap only. A packet loss is less likely on a small EAPOL time gap than on a big EAPOL TIME gap.

[LLH-l]

Adding MESSAGE TRIPLEs, require massive code changes

OK It does take a lot of time, and even the entire engine needs to be rewritten Let's put an end to this topic, Thanks .

[ZerBea]

Please also notice:

89247   Jul 19, 2020 22:05:14.397322000     1   5
89261   Jul 19, 2020 22:05:14.410123000     1   5
89264   Jul 19, 2020 22:05:14.420353000     2   5

186360  Jul 19, 2020 22:28:51.409611000     1   3
186363  Jul 19, 2020 22:28:51.431098000     2   3
186368  Jul 19, 2020 22:28:51.444929000     4   4

At time of converting this MESSGAE PAIRS, hcxpcangtool dos not have the key. It does not know which is the correct one. EAPOL M3 is missing - what about, if an entire AUTHENTICATION SEQUENCE is missing, too: 186360 Jul 19, 2020 22:28:51.409611000 1 3 186363 Jul 19, 2020 22:28:51.431098000 2 3

186364 Jul 19, 2020 22:28:51.431198000 1 3 186365 Jul 19, 2020 22:28:51.432198000 2 3 186366 Jul 19, 2020 22:28:51.433198000 3 4 186367 Jul 19, 2020 22:28:51.434198000 4 4

186368 Jul 19, 2020 22:28:51.444929000 4 4

I'll say: At time of converting the MESSAGE PAIRs, hcxpcapngtool does not know which is the best one. But it is most likely that the best one is the one with the smallest time between M1 and M2. On every other case, we must consider a packet loss (especially if there is a lost frame (like EAPOL M3).

[ZerBea]

I'm really interested to improve the detection engine, but I don't know how. I analyzed hundreds of dump files submitted to wpa-sec. There are too many screws to handle all dump files by default options. The current engine convert 90% by default options - but (unfortunately) the remaining 10% can't be handled by default options. To handle special cases (the remaining 10%), I added the options all, eapoltimeout, nonce-error-corrections, ignore-ie and max-essids. If the default option failed, this options are working as expected: https://github.com/ZerBea/hcxtools/issues/265#issuecomment-1509628442

If I e.g. modify the code to handle the dump file mentioned above, it will have a huge impact on other dump files (e.g. on dump files with zeroed timestamps).

[LLH-l]

@ZerBea don't worry You done very good

in fact dump files with zeroed timestamps abnormal file can be ignore Do not process files with zero timestamp in 20000 files, I not find timestamp zero file This type file may occur, but extremely rare