Plugins 2500/2501 and 16800/16801 are deprecated

[atom]

---

Since version 6.0.0, hashcat has been offering the new hash mode 22000, which we have not discussed in detail so far:

Code:

  22000 | WPA-PBKDF2-PMKID+EAPOL
  22001 | WPA-PMK-PMKID+EAPOL

Our goal is to replace the existing hash modes 2500 and 16800 (the .hccap and .hccapx file formats) with the new hash mode 22000:

  2500 | WPA-EAPOL-PBKDF2
  2501 | WPA-EAPOL-PMK

  16800 | WPA-PMKID-PBKDF2
  16801 | WPA-PMKID-PMK

With this thread we want to explain the reasons for the update and explain the details of the new format.

We should have added this announcement at the same time as the release of the new hash mode to get the community's attention. We're seeing some movement towards the new 22000 mode, but we're also seeing a lot of people referring to outdated techniques when it comes to WPA cracking in general, and most of the time they involve hash mode 2500, 16800, or even older tools.

We want to set up a reference that you can link to people who are still using old tools formats and techniques. This will probably never end as there are so many (now outdated) videos, documents, tutorials, training courses in the wild. But we have to get started somewhere.

If you see people talking about using -m 2500 or -m 16800, link them to this thread.

Note: this is not a new attack like PMKID was.

---

So what are the benefits of hash mode 22000?

• The hash mode 22000 hash line combines PMKIDs and EAPOL MESSAGE PAIRs in a single file
  
• Having all the different handshake types in a single file allows for efficient reuse of PBKDF2 to save GPU cycles
  
• It is no longer a binary format that allows various standard tools to be used to filter or process the hashes
  
• It is no longer a binary format which makes it easier to copy / paste anywhere as it is just text
  
• The best tools for capturing and filtering WPA handshake output in hash mode 22000 format (see tools below)
  

---

In order to be able to use the hash mode 22000 to the full extent, you need the following tools:

• hcxdumptool v6.0.0 or higher: https://github.com/ZerBea/hcxdumptool
  
• hcxpcapngtool from hcxtools v6.0.0 or higher: https://github.com/ZerBea/hcxtools
  
• hashcat v6.0.0 or higher: https://github.com/hashcat/hashcat
  

Optionally there is hcxlabtool, which you can use as an experienced user or in headless operation instead of hcxdumptool: https://github.com/ZerBea/wifi_laboratory

For users who don't want to struggle with compiling hcxtools from sources there is an online converter: https://hashcat.net/cap2hashcat/

If you choose the online converter, you may need to remove some data from your dump file if the file size is too large. Most of the time, this happens when data traffic is also being recorded.

You can reduce the size by tshark:

Code:

tshark -r dumpfile.cap/pcap -R "(wlan.fc.type_subtype == 0x00 || wlan.fc.type_subtype == 0x02 || wlan.fc.type_subtype == 0x04 || wlan.fc.type_subtype == 0x05 || wlan.fc.type_subtype == 0x08 || eapol)" -2 -F pcapng -w stripped.pcapng

---

ATTENTION!!! Please read carefully and respect:

Do not clean up the cap / pcap file (e.g. with wpaclean), as this will remove useful and important frames from the dump file.
Do not use filtering options while collecting WiFi traffic.

---

The hcxdumptool / hcxlabtool offers several attack modes that other tools do not.

This includes the PMKID attack, which is described here: https://hashcat.net/forum/thread-7717.html

It also includes AP-less client attacks and a lot more.

The traffic is saved in pcapng format. This format is used by Wireshark / tshark as the standard format. Additional information (NONCE, REPLAYCOUNT, MAC, hash values calculated during the session) are stored in pcapng option fields. The hcxpcapngtool uses these option fields to calculate the best hash values in order to avoid unbreakable hashes at best.

In addition, Hashcat is told how to handle the hash via the message pair field. When hcxdumptool is connected to a GPS device, it also saves the GPS coordinates of the frames.

---

Examples of the target and how traffic is captured:

1.Stop all services that are accessing the WLAN device (e.g .: NetworManager and wpa_supplicant.service)

Code:

$ sudo systemctl stop NetworkManager.service
$ sudo systemctl stop wpa_supplicant.service

2. Start the attack and wait for you to receive PMKIDs and / or EAPOL message pairs, then exit hcxdumptool

Code:

$ hcxdumptool -i interface -o dumpfile.pcapng --active_beacon --enable_status=15

3. Restart stopped services to reactivate your network connection

Code:

$ sudo systemctl start wpa_supplicant.service
$ sudo systemctl start NetworkManager.service

4. Convert the traffic to hash format 22000

Code:

$ hcxpcapngtool -o hash.hc22000 -E wordlist dumpfile.pcapng

5. Run Hashcat on the list of words obtained from WPA traffic

Code:

$ hashcat -m 22000 hash.hc22000 wordlist.txt

For more options, see the tools help menu (-h or --help) or this thread: https://hashcat.net/forum/thread-6661-po...l#pid52103

Get more examples from here: https://github.com/evilsocket/pwnagotchi...-598597214

Run Hashcat on an excellent WPA word list or check out their free online service:

Code:

$ wget https://wpa-sec.stanev.org/dict/cracked.txt.gz
$ hashcat -m 22000 test.hc22000 cracked.txt.gz

Get more examples from here: https://github.com/hashcat/hashcat/issues/2923

---

Examples to work on hc22000 hash files:

Filter hash file by PMKID

Code:

$ grep 'WPA\*01' hash.hc22000 > pmkid.hc22000
$ hcxhashtool -i hash.hc22000 --type=1 -o pmkid.hc22000

Filter hash file by EAPOL

Code:

$ grep 'WPA\*02' hash.hc22000 > eapol.hc22000
$ hcxhashtool -i hash.hc22000 --type=2 -o eapol.hc22000

Filter by MAC:

Code:

$ grep 'WPA\*02' hash.hc22000
$ grep '\*112233445566\*' home.22000 > mac.hc22000
$ hcxhashtool -i home.22000 --mac-ap=112233445566 -o mac.hc22000
$ hcxhashtool -i home.22000 --mac-client=112233445566 -o mac.hc22000

---

For developers

The new hash format 22000 in detail:

Code:

PROTOCOL*TYPE*PMKID/MIC*MACAP*MACCLIENT*ESSID*ANONCE*EAPOL*MESSAGEPAIR

PROTOCOL = Fixed string "WPA"
TYPE = 01 for PMKID, 02 for EAPOL
PMKID/MIC = PMKID if TYPE=01, MIC if TYPE=02
MACAP = MAC of AP
MACCLIENT = MAC of CLIENT
ESSID = network name (ESSID) in HEX
ANONCE = ANONCE
EAPOL = EAPOL (SNONCE is in here)
MESSAGEPAIR = Bitmask:

• 0: MP info (https://hashcat.net/wiki/doku.php?id=hccapx)
  
• 1: MP info (https://hashcat.net/wiki/doku.php?id=hccapx)
  
• 2: MP info (https://hashcat.net/wiki/doku.php?id=hccapx)
  
• 3: x (unused)
  
• 4: ap-less attack (set to 1) - no nonce-error-corrections necessary
  
• 5: LE router detected (set to 1) - nonce-error-corrections only for LE necessary
  
• 6: BE router detected (set to 1) - nonce-error-corrections only for BE necessary
  
• 7: not replaycount checked (set to 1) - replaycount not checked, nonce-error-corrections definitely necessary
  

The pot file format in detail (resultat of PBKDF2 calculation):

Code:

PMK*ESSID:PSK

PMK = Plain Master Key
ESSID = network name (ESSID) in HEX
PSK = Pre Shared Key

The out file format in detail:

Code:

PMKID/MIC:MACAP:MACCLIENT:ESSID:PSK

PMKID/MIC = PMKID or MIC depending on hash type
MACAP = MAC of AP
MACCLIENT = MAC of CLIENT
ESSID = network name (ESSID) in plain
PSK = Pre Shared Key

All the discussion about finding the details of this new format is here: https://github.com/hashcat/hashcat/issues/1816

---

One last note: the plugins 2500/2501 and 16800/16801 receive a deprecated flag in the hashcat module that blocks the use of the plugin. There may be a parameter you can set to work around this if you really have to, but keep it to yourself :)

- atom

[ZerBea]

It is a good decision to retire 250x (especially the binary hccapx format) and 1680x hash modes.
Thanks for your efforts and your excellent work.

[CUwindows00]

Hi..

Need to verify valid hash
Convert cap to hc22000 hash format, I also did a lot of tests, you guys did a great job

However, I still feel that there are two issues that need improvement.

1. Mark the PMKID hash in front

2. The hash of the handshake is best to mark whether those hashes are valid, so that everyone can recover the password faster and save time

E.g..

Code:

PMKID*WPA*01*7f216085c9b501d2b8c72f95ce1096ad*fc7c023a4397*54bad65693c6*40504849434f4d4d5f3935***

NO*WPA*02*1709ba709b92c3eb7b662036b02e843c*6c5940096fb6*64cc2edaeb52*6c686c64*ca37bb6be93179b0ce86e0f4e393d742fca6854ace6791f29a7d0c0ec1534086*0103007502010a00000000000000000001f09960e32863aa57ba250769b6e12d959a5a1f1cc8939d6bed4401a16092fa72000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*00

YES*WPA*02*8b01e5cdce2ceea155bab2d2c890bf6b*6c5940096fb6*8473033aba70*6c686c64*9914f0f49b7947142f74501c1f5dec2b859be7b56be607b8d4e0576acf3d6ffe*0103007502010a000000000000000000013384539f89fec79de93e258534c6bdded858b12fce70158d65841b31afd52ba7000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*02

[ZerBea]

Your request will produce significant redundant overhead which is not necessary.
It is not the purpose of the hash line to be human readable. Instead it should be readable in a fast way by the the tools on the cracking machine (hashcat or bash tools or other tools like hcxhashtool - but definitely not by a human).

BTW1:
1. Mark the PMKID hash in front
The PMKID is marked in front as WPA*01

You can do filtering in a very easy way by bash tools:

get PMKIDs only:

Code:

$ cat hashfile.hc22000 | grep "WPA.01"

get authenticated handshakes only:

Code:

$ cat hashfile.hc22000 | grep "WPA.02" | grep "2$"

BTW2:
2. The hash of the handshake is best to mark whether those hashes are valid, so that everyone can recover the password faster and save time.
Every converted hash should be a valid hash (depending on the quality of the dump tool handling possible packet loss and the conversion tool regarding EAPOL TIME OUT, detecting NC, evaluation RC). The PSK from this hash is recoverable, but it may not belong to your target network if it is converted from M1M2.

Overview of valid MESSAGE PAIRs belonging to the same AUTHENTICATION SEQUENCE:
M1M2 = challenge and RC on M1 and M2 is the same
M2M3 = authenticated (by AP) and RC of M3 = RC M2 +1
M3M4 = authenticated (by CLIENT) and RC on M3 and M4 are the same
M1M4 = authenticated (by CLIENT) and RC of M1 = RC M4 +1

Example of invalid MESSAGE PAIRs (NC not possible = PSK not recoverable):
M1RC1M2RC9
M2RC3M3RC14

Example of invalid MESSAGE PAIRs that can be converted to valid MESSAGE PAIRS (NC possible = PSK recoverable) by hashcat default NC option (8):
M1RC1M2RC3
M2RC3M3RC5
It is not mandatory that they belong to the same AUTHENTICATION sequence, as long as NC is possible.

State of the art attack tools should detect a packet loss and request the packet again. Also they shouldn't run excessive deauthentications/disassociations which cause an AP to reset its EAPOL timers, counters and ANONCE or to start a new AUTHENTICATION sequence.
State of the art conversion tools should detect if NC is possible or not.

BTW3 (experienced users):
The most important MESSAGE PAIR is M1M2ROGUE coming from hcxdumptool/hcxlabtool attack against a weak CLIENT:

Code:

hcxdumptool option:
--stop_client_m2_attacks=<digit>   : stop attacks against CLIENTS after 10 M2 frames received
                                     affected: ap-less (EAPOL 2/4 - M2) attack
                                     require hcxpcangtool --all option

hcxlabtool option:
--m2attempt=<digit>       : reject CLIENT request after n received M2 frames
                            default: 10 received M2 frames

In combination with hcxpcapngtool --all and -E it will give useful information about the wpa_supplicant.conf entries of the CLIENT.

BTW4:
Please do not post real hashes, because it is against the forum rules.

Legend:
RC = replaycount
NC = nonce error correction on BE and LE routers
BE = big endian
LE = low endian
M1 = EAPOL message 1 (AP) of 4way handshake
M2 = EAPOL message 2 (CLIENT) of 4way handshake
M3 = EAPOL message 3 (AP) of 4way handshake
M4 = EAPOL message 4 (CLIENT) of 4way handshake (useless if SNONCE is zeroed)
ROGUE = coming from hcxdumptool/hcxlabtool attack
PSK = pre-shared key (password of the NETWORK)


Notice:
hcxhashtool provide various filtering options, especially on big hash files (e.g. > 100 hashes):

Code:

$ hcxhashtool -h
hcxhashtool 6.2.4-1-g34a4170 (C) 2021 ZeroBeat
usage:
hcxhashtool <options>

options:
-i <file>   : input PMKID/EAPOL hash file
-o <file>   : output PMKID/EAPOL hash file
-E <file>   : output ESSID list (autohex enabled)
-d          : download http://standards-oui.ieee.org/oui.txt
              and save to ~/.hcxtools/oui.txt
              internet connection required
-h          : show this help
-v          : show version

--essid-group                : convert to ESSID groups in working directory
                               full advantage of reuse of PBKDF2
                               not on old hash formats
--oui-group                  : convert to OUI groups in working directory
                               not on old hash formats
--mac-group-ap               : convert APs to MAC groups in working directory
                               not on old hash formats
--mac-group-client           : convert CLIENTs to MAC groups in working directory
                               not on old hash formats
--type=<digit>               : filter by hash type
                               bitmask:
                                1 = PMKID
                                2 = EAPOL
                               default PMKID and EAPOL (1+2=3)
--hcx-min=<digit>            : disregard hashes with occurrence lower than hcx-min/ESSID
--hcx-max=<digit>            : disregard hashes with occurrence higher than hcx-max/ESSID
--essid-len                  : filter by ESSID length
                               default ESSID length: 0...32
--essid-min                  : filter by ESSID minimum length
                               default ESSID minimum length: 0
--essid-max                  : filter by ESSID maximum length
                               default ESSID maximum length: 32
--essid=<ESSID>              : filter by ESSID
--essid-part=<part of ESSID> : filter by part of ESSID
--essid-list=<file>          : filter by ESSID file
--mac-ap=<MAC>               : filter AP by MAC
                               format: 001122334455, 00:11:22:33:44:55, 00-11-22-33-44-55 (hex)
--mac-client=<MAC>           : filter CLIENT by MAC
                               format: 001122334455, 00:11:22:33:44:55, 00-11-22-33-44-55 (hex)
--mac-list=<file>            : filter by MAC file
                               format: 001122334455, 00:11:22:33:44:55, 00-11-22-33-44-55 (hex)
--mac-skiplist=<file>        : exclude MAC from file
                               format: 001122334455, 00:11:22:33:44:55, 00-11-22-33-44-55 (hex)
--oui-ap=<OUI>               : filter AP by OUI
                               format: 001122, 00:11:22, 00-11-22 (hex)
--oui-client=<OUI>           : filter CLIENT by OUI
                               format: 001122, 00:11:22, 00-11-22 (hex)
--vendor=<VENDOR>            : filter AP or CLIENT by (part of) VENDOR name
--vendor-ap=<VENDOR>         : filter AP by (part of) VENDOR name
--vendor-client=<VENDOR>     : filter CLIENT by (part of) VENDOR name
--authorized                 : filter EAPOL pairs by status authorized
--notauthorized              : filter EAPOL pairs by status CHALLENGE (not authorized)
--rc                         : filter EAPOL pairs by replaycount status checked
--apless                     : filter EAPOL pairs by status M1M2ROGUE (M2 requested from CLIENT)
--info=<file>                : output detailed information about content of hash file
                               not in combination with --vendor, --vendor-ap or --vendor-client
--info=stdout                : stdout output detailed information about content of hash file
                               not in combination with --vendor, --vendor-ap or --vendor-client
--info-vendor=<file>         : output detailed information about ACCESS POINT and CLIENT VENDORs
                               not in combination with --vendor, --vendor-ap or --vendor-client
--info-vendor-ap=<file>      : output detailed information about ACCESS POINT VENDORs
                               not in combination with --vendor, --vendor-ap or --vendor-client
--info-vendor-client=<file>  : output detailed information about ACCESS POINT VENDORs
                               not in combination with --vendor, --vendor-ap or --vendor-client
--info-vendor=stdout         : stdout output detailed information about ACCESS POINT and CLIENT VENDORs
                               not in combination with --vendor, --vendor-ap or --vendor-client
--info-vendor-ap=stdout      : stdout output detailed information about ACCESS POINT VENDORs
                               not in combination with --vendor, --vendor-ap or --vendor-client
--info-vendor-client=stdout  : stdout output detailed information about ACCESS POINT VENDORs
                               not in combination with --vendor, --vendor-ap or --vendor-client
--psk=<PSK>                  : pre-shared key to test
                               due to PBKDF2 calculation this is a very slow process
                               no nonce error corrections
--pmk=<PMK>                  : plain master key to test
                               no nonce error corrections
--hccapx=<file>              : output to deprecated hccapx file
--hccap=<file>               : output to ancient hccap file
--hccap-single               : output to ancient hccap single files (MAC + count)
--john=<file>                : output to deprecated john file
--vendorlist                 : stdout output complete OUI list sorted by OUI
--help                       : show this help
--version                    : show version

[CUwindows00]

Hello, ZerBea


Let me give you an example
The following cap contains 2 different passwords, one of which is valid
password: 123456789
Valid password: 19901013ld

If we convert the hc22000 format, mark which WPA column is valid, so that we can use this WPA data recovery more accurately

Code:

WPA*02*1709ba709b92c3eb7b662036b02e843c*6c5940096fb6*64cc2edaeb52*6c686c64*ca37bb6be93179b0ce86e0f4e393d742fca6854ace6791f29a7d0c0ec1534086*0103007502010a00000000000000000001f09960e32863aa57ba250769b6e12d959a5a1f1cc8939d6bed4401a16092fa72000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*00

Valid*WPA*02*8b01e5cdce2ceea155bab2d2c890bf6b*6c5940096fb6*8473033aba70*6c686c64*9914f0f49b7947142f74501c1f5dec2b859be7b56be607b8d4e0576acf3d6ffe*0103007502010a000000000000000000013384539f89fec79de93e258534c6bdded858b12fce70158d65841b31afd52ba7000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*02

[ZerBea]

The last field of the hash line (...*xx) contain a bitmask with detailed information about the MESSAGEPAIR (machine readable and much more information than a simple yes or no):

Code:

bitmask of message pair field:
2,1,0:
000 = M1+M2, EAPOL from M2 (challenge)
001 = M1+M4, EAPOL from M4 if not zeroed (authorized)
010 = M2+M3, EAPOL from M2 (authorized)
011 = M2+M3, EAPOL from M3 (authorized) - unused
100 = M3+M4, EAPOL from M3 (authorized) - unused
101 = M3+M4, EAPOL from M4 if not zeroed (authorized)
3: reserved
4: ap-less attack (set to 1) - no nonce-error-corrections necessary
5: LE router detected (set to 1) - nonce-error-corrections only for LE necessary
6: BE router detected (set to 1) - nonce-error-corrections only for BE necessary
7: not replaycount checked (set to 1) - replaycount not checked, nonce-error-corrections definitely necessary

In your case
on the first hash:

Code:

...*00 = bitmask 00000000 = M1+M2, EAPOL from M2 (challenge)

on the second first hash:

Code:

...*02 = bitmask 00000010 = M2+M3, EAPOL from M2 (authorized)

Now you can run bash tools to get all MESSAGEPAIRs you want:

Code:

001 = M1+M4, EAPOL from M4 if not zeroed (authorized)
$ cat hashfile.hc22000 | grep "WPA.02" | grep "1$"

010 = M2+M3, EAPOL from M2 (authorized)
$ cat hashfile.hc22000 | grep "WPA.02" | grep "2$"

101 = M3+M4, EAPOL from M4 if not zeroed (authorized)
$ cat hashfile.hc22000 | grep "WPA.02" | grep "5$"

or, if you don't want NC to be in use:

Code:

001 = M1+M4, EAPOL from M4 if not zeroed (authorized)
$ cat hashfile.hc22000 | grep "WPA.02" | grep "01$"

010 = M2+M3, EAPOL from M2 (authorized)
$ cat hashfile.hc22000 | grep "WPA.02" | grep "02$"

101 = M3+M4, EAPOL from M4 if not zeroed (authorized)
$ cat hashfile.hc22000 | grep "WPA.02" | grep "05$"

Some more examples:

Code:

Get all PMKIDs, sort by MAC_AP:
$ cat hash.hc22000 | grep WPA.01 | sort -t "*" -k 4

Get all PMKIDs, sort by ESSID:
$ cat hash.hc22000 | grep WPA.01 | sort -t "*" -k 6

Get all authenticated MESSAGEPAIRs, NC not required, sort by MAC_AP:
$ cat hash.hc22000 | grep WPA.02 | grep 02$ | sort -t "*" -k 4

Get all authenticated MESSAGEPAIRs, NC not required, sort by ESSID:
$ cat hash.hc22000 | grep WPA.02 | grep 02$ | sort -t "*" -k 6

BTW:
I took a look at the attached cap file:
The capture file appears to have been cut short in the middle of a packet (packet 16063).
It looks like your capturing tool doesn't handle timestamps correctly.
You injected too many deauthentications. Some of them are injected directly into the authentication sequence between an EAPOL M1 and an EAPOL M2 message (packet 1187 - 1197). This mostly happens if you use stupid deauthentication tools which doesn't evaluate incoming frames.
Directed PROBEREQUEST frames are not stored or filtered out. From this frames we possible can get PSKs in the clear.
The radiotap header was removed.
Ancient cap file format is used to store packets.

Code:

$ hcxpcapngtool -o test.22000 123456789_19901013ld.cap
hcxpcapngtool 6.2.4-1-g34a4170 reading from 123456789_19901013ld.cap...
failed to read pcap packet header for packet 16063

summary capture file
--------------------
file name................................: 123456789_19901013ld.cap
version (pcap/cap).......................: 2.4 (very basic format without any additional information)
timestamp minimum (GMT)..................: 10.04.2016 06:06:45
timestamp maximum (GMT)..................: 10.04.2016 07:18:21
used capture interfaces..................: 1
link layer header type...................: DLT_IEEE802_11 (105)
endianess (capture system)...............: little endian
packets inside...........................: 16063
BEACON (total)...........................: 1
ACTION (total)...........................: 38
PROBEREQUEST (directed)..................: 5
PROBERESPONSE (total)....................: 106
DEAUTHENTICATION (total).................: 770
AUTHENTICATION (total)...................: 5
AUTHENTICATION (OPEN SYSTEM).............: 5
ASSOCIATIONREQUEST (total)...............: 2
ASSOCIATIONREQUEST (PSK).................: 2
WPA encrypted............................: 41
EAPOL messages (total)...................: 34
EAPOL RSN messages.......................: 34
ESSID (total unique).....................: 1
EAPOLTIME gap (measured maximum usec)....: 42501
EAPOL ANONCE error corrections (NC)......: not detected
REPLAYCOUNT gap (measured maximum).......: 3
EAPOL M1 messages (total)................: 5
EAPOL M2 messages (total)................: 27
EAPOL M3 messages (total)................: 1
EAPOL M4 messages (total)................: 1
EAPOL pairs (total)......................: 28
EAPOL pairs (best).......................: 2
EAPOL pairs written to combi hash file...: 2 (RC checked)
EAPOL M12E2 (challenge)..................: 1
EAPOL M32E2 (authorized).................: 1
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...................: 1

[CUwindows00]

Hello. ZerBea 

Thanks  Bring us very good tools

[ZerBea]

With a little help of bash tools, you should be able to get exactly the hash that you want to feed hashcat with.
The format identifier (WPA*01* or WPA*02 for type and the messag epair field for kind).
Please notice that there will be more identifier in future times. Therefor I asked Atom to block WPA*01* up to WPA*FF* for this purpose (WiFi related hash algorithms). Regarding this and the machine read ability it is really not a good idea to add a YES or NO here. The same applies to the message pair field, because this bit mask contain all information about the kind of the hash.

[Snoopy]

can we make this thread sticky or can someone add a link to this thread in the wiki for the wpa cracking page?

https://hashcat.net/wiki/doku.php?id=cracking_wpawpa2

[ZerBea]

I fully agree. This wiki entry is outdated. Additional it referenced rockyou.txt, which is very old word list.
The same applies to the old cap format. As of Wireshark 1.2.0, pcapng files can be read and written, and live captures can be done in pcapng format. Wireshark uses the pcapng file format as the default format to save captured packets, as well as hcxdumptool/hcxlabtool.
https://www.wireshark.org/docs/wsug_html...Files.html

I sent a PM to Atom regarding this wiki entry.