The pot file entry is the result of PBKDF2 calculation (hash mode 22000, 16800, 2500):
The PMK is unique for a complete network! That include the AP and all CLIENTs
Storing this unique result, only, will keep the pot file small.
hascat doesn't need further information to verify the NETWORK key!
Running hashcat with option -o will print what you expect to see:
The PMKID is unique for a single CLIENT of the NETWORK, only.
The MIC is unique for a single AUTHENTICATION of a single CLIENT of the NETWORK, only.
Storing this dynamic values to a pot file will bloat it and decrease speed.
This is valid for so long until the PSK or the ESSID changed. In that case you must hunt for the new PMK (which is the result of PBKDF2).
More information is here:
https://hashcat.net/forum/thread-9893.html
and here:
https://github.com/hashcat/hashcat/issue...-446869779
and of course here:
$ hashcat --help
If you understand PBKDF2, the pot file is not longer so strange as you might think.
Code:
PMK * ESSID in HEX : PSKStoring this unique result, only, will keep the pot file small.
hascat doesn't need further information to verify the NETWORK key!
Running hashcat with option -o will print what you expect to see:
Code:
PMKID or MIC : MAC_AP : MAC_STA : ESSID : PSKThe MIC is unique for a single AUTHENTICATION of a single CLIENT of the NETWORK, only.
Storing this dynamic values to a pot file will bloat it and decrease speed.
This is valid for so long until the PSK or the ESSID changed. In that case you must hunt for the new PMK (which is the result of PBKDF2).
More information is here:
https://hashcat.net/forum/thread-9893.html
and here:
https://github.com/hashcat/hashcat/issue...-446869779
and of course here:
$ hashcat --help
If you understand PBKDF2, the pot file is not longer so strange as you might think.