hashcat Forum

I have seen many articles state that while the new method lets you start cracking Wifi password without waiting for a handshake the cracking process itself is not faster, however according to this benchmark: https://gist.github.com/iam1980/808f696a...01f91a8b18

Hashcat can crack WPA/WPA2 PMK ~500 times faster than WPA/WPA2 (3200MH/s vs 6300KH/s)

Am I missing something or is -m 2501 that much faster?

You are confusing PMK and PMKID. The hash mode for the PMKID attack is 16800.

(01-06-2020, 12:45 PM)undeath Wrote: [ -> ]You are confusing PMK and PMKID. The hash mode for the PMKID attack is 16800.

Oh...

What is 2501 used for then?

It's used to attack a WPA handshake using pre-calculated PMK for a specific SSID.

(01-06-2020, 01:14 PM)undeath Wrote: [ -> ]It's used to attack a WPA handshake using pre-calculated PMK for a specific SSID.

Is that the most popular method of cracking handshakes nowaday since it's so much faster?

You can't compare 2500 to 2501 and 16800 to 16801.
2500 and 16800 are hash modes to get a PSK, while 2501 and 16801 hash modes are used to verify a given(!) PMK.

BTW:
Both modes 250x and 1680x are deprecated, soon. Successor is hash mode 2200x

$ hashcat -V
v5.1.0-1547-g8e0f976c

$ hashcat --help
22000 | WPA-PBKDF2-PMKID+EAPOL | Network Protocols
22001 | WPA-PMK-PMKID+EAPOL | Network Protocols

Advantages:
- easy to handle
- hash file is HEX ASCII (no longer binary)
- full reuse of PBKDF2 over PMKID and EAPOL (speed improvement)
- and more...

(01-06-2020, 02:34 PM)ZerBea Wrote: [ -> ]You can't compare 2500 to 2501 and 16800 to 16801.
2500 and 16800 are hash modes to get a PSK, while 2501 and 16801 hash modes are used to verify a given(!) PMK.

BTW:
Both modes 250x and 1680x are deprecated, soon. Successor is hash mode 2200x

$ hashcat -V
v5.1.0-1547-g8e0f976c

$ hashcat --help
  22000 | WPA-PBKDF2-PMKID+EAPOL                          | Network Protocols
  22001 | WPA-PMK-PMKID+EAPOL                              | Network Protocols

Advantages:
- easy to handle
- hash file is HEX ASCII (no longer binary)
- full reuse of PBKDF2 over PMKID and EAPOL (speed improvement)
- and more...

Nice, and it's even nicer that mode 22000 still receives the old binary .hccapx format.

But I found that if I'm using a 4800000-lines dictionary and a 1000-lines rule, mode 22000 is 20% slower than mode 2500, using GTX1080, CUDA 10.2 API on Linux, compiled by myself using Arch User Repository. The version number is v5.1.0-1755-gddb641b8+

Speed depend on count of hashes inside the hash file and/or nonce-error-correction value. How have you measured the 20%?

I can't reproduce such a big difference running an example hash from here:
https://hashcat.net/misc/example_hashes/hashcat.hccapx

one EAPOL hccapx:
real 0m9,860s
user 0m3,913s
sys 0m4,207s

versus

one EAPOL 22000 (the same as in the hccapx file)
real 0m9,389s
user 0m3,939s
sys 0m3,686s

As expected, the measured values are nearly the same

envirnonment:
$ uname -r
5.5.10-arch1-1

$ pacman -Q | grep nvidia
nvidia 440.64-5
nvidia-settings 440.64-1
nvidia-utils 440.64-2
opencl-nvidia 440.64-2

$ pacman -Q | grep cuda
cuda 10.2.89-3

in detail (disabled automatic nonce error corrections, to make sure we have the same conditions):


versus


Please post your complete comparison,
$ time hashcat -m 2500 + your options
versus
$ time hashcat -m 22000 + your options
to find out what is going wrong.

Please read also this post:
https://hashcat.net/forum/thread-9055-po...l#pid48000

(03-23-2020, 09:36 AM)ZerBea Wrote: [ -> ]Please post your complete comparison,
$ time hashcat -m 2500 + your options
versus
$ time hashcat -m 22000 + your options
to find out what is going wrong.

Please read also this post:
https://hashcat.net/forum/thread-9055-po...l#pid48000
Speed depend on count of hashes inside the hash file and/or nonce-error-correction value.

Thanks for the attention. Further testing shows that the performance decrease only happens with one of my .hccapx files and certain cracking method (4800000x words and 1000x rules), and the decrease disappears when --nonce-error-correction=0 is set.

-m 2500 1020.2 kH/s:

-m 22000 847.6 kH/s:

The performance difference disappeared when using a dictionary without rules:
-m 22000 993.4 kH/s

The difference also disappears when set --nonce-error-corrections=0
-m 22000 1037.0 kH/s

Great, thanks for posting your result. Some words about nonce error corrections (NC):
NC values have a deep impact on hashcat speed. Within hccapx and 22000 hash records the message pair field is used, to tell hashcat what to do (NC on big endian, NC on little endian, NC on both). That will drop speed. Mostly, you need NC only if you captured traffic, running a passive dumper (tshark, Wireshark, kismet, airodump-ng) to compensate a possible packet loss. Also it is important to know that NC is not possible on all types of EAPOL messages. To detect that NC is possible, we need at least 2 different ANONCEs from 2 different authentication sequences of the same ACCESS POINT.
On active attacks (M1M2ROGUE), NC can be disabled (=0). Here we have no packet loss, because a missing EAPOL message is requested immediately by the attack tool.
Also there are speed differences between mask, wordlist, wordlist +rule tasks within the same hash mode. But running wordlist +rule by hash mode 2500 should be the same as running wordlist +rule by hash mode 22000.

You shouldn't compare average speed values between
Status...........: Quit
and
Status...........: Exhausted
because that falsifies the result. In that case you can't rely on the average speed value (e.g. 1037.0 kH/s), only. It is much more precise and accurate to use Linux time function over the whole task (up to Exhausted).

example:

Status...........: Quit

versus

Status...........: Exhausted

big difference in average speed:
Speed.#1.........: 554.3 kH/s
versus
Speed.#1.........: 529.4 kH/s