That has nothing todo with the hash mode or the hccapx format and hcxpcapngtool is able to find a valid message pair. But that need more options to be used on this cap file.
The old cap2hccapx (from hashcat utils) convert all possible message pairs to a hccapx file.
The new online converter convert only the best one to a 22000 hash file.
Where best one is defined as:
Replay count is matching and lowest time gap between teo EAPOL messages.
Unfortunately the attack mode, used to get EAPOL messages stored in this cap file is not the best choice.
It is not a good idea to excessive inject so many deuthentications to get a 4way handshake.
May I ask a question:
Which tools have you used to attack the AP?
Which tools have you used to dump the traffic to the cap file?
Analysis of your cap file:
The capture file appears to have been cut short in the middle of a packet (packet 2481).
It looks like your capturing tool doesn't handle timestamps correctly.
During the attack, too many deauthentications are injected. Some of them are injected directly into the authentication sequences. This behavior destroyed most of the authentication sequences and AP and CLIENT renewed all values and timers.
Additional (if you check the sequence numbers) you'll see that the dump tool doesn't detect a packet loss. And there are many, many lost (authentication) packets.
All that (execssive deauthentications, packet loss not detected during attack, wrong timestamps) makes it nearly impossible to convert only the best message pair by default options of hcxpcapngtool.
hcxpcapngtool detect this behavior and show a warning:
A Wireshark analysis of the cap file shows that from all possible message pair combinations only one(!) is useful. This is caused by excessive injecting deauthentications!!!!
The online converter can't handle that, because it is running standard options, only!
Running hcxpcapngtool with option --all will give you better results, if trying to get a valid message pair from such dump files:
Converting all possible message pairs, hashcat will recover the correct PSK:
Please notice, that --all produce much overhead and invalid message pairs!
Total 24 message pair combinations are converted by hcxpcapngtool.
13 of them are unique.
But only one of them is valid, because all other ones are destroyed by excessive injecting deauthentications or EAPOL messages are not dumped to the cap file due to packet loss,
I strongly recommend to improve the attack.
Do not run excessive deauthentications by stupid deauthentication tools.
Do not use tools that are not able to detect a packet loss during capturing.
BTW:
You can ask Atom to add option --all to the online converter to get all possible combinations.
But I don't think that it is a good idea to add --all, because it produce much overhead (invalid message pairs).
It is much better to improve you attack and to use tools that are able to detect and prevent this during the attack.
The old cap2hccapx (from hashcat utils) convert all possible message pairs to a hccapx file.
The new online converter convert only the best one to a 22000 hash file.
Where best one is defined as:
Replay count is matching and lowest time gap between teo EAPOL messages.
Unfortunately the attack mode, used to get EAPOL messages stored in this cap file is not the best choice.
It is not a good idea to excessive inject so many deuthentications to get a 4way handshake.
May I ask a question:
Which tools have you used to attack the AP?
Which tools have you used to dump the traffic to the cap file?
Analysis of your cap file:
The capture file appears to have been cut short in the middle of a packet (packet 2481).
It looks like your capturing tool doesn't handle timestamps correctly.
During the attack, too many deauthentications are injected. Some of them are injected directly into the authentication sequences. This behavior destroyed most of the authentication sequences and AP and CLIENT renewed all values and timers.
Additional (if you check the sequence numbers) you'll see that the dump tool doesn't detect a packet loss. And there are many, many lost (authentication) packets.
All that (execssive deauthentications, packet loss not detected during attack, wrong timestamps) makes it nearly impossible to convert only the best message pair by default options of hcxpcapngtool.
hcxpcapngtool detect this behavior and show a warning:
Code:
Warning: out of sequence timestamps!
This dump file contains frames with out of sequence timestamps.
That is a bug of the capturing tool.
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.A Wireshark analysis of the cap file shows that from all possible message pair combinations only one(!) is useful. This is caused by excessive injecting deauthentications!!!!
The online converter can't handle that, because it is running standard options, only!
Running hcxpcapngtool with option --all will give you better results, if trying to get a valid message pair from such dump files:
Code:
$ hcxpcapngtool --all -o test.hc22000 ht3466227.cap
hcxpcapngtool 6.2.4-3-g1fa7cdb reading from ht3466227.cap...
failed to read packet 2481
summary capture file
--------------------
file name................................: ht3466227.cap
version (pcap/cap).......................: 2.4 (very basic format without any additional information)
timestamp minimum (GMT)..................: 04.11.2019 16:36:47
timestamp maximum (GMT)..................: 04.11.2019 16:37:19
used capture interfaces..................: 1
link layer header type...................: DLT_IEEE802_11 (105)
endianess (capture system)...............: little endian
packets inside...........................: 2481
BEACON (total)...........................: 1
ACTION (total)...........................: 22
PROBEREQUEST (directed)..................: 36
PROBERESPONSE (total)....................: 39
DEAUTHENTICATION (total).................: 773
AUTHENTICATION (total)...................: 43
AUTHENTICATION (OPEN SYSTEM).............: 43
ASSOCIATIONREQUEST (total)...............: 10
ASSOCIATIONREQUEST (PSK).................: 10
WPA encrypted............................: 17
EAPOL messages (total)...................: 17
EAPOL RSN messages.......................: 17
ESSID (total unique).....................: 1
EAPOLTIME gap (measured maximum usec)....: 1550386
EAPOL ANONCE error corrections (NC)......: working
REPLAYCOUNT gap (suggested NC)...........: 1
EAPOL M1 messages (total)................: 7
EAPOL M2 messages (total)................: 8
EAPOL M3 messages (total)................: 1
EAPOL M4 messages (total)................: 1
EAPOL pairs (total)......................: 24
EAPOL pairs (best).......................: 24
EAPOL pairs written to combi hash file...: 24 (RC checked)
EAPOL M12E2 (challenge)..................: 22
EAPOL M32E2 (authorized).................: 2
PMKID (useless)..........................: 7
packet read error........................: 1
Warning: out of sequence timestamps!
This dump file contains frames with out of sequence timestamps.
That is a bug of the capturing tool.
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.
Warning: 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...................: 1Converting all possible message pairs, hashcat will recover the correct PSK:
Code:
$ hashcat -m 22000 test.hc22000 -a3 ht3466227
hashcat (v6.2.4-66-gee3eb21a0) starting
CUDA API (CUDA 11.4)
====================
* Device #1: NVIDIA GeForce GTX 1080 Ti, 10698/11175 MB, 28MCU
OpenCL API (OpenCL 3.0 CUDA 11.4.112) - Platform #1 [NVIDIA Corporation]
========================================================================
* Device #2: NVIDIA GeForce GTX 1080 Ti, skipped
Minimum password length supported by kernel: 8
Maximum password length supported by kernel: 63
Hashes: 24 digests; 13 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Optimizers applied:
* Zero-Byte
* Single-Salt
* Brute-Force
* Slow-Hash-SIMD-LOOP
Watchdog: Temperature abort trigger set to 90c
Host memory required for this attack: 2950 MB
The wordlist or mask that you are using is too small.
This means that hashcat cannot use the full parallel power of your device(s).
Unless you supply more work, your cracking speed will drop.
For tips on supplying more work, see: https://hashcat.net/faq/morework
Approaching final keyspace - workload adjusted.
0e678a6d2a56a24d42592dfd83ae61c2:786256a37308:c8ddc9f59185:我的大菠萝:ht3466227
Session..........: hashcat
Status...........: Exhausted
Hash.Mode........: 22000 (WPA-PBKDF2-PMKID+EAPOL)
Hash.Target......: test.hc22000
Time.Started.....: Sat Sep 18 08:46:57 2021 (0 secs)
Time.Estimated...: Sat Sep 18 08:46:57 2021 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Mask.......: ht3466227 [9]
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 22 H/s (1.44ms) @ Accel:8 Loops:256 Thr:512 Vec:1
Recovered........: 1/13 (7.69%) Digests
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:12-25
Candidate.Engine.: Device Generator
Candidates.#1....: ht3466227 -> ht3466227
Hardware.Mon.#1..: Temp: 56c Fan: 35% Util: 84% Core:1847MHz Mem:5005MHz Bus:16
Started: Sat Sep 18 08:46:54 2021
Stopped: Sat Sep 18 08:46:58 2021Please notice, that --all produce much overhead and invalid message pairs!
Total 24 message pair combinations are converted by hcxpcapngtool.
13 of them are unique.
But only one of them is valid, because all other ones are destroyed by excessive injecting deauthentications or EAPOL messages are not dumped to the cap file due to packet loss,
I strongly recommend to improve the attack.
Do not run excessive deauthentications by stupid deauthentication tools.
Do not use tools that are not able to detect a packet loss during capturing.
BTW:
You can ask Atom to add option --all to the online converter to get all possible combinations.
But I don't think that it is a good idea to add --all, because it produce much overhead (invalid message pairs).
It is much better to improve you attack and to use tools that are able to detect and prevent this during the attack.