Separator unmatched - file hccapx

[MariuszPoz]

Hello. I recently watched this video file of cracking wifi password:

[Video: https://www.youtube.com/watch?v=J8A8rKFZ...avidBombal]

i used The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) linux on vmware virtual machine. I successfully found handshake, got cap file. I converted it to a hccapx file.

When i try to use this hccapx file in hashcat (does not matter if with brute force or dictionary) it says:

Hashfile 'wpa2.hccapx' on line 1 (HCPX♦): Separator unmatched
Hashfile 'wpa2.hccapx' on line 2 (): Separator unmatched
Hashfile 'wpa2.hccapx' on line 3 (): Separator unmatched
No hashes loaded.


Screenshot below



If this is allowed i'd like to share my cap and hccapx files with you. It is available here: https://mbaraniecki.pl/files/myhandshakefiles.zip

Am i using wrong command? Or my files may be corrupted? hccapx file has 786 bytes. cap file has 92kb (about).

I've got handshake file on The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) linux, but i am using hashcat on windows (on The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) it does not using my gpu - i don't know why, only cpu)

IS IT possible when i sent hccapx file to gmail from linux, and from gmail i downloaded to windows the file was corrupted? Anyway file size did not change even before and after i send it.

Please help and thanks to all.

[ZerBea]

hccapx is deprecated and replaced by a new hash format.

Read about the new format here:
https://hashcat.net/wiki/doku.php?id=cracking_wpawpa2
and here:
https://hashcat.net/forum/thread-10253.html
and here:
https://hashcat.net/forum/thread-10357.html

Many DEAUTHENTICATION frames are injected directly into the AUTHENTICATION sequence (which is an ugly/stupid/nasty behavior of either your attack vector or the tools that you have used to perform this attack).
Starting with packet 1397 the CLIENT requested a new AUTHENTICATION sequence. Unfortunately it looks like the DEUTHENTICATION tool didn't notice that.

Code:

packet 1397 REASSOCIATIONREQUEST
packet 1398 DEAUTHENTICATION
packet 1399 DEAUTHENTICATION
packet 1402 DEAUTHENTICATION
packet 1403 DEAUTHENTICATION
packet 1404 DEAUTHENTICATION
packet 1408 DEAUTHENTICATION
packet 1409 DEAUTHENTICATION
packet 1410 DEAUTHENTICATION
packet 1412 M1
packet 1416 M2
packet 1418 DEAUTHENTICATION
packet 1419 M3
packet 1421 DEAUTHENTICATION
packet 1422 DEAUTHENTICATION
packet 1423 DEAUTHENTICATION
packet 1425 M4

Analysis done by using tshark/Wireshark.

Goal should it be to retrieve a PMKID or a complete AUTHENTICATION sequence (EAPOL 4way handshake) and not to destroy everything by injecting stupid DEAUTHENTICATION frames.

BTW:
You got a PMKID and you should use it.
PMKID written to combi hash file.........: 1

Read more about the PMKID attack here:
https://hashcat.net/forum/thread-7717.ht...KID+attack
and forget everything you've seen in these old video tutorials.

In detail:

Code:

$ hcxpcapngtool handshake_si_2C-56-DC-4F-EF-A8_2021-11-03T13-36-56.cap -o /tmp/test.22000
hcxpcapngtool 6.2.4-60-gd82349d reading from handshake_si_2C-56-DC-4F-EF-A8_2021-11-03T13-36-56.cap...
failed to read pcap packet header for packet 1576

summary capture file
--------------------
file name.................................: handshake_si_2C-56-DC-4F-EF-A8_2021-11-03T13-36-56.cap
version (pcap/cap).......................: 2.4 (very basic format without any additional information)
timestamp minimum (GMT)..................: 03.11.2021 18:36:36
timestamp maximum (GMT)..................: 03.11.2021 18:36:54
used capture interfaces..................: 1
link layer header type...................: DLT_IEEE802_11 (105)
endianess (capture system)...............: little endian
packets inside...........................: 1576
ESSID (total unique).....................: 1
BEACON (total)...........................: 1
BEACON (detected on 2.4GHz channel)......: 3
ACTION (total)...........................: 4
PROBERESPONSE (total)....................: 72
DEAUTHENTICATION (total).................: 472
AUTHENTICATION (total)...................: 3
AUTHENTICATION (OPEN SYSTEM).............: 3
REASSOCIATIONREQUEST (total).............: 1
REASSOCIATIONREQUEST (PSK)...............: 1
WPA encrypted............................: 43
EAPOL messages (total)...................: 4
EAPOL RSN messages.......................: 4
EAPOLTIME gap (measured maximum usec)....: 4662
EAPOL ANONCE error corrections (NC)......: working
REPLAYCOUNT gap (recommended NC).........: 8
EAPOL M1 messages (total)................: 1
EAPOL M2 messages (total)................: 1
EAPOL M3 messages (total)................: 1
EAPOL M4 messages (total)................: 1
EAPOL pairs (total)......................: 2
EAPOL pairs (best).......................: 1
EAPOL pairs written to combi hash file...: 1 (RC checked)
EAPOL M32E2 (authorized).................: 1
PMKID (total)............................: 1
PMKID (best).............................: 1
PMKID written to combi hash file.........: 1
packet read error........................: 1

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.

Warning: missing frames!
This dump file does not contain enough EAPOL M1 frames.
It always happens if the capture file was cleaned or
it could happen if filter options are used during capturing.
That makes it impossible to calculate nonce-error-correction values.


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

[MariuszPoz]

Ok. So basically the file *.cap file is not corrupted, right? I managed to create a file *.hc22000 from cap file using online page and a command:

$ hashcat -m 22000 hash.hc22000 wordlist.txt

for dictionary attack works just fine.

This for brute force:

hashcat -m 22000 handshake.hc22000 -a 3 -O

also works fine.

I see thath cracking wpa2 with 22000 is slower than cracking sha256. 8 char password (if no longer) will be cracked within 22h using my Radeon 580 8gb. 10 chars Sha256 this card cracks within 1.5 day.

[ZerBea]

You're absolutely right. PBKDF2 is a slow process.

The cap file is damaged at the end. It looks like your capturing tool was terminated "hard".
You don't have to care about this, because you got all the information to recover the PSK before this happened:

Code:

$ tshark -r handshake_si_2C-56-DC-4F-EF-A8_2021-11-03T13-36-56.cap
tshark: The file "handshake_si_2C-56-DC-4F-EF-A8_2021-11-03T13-36-56.cap" appears to have been cut short in the middle of a packet.

But you have to improve your attack vector, because injecting tons of DAUTHENTICATION frames into AUTHENTICATION sequences may lead to uncrackable MESSAGE PAIRs:

Code:

1397 17:36:53,921712 7c:76:35:15:44:4c → 2c:56:dc:4f:ef:a8 802.11 190 Reassociation Request, SN=10, FN=0, Flags=........, SSID=si
1398 17:36:53,924834 2c:56:dc:4f:ef:a8 → 68:3e:34:29:8e:42 802.11 26 Deauthentication, SN=58, FN=0, Flags=........
1399 17:36:53,928903 68:3e:34:29:8e:42 → 2c:56:dc:4f:ef:a8 802.11 26 Deauthentication, SN=59, FN=0, Flags=........
1400 17:36:53,932083 2c:56:dc:4f:ef:a8 → 7c:76:35:15:44:4c 802.11 33 Action, SN=756, FN=0, Flags=........
1401 17:36:53,932408              → 2c:56:dc:4f:ef:a8 (RA) 802.11 10 Acknowledgement, Flags=........
1402 17:36:53,935831 2c:56:dc:4f:ef:a8 → 68:3e:34:29:8e:42 802.11 26 Deauthentication, SN=60, FN=0, Flags=........
1403 17:36:53,937099 2c:56:dc:4f:ef:a8 → 68:3e:34:29:8e:42 802.11 26 Deauthentication, SN=58, FN=0, Flags=........
1404 17:36:53,937906 68:3e:34:29:8e:42 → 2c:56:dc:4f:ef:a8 802.11 26 Deauthentication, SN=59, FN=0, Flags=........
1405 17:36:53,937965              → 68:3e:34:29:8e:42 (RA) 802.11 10 Acknowledgement, Flags=........
1406 17:36:53,938482 7c:76:35:15:44:4c → 2c:56:dc:4f:ef:a8 802.11 33 Action, SN=11, FN=0, Flags=........
1407 17:36:53,938796              → 7c:76:35:15:44:4c (RA) 802.11 10 Acknowledgement, Flags=........
1408 17:36:53,939800 68:3e:34:29:8e:42 → 2c:56:dc:4f:ef:a8 802.11 26 Deauthentication, SN=61, FN=0, Flags=........
1409 17:36:53,943700 2c:56:dc:4f:ef:a8 → 68:3e:34:29:8e:42 802.11 26 Deauthentication, SN=60, FN=0, Flags=........
1410 17:36:53,944702 68:3e:34:29:8e:42 → 2c:56:dc:4f:ef:a8 802.11 26 Deauthentication, SN=61, FN=0, Flags=........
1411 17:36:53,944707              → 68:3e:34:29:8e:42 (RA) 802.11 10 Acknowledgement, Flags=........
1412 17:36:53,946284 2c:56:dc:4f:ef:a8 → 7c:76:35:15:44:4c EAPOL 155 Key (Message 1 of 4)
1413 17:36:53,946531              → 2c:56:dc:4f:ef:a8 (RA) 802.11 10 Acknowledgement, Flags=........
1414 17:36:53,947080 2c:56:dc:4f:ef:a8 (TA) → 7c:76:35:15:44:4c (RA) 802.11 20 802.11 Block Ack Req, Flags=........
1415 17:36:53,947538 7c:76:35:15:44:4c (TA) → 2c:56:dc:4f:ef:a8 (RA) 802.11 28 802.11 Block Ack, Flags=........
1416 17:36:53,949132 7c:76:35:15:44:4c → 2c:56:dc:4f:ef:a8 EAPOL 157 Key (Message 2 of 4)
1417 17:36:53,949407              → 7c:76:35:15:44:4c (RA) 802.11 10 Acknowledgement, Flags=........
1418 17:36:53,951864 2c:56:dc:4f:ef:a8 → 68:3e:34:29:8e:42 802.11 26 Deauthentication, SN=62, FN=0, Flags=........
1419 17:36:53,953794 2c:56:dc:4f:ef:a8 → 7c:76:35:15:44:4c EAPOL 189 Key (Message 3 of 4)
1420 17:36:53,954039              → 2c:56:dc:4f:ef:a8 (RA) 802.11 10 Acknowledgement, Flags=........
1421 17:36:53,955821 68:3e:34:29:8e:42 → 2c:56:dc:4f:ef:a8 802.11 26 Deauthentication, SN=63, FN=0, Flags=........
1422 17:36:53,958579 2c:56:dc:4f:ef:a8 → 68:3e:34:29:8e:42 802.11 26 Deauthentication, SN=62, FN=0, Flags=........
1423 17:36:53,959565 68:3e:34:29:8e:42 → 2c:56:dc:4f:ef:a8 802.11 26 Deauthentication, SN=63, FN=0, Flags=........
1424 17:36:53,959569              → 68:3e:34:29:8e:42 (RA) 802.11 10 Acknowledgement, Flags=........
1425 17:36:53,961085 7c:76:35:15:44:4c → 2c:56:dc:4f:ef:a8 EAPOL 133 Key (Message 4 of 4)
1426 17:36:53,961350              → 7c:76:35:15:44:4c (RA) 802.11 10 Acknowledgement, Flags=........
1427 17:36:53,963874 2c:56:dc:4f:ef:a8 → 68:3e:34:29:8e:42 802.11 26 Deauthentication, SN=64, FN=0, Flags=........
1428 17:36:53,967897 68:3e:34:29:8e:42 → 2c:56:dc:4f:ef:a8 802.11 26 Deauthentication, SN=65, FN=0, Flags=........
1429 17:36:53,972935 2c:56:dc:4f:ef:a8 → 68:3e:34:29:8e:42 802.11 26 Deauthentication, SN=64, FN=0, Flags=........
1430 17:36:53,973811 68:3e:34:29:8e:42 → 2c:56:dc:4f:ef:a8 802.11 26 Deauthentication, SN=65, FN=0, Flags=........

BTW:
If you take a look at the converted hc22000 hash line, you'll see 2 entries for your target:
A PMKID starting with identifier WPA*01 and an EAPOL MESSAGE PAIR, starting with WPA*02.
In this case, to speed up hashcat, you can remove the EAPOL MESSAGE PAIR (WPA*02 line) from your hash file.

You can confirm that the PMKID within the hash file is correct by running tshark:

Code:

$ tshark -r handshake_si_2C-56-DC-4F-EF-A8_2021-11-03T13-36-56.cap -T fields -e wlan.ta -e wlan.sa -e wlan.rsn.ie.pmkid | sort | uniq

The shown PMKID should be identical to the PMKID within the WPA*01 hash line.

[MariuszPoz]

Ok. As far as i know password is salted with ssid name, right? Source of this is here:

https://www.rfc-editor.org/rfc/rfc2898#section-5.2

So if i order hashcat to find a password with brute force is there any command to include a salt taken from ssid or is this salt stored in file *.hc22000 and the hashcat may use this salt from this file automatically?

[ZerBea]

In every case (WPA1-PSK, WPA2-PSK, WPA2 key version3-PSK), the salt is the ESSID and hashcat will take it from the hash line as well as all other values needed to recover the PSK.
The hash line is explained here:
https://hashcat.net/wiki/doku.php?id=cracking_wpawpa2

Code:

WPA*01*PMKID*MAC_AP*MAC_CLIENT*ESSID***
WPA*02*MIC*MAC_AP*MAC_CLIENT*ESSID*NONCE_AP*EAPOL_CLIENT*MESSAGEPAIR

Simply explained, recovering the PSK is divided into 2 steps:
1. calculate PMK from ESSID and PSK (via PBKDF2 - rfc2898) - this calculation is very slow
2. calculate PMKID or MIC using the PMK (calculated in step 1) - if the calculated PMKID or MIC is the same as the one stored in the hash line, the PSK is correct - this calculation is fast

The PMKID (identifier WPA*01) calculation is explained here:
https://hashcat.net/forum/thread-7717.html

A proof of concept is explained here:
https://www.cyberark.com/resources/threa...mple-trick

The 4way handshake (identifier WPA*02) calculation is explained here:
https://www.wifi-professionals.com/2019/...-handshake


It is mandatory to have at least one of them (WPA*01 or WPA*02 hash line) to successfully recover the PSK.

BTW:
If you compare the calculation of the PMKID with the calculation of the MIC, you'll notice that calculating a PMKID is slightly faster, while step 1 take the same time on both.