Mode 22000 format question

[s3in!c]

Hi everyone

I have a specific question regarding the 22000 mode. The input hash looks like that:

Code:

WPA*01*4d4fe7aac3a2cecab195321ceb99a7d0*fc690c158264*f4747f87f9f4*686173686361742d6573736964***

When cracked, hashcat delivers a completely differently formatted output:

Code:

4d4fe7aac3a2cecab195321ceb99a7d0:fc690c158264:f4747f87f9f4:hashcat-essid:hashcat!

I'm wondering if there is a specific reason for this?
Because IMHO this is not good to have hashes printed differently when they are cracked than how the were put into hashcat.

[ZerBea]

Maybe a good idea to add an option to hashcat - [ Outfile Formats ] -
to print either the short form:

Code:

MIC/PMKID:MAC_AP:MAC_CLIENT:ESSID:PSK

or the long form:

Code:

complete hash line:PSK

Most parts of the WPA*02* hash line are zeroed. To save disk space, for me, the short form is enough to identify and find the hash via MIC or PMKID running bash tools.

I strongly recommend to archive the pcapng files, because they contain much more information than a hash file.
Also you should know, that in case of hcxdumptool attacks neither MAC_AP, nor MAC_CLIENT, nor ANONCE, nor SNONCE, nor EAPOL data, nor PMKID nor MIC is unique!

We are talking about hash files > 1GB (and more).

Code:

Session..........: hashcat
Status...........: Quit
Hash.Name........: WPA-PBKDF2-PMKID+EAPOL
Hash.Target......: db1.22000
Time.Started.....: Mon Dec 21 09:26:12 2020 (3 secs)
Time.Estimated...: Thu Dec 24 05:33:54 2020 (2 days, 20 hours)
Guess.Base.......: File (wl)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:   188.0 kH/s (10.05ms) @ Accel:8 Loops:64 Thr:1024 Vec:1
Recovered........: 3578/649153 (0.55%) Digests, 6/205190 (0.00%) Salts
Remaining........: 645575 (99.45%) Digests, 205184 (100.00%) Salts
Recovered/Time...: CUR:N/A,N/A,N/A AVG:21,1285,30860 (Min,Hour,Day)
Progress.........: 2855496/46122813390 (0.01%)
Rejected.........: 2462280/2855496 (86.23%)
Restore.Point....: 0/224781 (0.00%)
Restore.Sub.#1...: Salt:3 Amplifier:0-1 Iteration:0-6
Candidates.#1....: $HEX[0000000000000000] -> $HEX[533238303531393730]
Hardware.Mon.#1..: Temp: 41c Util: 94% Core:1905MHz Mem:4001MHz Bus:8

or

Session..........: hashcat
Status...........: Running
Hash.Name........: WPA-PBKDF2-PMKID+EAPOL
Hash.Target......: db2.22000
Time.Started.....: Mon Dec 21 09:27:18 2020 (1 sec)
Time.Estimated...: Sun Dec 27 20:27:44 2020 (6 days, 11 hours)
Guess.Base.......: File (wl)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:   188.2 kH/s (10.04ms) @ Accel:8 Loops:64 Thr:1024 Vec:1
Recovered........: 0/1233439 (0.00%) Digests, 0/467282 (0.00%) Salts
Remaining........: 1233439 (100.00%) Digests, 467282 (100.00%) Salts
Recovered/Time...: CUR:N/A,N/A,N/A AVG:0,0,0 (Min,Hour,Day)
Progress.........: 5738456/105036115242 (0.01%)
Rejected.........: 5607384/5738456 (97.72%)
Restore.Point....: 0/224781 (0.00%)
Restore.Sub.#1...: Salt:1 Amplifier:0-1 Iteration:896-960
Candidates.#1....: $HEX[0000000000000000] -> $HEX[533238303531393730]
Hardware.Mon.#1..: Temp: 43c Util: 27% Core:1830MHz Mem:4001MHz Bus:8

That is the main reason why hashcat stores only the PBKDF2 data (PMK, ESSID, PSK) in the potfile. That will keep the potfile small in case of really big hash files. If you are experienced, the PBKDF2 result is all you need, because the PMK is uniq on a WPA1/WPA2/WPA2 keyver 3 network that uses this algo to calculate the PMK from a PSK.

Please read more here (why we came to this decision):
https://github.com/hashcat/hashcat/issues/1816

Please do not wonder about the low hash rate. I prefer running more machines with a single small and cheap GPU running smaller wordlists calculated by hcxtools, than one machine with 8 big GPUs running on an excessive wordlists downloaded from the internet.

BTW:
Please use the example hashes from here if you post an example:
https://hashcat.net/wiki/doku.php?id=example_hashes
because it is against the forum rules to comment real hashes

[s3in!c]

Thanks for the detailed explanation, WPA seems to be a hassle all the time in different variants and formats

I think in that case I'll have to adjust that in Hashtopolis, as it seems that it's much more complicated to adjust in hashcat. Also, having a separate flag to print the full output would help a bit, but I would still need to add the special case, so better not spend time on doing that in hashcat.

[ZerBea]

Yes, you're absolutely right, when you mention the different variants and formats of WPA. Compared to md5 or sha1, EAPOL message pairs and PMKIDs of a network are not unique. This hashes depend on the current session to secure the traffic. That will lead to many, many different hashes on a single network, because every connection attempt will result in a new hash. This will increase the size of the hash files and the outfiles enormous. Luckily the PMK on a network is static. As long as the admin doesn't change ESSID (SALT) or PSK the PMK will be the same on this network. The calculation of a PMK by PBKDF2 is very GPU cycle intensive.
If you take a look at the potfile, you'll see exactly the result of the PBKDF2 calculation (all parameters to reproduce it: HASH, SALT, PASSWORD). You can try wlangenpmk (-e -p) to verify the hash.
It will save much GPU time, if you set your focus on the PMK, because PBKDF2 calculation was already done. On networks, running the same ESSID you will get the results for the "price" of one (PBKDF2 calculation). The same applies to different networks, using the same ESSID if you captured a PMKID from the first network and an EAPOL message pair from the second network. In that case you will also get 2 results for the "price" of one calculation.
This verification/evaluation/calculation is running in the background on wpa-sec (https://wpa-sec.stanev.org/?). It is extreme fast.
It would be great to see this in Hashtopolis, too.

BTW:
The source is here:
https://github.com/RealEnder/dwpa

Stay healthy
cheers
Mike

Interested in more? Discussion is moved to this place:
https://github.com/s3inlc/hashtopolis/issues/678