Separator unmatched - file hccapx

Separator unmatched - file hccapx - Printable Version

+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Misc (https://hashcat.net/forum/forum-15.html)
+--- Forum: General Talk (https://hashcat.net/forum/forum-33.html)
+--- Thread: Separator unmatched - file hccapx (/thread-10441.html)

Separator unmatched - file hccapx - MariuszPoz - 11-03-2021

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

[Video: https://www.youtube.com/watch?v=J8A8rKFZW-M&t=13s&ab_channel=DavidBombal]

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

[Image: HiK8Mnt.jpg]

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.

RE: Separator unmatched - file hccapx - ZerBea - 11-03-2021

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.html?highlight=PMKID+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

RE: Separator unmatched - file hccapx - MariuszPoz - 11-04-2021

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:

Quote:$ hashcat -m 22000 hash.hc22000 wordlist.txt

for dictionary attack works just fine.

This for brute force:

Quote: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.

RE: Separator unmatched - file hccapx - ZerBea - 11-04-2021

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:
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 

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=........ 

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=........ 

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=........ 

17:36:53,932408              → 2c:56:dc:4f:ef:a8 (RA) 802.11 10 Acknowledgement, Flags=........ 

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=........ 

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=........ 

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=........ 

17:36:53,937965              → 68:3e:34:29:8e:42 (RA) 802.11 10 Acknowledgement, Flags=........ 

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=........ 

17:36:53,938796              → 7c:76:35:15:44:4c (RA) 802.11 10 Acknowledgement, Flags=........ 

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=........ 

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=........ 

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=........ 

17:36:53,944707              → 68:3e:34:29:8e:42 (RA) 802.11 10 Acknowledgement, Flags=........ 

17:36:53,946284 2c:56:dc:4f:ef:a8 → 7c:76:35:15:44:4c EAPOL 155 Key (Message 1 of 4) 

17:36:53,946531              → 2c:56:dc:4f:ef:a8 (RA) 802.11 10 Acknowledgement, Flags=........ 

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=........ 

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=........ 

17:36:53,949132 7c:76:35:15:44:4c → 2c:56:dc:4f:ef:a8 EAPOL 157 Key (Message 2 of 4) 

17:36:53,949407              → 7c:76:35:15:44:4c (RA) 802.11 10 Acknowledgement, Flags=........ 

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=........ 

17:36:53,953794 2c:56:dc:4f:ef:a8 → 7c:76:35:15:44:4c EAPOL 189 Key (Message 3 of 4) 

17:36:53,954039              → 2c:56:dc:4f:ef:a8 (RA) 802.11 10 Acknowledgement, Flags=........ 

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=........ 

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=........ 

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=........ 

17:36:53,959569              → 68:3e:34:29:8e:42 (RA) 802.11 10 Acknowledgement, Flags=........ 

17:36:53,961085 7c:76:35:15:44:4c → 2c:56:dc:4f:ef:a8 EAPOL 133 Key (Message 4 of 4) 

17:36:53,961350              → 7c:76:35:15:44:4c (RA) 802.11 10 Acknowledgement, Flags=........ 

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=........ 

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=........ 

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=........ 

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.

RE: Separator unmatched - file hccapx - MariuszPoz - 11-09-2021

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?

RE: Separator unmatched - file hccapx - ZerBea - 11-09-2021

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/threat-research-blog/cracking-wifi-at-scale-with-one-simple-trick

The 4way handshake (identifier WPA*02) calculation is explained here:
https://www.wifi-professionals.com/2019/01/4-way-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.