Please note, this is a STATIC archive of website hashcat.net from October 2020, cach3.com does not collect or store any user information, there is no "phishing" involved.

hashcat Forum

Full Version: cracking way too fast?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I'm cracking some WPA/WPA2 handshakes, and the results I'm seeing seem to be way too fast by orders of magnitude.  I'm expecting to crack WPA at between 400-500kH/s on this hardware (dual GTX 1060), and on some workloads I'm seeing 300-350MH/s instead.  This is a good problem to have, but I'm concerned the results are invalid.  Any ideas?



Code:
pdo@seven:~$ hashcat -m 2500 -w 4 Tenda.hccapx wordlists/crackstation-human-WPA.txt
hashcat (v3.40) starting...

* Device #1: WARNING! Kernel exec timeout is not disabled, it might cause you errors of code CL_OUT_OF_RESOURCES
             See the wiki on how to disable it: https://hashcat.net/wiki/doku.php?id=timeout_patch
OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: GeForce GTX 1060 3GB, 752/3008 MB allocatable, 9MCU
* Device #2: GeForce GTX 1060 3GB, 753/3013 MB allocatable, 9MCU

Hashes: 264 digests; 264 unique digests, 264 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1

Applicable Optimizers:
* Zero-Byte
* Slow-Hash-SIMD

Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger disabled

Cache-hit dictionary stats wordlists/crackstation-human-WPA.txt: 591844916 bytes, 46663304 words, 46663304 keyspace

[results redacted]

Session..........: hashcat
Status...........: Exhausted
Hash.Type........: WPA/WPA2
Hash.Target......: Tenda.hccapx
Time.Started.....: Sun Mar 26 12:10:05 2017 (2 mins, 31 secs)
Time.Estimated...: Sun Mar 26 12:12:36 2017 (0 secs)
Input.Base.......: File (wordlists/crackstation-human-WPA.txt)
Input.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....:   177.0 MH/s (374.72ms)
Speed.Dev.#2.....:   175.2 MH/s (374.21ms)
Speed.Dev.#*.....:   352.1 MH/s
Recovered........: 45/264 (17.05%) Digests, 45/264 (17.05%) Salts
Progress.........: 12319112256/12319112256 (100.00%)
Rejected.........: 0/12319112256 (0.00%)
Restore.Point....: 46006272/46663304 (98.59%)
Candidates.#1....: YOSIHUSA -> ZAINABLOVE
Candidates.#2....: ZAINABMA -> שמא110506
HWMon.Dev.#1.....: Temp: 71c Fan: 54% Util:  0% Core:1898MHz Mem:3802MHz Lanes:16
HWMon.Dev.#2.....: Temp: 66c Fan: 49% Util: 90% Core:1885MHz Mem:3802MHz Lanes:4

Started: Sun Mar 26 12:09:58 2017
Stopped: Sun Mar 26 12:12:36 2017
If you use the release version from https://hashcat.net/ you just need to know that this is a known issue and was already fixed: https://github.com/hashcat/hashcat/issues/1178

You can use https://hashcat.net/beta/ to double-check that this display error is fixed (otherwise you need to wait for the next release version).

No, there shouldn't be any invalid results. As said, for the user it should only be a cosmetic difference.
This question was already answered a couple of times, lately.
(03-26-2017, 06:32 PM)philsmd Wrote: [ -> ]If you use the release version from https://hashcat.net/ you just need to know that this is a known issue and was already fixed: https://github.com/hashcat/hashcat/issues/1178

You can use https://hashcat.net/beta/ to double-check that this display error is fixed (otherwise you need to wait for the next release version).

No, there shouldn't be any invalid results. As said, for the user it should only be a cosmetic difference.
This question was already answered a couple of times, lately.

Thanks for the response, sorry for the noise.