Please mask or remove the 22000 hash line from your comment, because it is against the forum rules to comment real hashes, here.
You can remove your attachments, too.
First of all, may I ask two questions:
What tool did you used to capture the traffic?
Why did you ran so many deauthentications?
If you take a look inside your capfile, you'll notice in packet 3 a BEACON (the only one), with this ESSID:
Tag: SSID parameter set: GxC3xBCl's
But the ESSIDs in the PROBERESPONSE frames are different to the BEACON frame:
ESSID changes (detected maximum).........: 1 (information: option --max-essids=<digit> and --all recommended)
That let me assume that your capturing tool picked up the wrong BEACON (and this is an issue of the capturing tool).
You can use tshark to verify this:
Every conversion tool will see this captured ESSID and convert it (by default options).
BTW:
The quality of your captured file is terrible!
Too many deauthentications.
DEAUTHENTICATION (total).................: 36409
to retrieve a single EAPOL MESSAGE pair:
EAPOL pairs (best).......................: 1
Runnig this massive deauthentications you'll spam the entire WiFi channel!
You're going to make the AP and the CLIENT "crazy" and they'll reset their EAPOL counters (which result in uncrackable EAPOL messages).
Timestamps damaged! They are not in a row.
Important frames (from which the PSK can be recovered) are missing.
Only one BEACON inside. If this BEACON is wrong, you'll never recover the PSK (explained before)!
hcxpcapngtool result in detail (Wireshark and tshark showing a similar result):
In other words, neither a standard conversion tool nor hashcat can work on this capture file.
BTW - to answer your questions:
"I have a cap file and when i send this file to a cracking servide, SSID is correctly defined = Router SSID (Gül's Home) and it is cracked!"
For sure, most of the online services running hcxtools (with advanced options).
https://hashcat.net/forum/thread-9893-po...l#pid51787
https://wpa-sec.stanev.org/?search=G%C3%BCl%27s+Home
"How can I make it look right ssid name in hccapx or in 22000 hash?
This is my problem. SSID doen not look right?"
This is not your problem and it is not the problem of hashcat!
It is the problem of the tool you used for capturing!
If the capturing tool is missing some frames, they are gone for ever!
None of the following tools in the workflow (conversion tool to a format hashcat accept, and hashcat itself) can bring it back or is able to recover the PSK from it!
However, xcxpcapngtool will provide some options to work on that cap file, but don't rely on it. If you do the conversion again, running option --max-essids=2 you'll get two 22000 hash lines:
One which is wrong (ESSID) 477843337842436c2773
You can't recover the PSK from it in hash mode 22000 (by (PBKDF2).
But you can verify the hash running hash mode 22001 with the PMK recovered from the correct ESSID:
One which is possible the correct ESSID 47c3bc6c277320486f6d65
Hashcat may be able to recover the PSK from it 47c3bc6c277320486f6d65
You can use the recovered PMK to verify the PSK of the hash line with the wrong ESSID by hash mode 22001.
Verifying a network by PMK is explained here:
https://hashcat.net/forum/thread-9893.html
In detail:
Please, be so kind an comment the command lines you used
to capture the traffic
to convert the captured file to a hash format hashcat accepts
to recover the PSK by running hashcat
That makes it much easier to figure out, what exactly went wrong in your workflow.
You can remove your attachments, too.
First of all, may I ask two questions:
What tool did you used to capture the traffic?
Why did you ran so many deauthentications?
If you take a look inside your capfile, you'll notice in packet 3 a BEACON (the only one), with this ESSID:
Tag: SSID parameter set: GxC3xBCl's
Code:
3 Feb 21, 2021 08:22:01.616000000 CET GxC3xBCl'sBut the ESSIDs in the PROBERESPONSE frames are different to the BEACON frame:
ESSID changes (detected maximum).........: 1 (information: option --max-essids=<digit> and --all recommended)
Code:
37 Feb 21, 2021 08:22:04.598014000 CET Gül's Home
38 Feb 21, 2021 08:22:04.605181000 CET Gül's Home
39 Feb 21, 2021 08:22:04.769532000 CET Gül's HomeYou can use tshark to verify this:
Code:
$ tshark -r 1.cap -T fields -E header=y -e frame.number -e frame.time -e wlan.ssidEvery conversion tool will see this captured ESSID and convert it (by default options).
BTW:
The quality of your captured file is terrible!
Too many deauthentications.
DEAUTHENTICATION (total).................: 36409
to retrieve a single EAPOL MESSAGE pair:
EAPOL pairs (best).......................: 1
Runnig this massive deauthentications you'll spam the entire WiFi channel!
You're going to make the AP and the CLIENT "crazy" and they'll reset their EAPOL counters (which result in uncrackable EAPOL messages).
Timestamps damaged! They are not in a row.
Code:
Packet.Nr. Date Time
67989 Feb 21, 2021 08:33:52.858111000 CET
67990 Feb 21, 2021 08:33:52.858109000 CET
67991 Feb 21, 2021 08:33:52.858111000 CET
67992 Feb 21, 2021 08:33:52.858109000 CET
67993 Feb 21, 2021 08:33:52.858111000 CET
67994 Feb 21, 2021 08:33:52.858111000 CET
...
68235 Feb 21, 2021 08:33:53.474110000 CET
68236 Feb 21, 2021 08:33:53.474109000 CET
68237 Feb 21, 2021 08:33:53.478717000 CET
68238 Feb 21, 2021 08:33:53.478719000 CET
68239 Feb 21, 2021 08:33:53.478717000 CETImportant frames (from which the PSK can be recovered) are missing.
Only one BEACON inside. If this BEACON is wrong, you'll never recover the PSK (explained before)!
hcxpcapngtool result in detail (Wireshark and tshark showing a similar result):
Code:
$ hcxpcapngtool -o test.22000 1.cap
reading from 1.cap...
summary capture file
--------------------
file name................................: 1.cap
version (pcap/cap).......................: 2.4 (very basic format without any additional information)
timestamp minimum (GMT)..................: 21.02.2021 08:22:01
timestamp maximum (GMT)..................: 21.02.2021 09:45:52
used capture interfaces..................: 1
link layer header type...................: DLT_IEEE802_11 (105)
endianess (capture system)...............: little endian
packets inside...........................: 85311
BEACON (total)...........................: 1
ACTION (total)...........................: 126
PROBEREQUEST (directed)..................: 5
PROBERESPONSE............................: 2123
DEAUTHENTICATION (total).................: 36409
DISASSOCIATION (total)...................: 2
AUTHENTICATION (total)...................: 166
AUTHENTICATION (OPEN SYSTEM).............: 166
ASSOCIATIONREQUEST (total)...............: 26
ASSOCIATIONREQUEST (PSK).................: 26
WPA encrypted............................: 683
EAPOL messages (total)...................: 20
EAPOL RSN messages.......................: 20
ESSID (total unique).....................: 2
ESSID changes (detected maximum).........: 1 (information: option --max-essids=<digit> and --all recommended)
EAPOLTIME gap (measured maximum usec)....: 56630291
EAPOL ANONCE error corrections (NC)......: not detected
REPLAYCOUNT gap (measured maximum).......: 3
EAPOL M1 messages (total)................: 12
EAPOL M2 messages (total)................: 1
EAPOL M3 messages (total)................: 4
EAPOL M4 messages (total)................: 3
EAPOL pairs (total)......................: 2
EAPOL pairs (best).......................: 1
EAPOL pairs written to combi hash file...: 1 (RC checked)
EAPOL M32E2 (authorized).................: 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...................: 1In other words, neither a standard conversion tool nor hashcat can work on this capture file.
BTW - to answer your questions:
"I have a cap file and when i send this file to a cracking servide, SSID is correctly defined = Router SSID (Gül's Home) and it is cracked!"
For sure, most of the online services running hcxtools (with advanced options).
https://hashcat.net/forum/thread-9893-po...l#pid51787
https://wpa-sec.stanev.org/?search=G%C3%BCl%27s+Home
"How can I make it look right ssid name in hccapx or in 22000 hash?
This is my problem. SSID doen not look right?"
This is not your problem and it is not the problem of hashcat!
It is the problem of the tool you used for capturing!
If the capturing tool is missing some frames, they are gone for ever!
None of the following tools in the workflow (conversion tool to a format hashcat accept, and hashcat itself) can bring it back or is able to recover the PSK from it!
However, xcxpcapngtool will provide some options to work on that cap file, but don't rely on it. If you do the conversion again, running option --max-essids=2 you'll get two 22000 hash lines:
One which is wrong (ESSID) 477843337842436c2773
You can't recover the PSK from it in hash mode 22000 (by (PBKDF2).
But you can verify the hash running hash mode 22001 with the PMK recovered from the correct ESSID:
One which is possible the correct ESSID 47c3bc6c277320486f6d65
Hashcat may be able to recover the PSK from it 47c3bc6c277320486f6d65
You can use the recovered PMK to verify the PSK of the hash line with the wrong ESSID by hash mode 22001.
Verifying a network by PMK is explained here:
https://hashcat.net/forum/thread-9893.html
In detail:
Code:
WPA*02*MIC*MAC_AP*MAC_STA*477843337842436c2773*...
WPA*02*MIC*MAC_AP*MAC_STA*47c3bc6c277320486f6d65*...
[code]
You can verify the ESSID by pearl command:
[code]
$ echo "47c3bc6c277320486f6d65" | perl -pe 's/(..)/chr(hex($1))/ge'
Gül's HomePlease, be so kind an comment the command lines you used
to capture the traffic
to convert the captured file to a hash format hashcat accepts
to recover the PSK by running hashcat
That makes it much easier to figure out, what exactly went wrong in your workflow.