+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Support (https://hashcat.net/forum/forum-3.html)
+--- Forum: hashcat (https://hashcat.net/forum/forum-45.html)
+--- Thread: Plugins 2500/2501 and 16800/16801 are deprecated (/thread-10253.html)
RE: Plugins 2500/2501 and 16800/16801 are deprecated - CUwindows00 - 09-18-2021
Hello, ZerBea
I will show you a handshake package file again, hope you can use a more accurate algorithm to solve it.
https://hashcat.net/cap2hashcat/
This is the hc22000 format I converted from your website. I found that it doesn't seem to extract a valid hash, but I can tell you for sure that the file contains at least one valid password. Valid password: ht3466227
I try to use the hccapx algorithm format conversion, it can extract a valid hash.
In fact, I have collected a lot of such special handshake packages, and I tested them one by one, and found that the other files were no problem, only this handshake package file had a problem.
I have always liked your algorithm, because I tested thousands of such handshake files with your algorithm, and no problems have been found so far.
RE: Plugins 2500/2501 and 16800/16801 are deprecated - ZerBea - 09-18-2021
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:
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.
RE: Plugins 2500/2501 and 16800/16801 are deprecated - CUwindows00 - 09-18-2021
Thanks, ZerBea
It's been too long, I can't remember it, it should be the minidwep-gtk tool used
In fact, after improving the following 2 questions, it is very perfect, please believe me
As you said, if you want to prevent missing some possible passwords, you need to extract all possible hashes
After extracting all possible hashes, we then mark those hashes as valid, so that everyone can understand at a glance. When using Hashcat to recover, put all the hashes in for recovery. If the password is recovered, you can clearly see whether the recovered hash is valid.
E.g
Code:
WPA*02*1709ba709b92c3eb7b662036b02e843c*6c5940096fb6*64cc2edaeb52*6c686c64*ca37bb6be93179b0ce86e0f4e393d742fca6854ace6791f29a7d0c0ec1534086*0103007502010a00000000000000000001f09960e32863aa57ba250769b6e12d959a5a1f1cc8939d6bed4401a16092fa72000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*00
Valid*WPA*02*8b01e5cdce2ceea155bab2d2c890bf6b*6c5940096fb6*8473033aba70*6c686c64*9914f0f49b7947142f74501c1f5dec2b859be7b56be607b8d4e0576acf3d6ffe*0103007502010a000000000000000000013384539f89fec79de93e258534c6bdded858b12fce70158d65841b31afd52ba7000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*02E.g
When the password is restored...
Code:
78c535fa1351bab54806dc3b518babd50d4aa989f91df153372d76553be8cb24*6c686c64:123456789
Valid*68123e2953fe9f0e0145adab48d8b2c20dc44612ee423b32bdc8dae1f6540921*6c686c64:19901013ldI think it is the best solution
RE: Plugins 2500/2501 and 16800/16801 are deprecated - ZerBea - 09-18-2021
Please notice my wording:
Valid message pairs are message pairs of which we can recover a PSK!
challenge = M1M2 - CLIENT may not belong to the target NETWORK
authorized = M2M3, M3M2 or M1M4 - CLIENT belong to the target NETWORK
This information is stored in the message pair field at the end of the hash line.
In your case:
00 = challenge - CLIENT may not belong to the target NETWORK
02 = M2M3 - CLIENT belong to the target NETWORK
Both of the converted message pairs are valid and we recovered a PSK.
The first one doesn't belong to your target network.
The second one belong to your target network.
Invalid message pairs are message pairs that doesn't contain matching EAPOL messages (regardless if the RC is matching, too or not). This is caused by packet loss or excessive deauthentications. It is impossible to recover a PSK from this message pairs:
challenge = M1M2
authorized = M2M3, M3M4 or M1M4
Even if you know the correct PSK, hashcat will exhausted on them!
The second cap file contain 24 message pairs. 13 of them are unique.
But only one(!) message pair is valid - all others are invalid due to packet loss or excessive deauthentications.
For sure, you can make a feature request to add this overhead to hashcat, here:
https://github.com/hashcat/hashcat/issues
If Atom decided to add this, hcxtools will follow.
But from my point of view there is absolutely no need to add this overhead to the hash line, because this information (and much more) is stored in the message pair field.
This is a script that will get all authorized message pairs from a .hc22000 file and store it to another .hc2200 file without adding overhead and not slowing hashcat down due to this overhead:
Code:
#!/bin/bash
if [ "$#" -ne 2 ];
then echo "usage: input.hc22000 output.hc22000"
exit
fi
cat $1 | grep "WPA.02" | grep "2$" | sort | uniq > $2Open editor and insert text.
Store the script to "getauthorized".
Make it executable:
$ chmod -x getauthorized
Use it:
./getauthorized myhashfile.hc22000 authorized.hc22000
or copy it to /usr/local/bin
Now, "authorized.hc22000" will contain all M2M3 (authorized) message pairs, only.
As mentioned before, this is the advantage of machine readable hash files.
There is no need to add "authorized" to each hash line, because all hashes inside authorized.hc22000 are authorized.
Please notice:
If you run hcxpcapngtool on "crapy" dump files stored from stupid attacks, it is not recommended to run default options, only. Especially not, if hcxpcapngtool show you a warning!
RE: Plugins 2500/2501 and 16800/16801 are deprecated - ZerBea - 09-19-2021
@CUwindows00
After some more analysis and several tests (hashcat), I noticed that hashcat nonce-error-corrections is broken (on BE and LE ANONCEs). Hascat is not longer able to recover the PSK on hashes that require NC. That explained the bad result of your second cap file.
I opened an issue report here and sent a mail to Atom with some more information:
https://github.com/hashcat/hashcat/issues/2987
RE: Plugins 2500/2501 and 16800/16801 are deprecated - ZerBea - 09-19-2021
@Snoopy
hashcat team has updated the wiki. Thank's for the good piece of work.
https://hashcat.net/wiki/doku.php?id=cracking_wpawpa2
RE: Plugins 2500/2501 and 16800/16801 are deprecated - CUwindows00 - 09-20-2021
@ZerBea,
Thanks...
Hope to support the completion of the conversion of the hash format in the windows environment, because it is used frequently in the windows environment, far more than other systems
Your should know that most people who use Hashcat also run in windows
RE: Plugins 2500/2501 and 16800/16801 are deprecated - ZerBea - 09-20-2021
Atom is a little bit busy this week. He told me that he is back next Sunday. Then hashcat will receive the NC fix.
Activating/using NC feature of hcxpcapngtool and hashcat will have a huge impact, especially on "crappy" cap files. And this cap file is a kind of "crapy" due to massive dauthentications and lost packets.
But anyway, by activated NC it is possible to recover the PSK from all(!) message pairs.
For sure, this need some additional options to be selected on hcxpcapngtool and hashcat.
Additional you can choose a higher NC than default (8) by hashcat --nonce-error-corrections as I did it for the demonstration below.
To demonstrate that, I converted the cap file to hccapx and 22000. Both hash files contain exactly the same hashes!
hash mode 2500 is still working:
Code:
$ hcxpcapngtool --hccapx=test.hccapx --all ht3466227.cap
$ hashcat -m 2500 --deprecated-check-disable --nonce-error-corrections=128 test.hccapx -a 3 ht3466227
hashcat (v6.2.4-67-gdbefc7e60) starting
Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 2500 (WPA-EAPOL-PBKDF2)
Hash.Target......: test.hccapx
Time.Started.....: Mon Sep 20 08:51:19 2021 (0 secs)
Time.Estimated...: Mon Sep 20 08:51:19 2021 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Mask.......: ht3466227 [9]
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 6 H/s (1.42ms) @ Accel:8 Loops:256 Thr:512 Vec:1
Recovered........: 13/13 (100.00%) Digests
Progress.........: 1/1 (100.00%)
Rejected.........: 0/1 (0.00%)
Restore.Point....: 0/1 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:12-25
Candidate.Engine.: Device Generator
Candidates.#1....: ht3466227 -> ht3466227
Hardware.Mon.#1..: Temp: 55c Fan: 36% Util: 82% Core:1898MHz Mem:5005MHz Bus:16hash mode 22000 failed due to its NC issue:
Code:
$ hcxpcapngtool -o test.22000 --all ht3466227.cap
$ hashcat -m 22000 --nonce-error-corrections=128 test.22000 -a 3 ht3466227hashcat (v6.2.4-67-gdbefc7e60) starting
hashcat (v6.2.4-67-gdbefc7e60) starting
Session..........: hashcat
Status...........: Exhausted
Hash.Mode........: 22000 (WPA-PBKDF2-PMKID+EAPOL)
Hash.Target......: test.22000
Time.Started.....: Mon Sep 20 08:53:02 2021 (0 secs)
Time.Estimated...: Mon Sep 20 08:53:02 2021 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Mask.......: ht3466227 [9]
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 25 H/s (1.43ms) @ 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: 54c Fan: 35% Util: 62% Core:1860MHz Mem:5005MHz Bus:16BTW:
If you're interested in that stuff and what it looks like behind the scenes, I recommend to use Linux.
hcxdumptool/hcxlabtool share additional EAPOL information with hcxpcapngtool via pcapng comment block and hcxpcapngtool share this information with hashcat via messagepair field.
In other words, this chain
hcxdumptool/hcxlabtool -> hcxpcapngtool -> hcxtools -> hashcat/JtR
can do magic, if you know what to do (e.g. by using their additional options).
RE: Plugins 2500/2501 and 16800/16801 are deprecated - CUwindows00 - 09-21-2021
@ atom @ZerBea
https://hashcat.net/cap2hashcat
Online conversion needs to add 3 improvements
1. Display ESSID
2. Display BSSID
3. Display each verification hash
E.g
Code:
ESSID :abc
BSSID :C8:3A:35:E9:65:E1
EAPOL messages (total)...................: 4
EAPOL RSN messages.......................: 4
ESSID (total unique).....................: 1
EAPOLTIME gap (measured maximum usec)....: 3083
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)
PMKID : WPA*01*3736d3870084b3c5e3f9f380bc8cc63c*c83a3551bdd0*6091f35dcefc*54656e64615f353142444430***
EAPOL M3M2: WPA*02*8b01e5cdce2ceea155bab2d2c890bf6b*6c5940096fb6*8473033aba70*6c686c64*9914f0f49b7947142f74501c1f5dec2b859be7b56be607b8d4e0576acf3d6ffe*0103007502010a000000000000000000013384539f89fec79de93e258534c6bdded858b12fce70158d65841b31afd52ba7000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*02
EAPOL M1M2: WPA*02*1709ba709b92c3eb7b662036b02e843c*6c5940096fb6*64cc2edaeb52*6c686c64*ca37bb6be93179b0ce86e0f4e393d742fca6854ace6791f29a7d0c0ec1534086*0103007502010a00000000000000000001f09960e32863aa57ba250769b6e12d959a5a1f1cc8939d6bed4401a16092fa72000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*00
EAPOL M1M4: WPA*02*36c43abeb5ce0e23af27a670fc0f31f0*083e8ef2a805*14d1699f4073*e997ae363033*c25b1178afed98cea562306a50bbc248564d44fe1dcd334b3c24f29abb1a88e5*0103007502010a00000000000000000000d657a56e46d4c845cb3f4a2d95732b06936cd3c0fbe5db06cceee66a1791abd6000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*02RE: Plugins 2500/2501 and 16800/16801 are deprecated - ZerBea - 09-21-2021
hcxhashtool exactly provide all this information for every hash inside the hc22000 file:
Code:
$ hcxhashtool -i hashfile.hc22000 --info=hashfile.info
SSID.......: ESSID (network name)
MAC_AP.....: xxxxxxxxxxxx (manufacturer)
MAC_CLIENT.: xxxxxxxxxxxx (manufacturer)
VERSION....: 802.1X-2004 (2)
KEY VERSION: WPA2
REPLAYCOUNT: 1
RC INFO....: NC suggested
MP M1M2 E2.: challenge
MIC........: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
HASHLINE...: WPA*02*xxxxxxxx
SSID.......: ESSID (network name)
MAC_AP.....: xxxxxxxxxxxx (manufacturer)
MAC_CLIENT.: xxxxxxxxxxxx (manufacturer)
PMKID......: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
HASHLINE...: WPA*01*xxxxxxxxI don't think it is the job of an online converter to provide this additional information - but that is not my decision.
I love the KISS principle:
Keep It Simple, Stupid
https://en.wikipedia.org/wiki/KISS_principle
I love the Linux philosophy:
Small is Beautiful
Each Program Does One Thing Well
Prototype as Soon as Possible
Choose Portability Over Efficiency
Store Data in Flat Text Files
Use Software Leverage
Use Shell Scripts to Increase Leverage and Portability
Avoid Captive User Interfaces
Make Every Program a Filter
https://opensource.com/business/15/2/how-linux-philosophy-affects-you
And of course, the Arch Linux philosophy:
Simplicity
Modernity
Pragmatism
User centrality
Versatility
https://wiki.archlinux.org/title/Arch_Linux
You'll see this principle and this philosophy in each of my tools.