Discrepancy between Benchmark numbers and actual numbers
#11
Ok, I've been putting in a lot of time to dink with this since my last reply and I have to admit I have no idea why this is getting such slow speeds with commands that ought to be working.

hashcat64.exe d:\wordlists\000webhost.txt -r rules\best64.rule --stdout | hashcat64.exe -m0 d:\hashlists\Random\Quillen.txt -O --status

Quote:Session..........: hashcat
Status...........: Running
Hash.Type........: MD5
Hash.Target......: (redacted)
Time.Started.....: Thu Aug 29 21:17:16 2019 (30 secs)
Time.Estimated...: Thu Aug 29 21:17:46 2019 (0 secs)
Guess.Base.......: Pipe
Speed.#1.........:  126.1 kH/s (0.19ms) @ Accel:64 Loops:1 Thr:256 Vec:1
Speed.#2.........:  172.1 kH/s (2.05ms) @ Accel:128 Loops:1 Thr:256 Vec:1
Speed.#3.........:  164.3 kH/s (0.50ms) @ Accel:256 Loops:1 Thr:256 Vec:1
Speed.#4.........:  120.7 kH/s (0.31ms) @ Accel:128 Loops:1 Thr:256 Vec:1
Speed.#*.........:  583.2 kH/s
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 12586004
Rejected.........: 3092
Restore.Point....: 0
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Restore.Sub.#2...: Salt:0 Amplifier:0-1 Iteration:0-1
Restore.Sub.#3...: Salt:0 Amplifier:0-1 Iteration:0-1
Restore.Sub.#4...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidates.#1....: tufi -> liamsufc124
Candidates.#2....: hafez801237 -> il.cil.c
Candidates.#3....: cerberos849 -> vtnfkk0bcrfntkm
Candidates.#4....: liamsufc125 -> cerberos848
Hardware.Mon.#1..: Temp: 31c Fan: 36% Util:  0% Core:1515MHz Mem:6800MHz Bus:1
Hardware.Mon.#2..: Temp: 27c Fan: 40% Util:  0% Core:1480MHz Mem:5005MHz Bus:1
Hardware.Mon.#3..: Temp: 29c Fan: 40% Util: 29% Core:1632MHz Mem:3802MHz Bus:1
Hardware.Mon.#4..: Temp: 30c Fan:100% Util:  0% Core:1189MHz Mem:3304MHz Bus:1


The example command from the FAQ for an amplified attack is -
./hashcat64.bin --stdout wordlist.txt -r rules/best64.rule | ./hashcat64.bin -m 2500 test.hccapx

But with MD5 hashes you can see the speed above is... really slow. Feeding the command larger dictionaries or more rules has no significant impact. Ideas?
Reply
#12
Piping in words means every single word needs to be copied from your CPU to the GPU. That's slow! You can get away without speed penalties when using slow hash modes, but for fast hash modes that's bad.

Piping in a straight wordlist attack on a fast hash mode is not useful in general.
Reply
#13
Well shoot.

Ok, then for fast hashes, what's the best way to get full acceleration for rule based attacks? I was playing with the hctune file for a few hours but didn't get any progress.
Reply
#14
well, I would just try to compare it with the benchmark value.

if you test the same input (single hash, -w 3 or even -w 4 and -O and mask ?b?b?b?b?b?b?b), the speed should be the same.

if by changing the mask from ?b?b?b?b?b?b?b to your mask with ?1s the speed drops, it's for sure a too small keyspace.

we need to first confirm this
Reply
#15
And as a side note, I do appreciate all the help/pointers in the thread. I know how aggravating it can be and I'm trying other things. I think my biggest issue is the "how" hashcat works on the back end (doing a ton of googling and reading) is what's keeping me from figuring it out on my own.

But thank you. I'm confused as to how piping a wordlist through rules as an amplifier will slow it down when the FAQ says that should speed it up. I'll keep at it.

Quote:well, I would just try to compare it with the benchmark value.

if you test the same input (single hash, -w 3 or even -w 4 and -O and mask ?b?b?b?b?b?b?b), the speed should be the same.

if by changing the mask from ?b?b?b?b?b?b?b to your mask with ?1s the speed drops, it's for sure a too small keyspace.

we need to first confirm this

My bad, didn't refresh before posting. I'll get this in a few minutes and post results.
Reply
#16
hashcat64.exe -m0 -a3 d:\hashlists\Random\Quillen.txt ?b?b?b?b?b?b?b -w4 -O

Quote:hashcat (v5.1.0) starting...

* Device #1: WARNING! Kernel exec timeout is not disabled.
            This may cause "CL_OUT_OF_RESOURCES" or related errors.
            To disable the timeout, see: https://hashcat.net/q/timeoutpatch
* Device #2: WARNING! Kernel exec timeout is not disabled.
            This may cause "CL_OUT_OF_RESOURCES" or related errors.
            To disable the timeout, see: https://hashcat.net/q/timeoutpatch
* Device #3: WARNING! Kernel exec timeout is not disabled.
            This may cause "CL_OUT_OF_RESOURCES" or related errors.
            To disable the timeout, see: https://hashcat.net/q/timeoutpatch
* Device #4: WARNING! Kernel exec timeout is not disabled.
            This may cause "CL_OUT_OF_RESOURCES" or related errors.
            To disable the timeout, see: https://hashcat.net/q/timeoutpatch
* Device #5: Intel's OpenCL runtime (GPU only) is currently broken.
            We are waiting for updated OpenCL drivers from Intel.
            You can use --force to override, but do not report related errors.
OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: GeForce RTX 2080, 2048/8192 MB allocatable, 46MCU
* Device #2: GeForce GTX 1080 Ti, 2816/11264 MB allocatable, 28MCU
* Device #3: GeForce GTX 1070, 2048/8192 MB allocatable, 15MCU
* Device #4: GeForce GTX 980 Ti, 1536/6144 MB allocatable, 22MCU

OpenCL Platform #2: Intel(R) Corporation
========================================
* Device #5: Intel(R) HD Graphics 4600, skipped.
* Device #6: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz, skipped.

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

Applicable optimizers:
* Optimized-Kernel
* Zero-Byte
* Precompute-Init
* Precompute-Merkle-Demgard
* Meet-In-The-Middle
* Early-Skip
* Not-Salted
* Not-Iterated
* Single-Hash
* Single-Salt
* Brute-Force
* Raw-Hash

Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 55

Watchdog: Temperature abort trigger set to 90c

[s]tatus [p]ause [b]ypass [c]heckpoint [q]uit =>

Session..........: hashcat
Status...........: Running
Hash.Type........: MD5
Hash.Target......: (redacted)
Time.Started.....: Fri Aug 30 12:52:59 2019 (2 secs)
Time.Estimated...: Tue Sep 10 09:54:00 2019 (10 days, 21 hours)
Guess.Mask.......: ?b?b?b?b?b?b?b [7]
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 24835.8 MH/s (17.96ms) @ Accel:64 Loops:1024 Thr:256 Vec:4
Speed.#2.........: 20023.2 MH/s (34.71ms) @ Accel:128 Loops:1024 Thr:256 Vec:4
Speed.#3.........: 16091.3 MH/s (50.37ms) @ Accel:256 Loops:1024 Thr:256 Vec:4
Speed.#4.........: 15734.6 MH/s (38.61ms) @ Accel:128 Loops:1024 Thr:256 Vec:4
Speed.#*.........: 76685.5 MH/s
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 177335173120/72057594037927936 (0.00%)
Rejected.........: 0/177335173120 (0.00%)
Restore.Point....: 0/4294967296 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:75776-76800 Iteration:0-1024
Restore.Sub.#2...: Salt:0 Amplifier:50176-51200 Iteration:0-1024
Restore.Sub.#3...: Salt:0 Amplifier:37888-38912 Iteration:0-1024
Restore.Sub.#4...: Salt:0 Amplifier:50176-51200 Iteration:0-1024
Candidates.#1....: $HEX[735f616572616e] -> $HEX[ff2b31ff7f0b00]
Candidates.#2....: $HEX[73010065800b00] -> $HEX[ffc700ff7f1900]
Candidates.#3....: $HEX[7394e365801900] -> $HEX[ff978fff7f284c]
Candidates.#4....: $HEX[7301006580284c] -> $HEX[ffc700ff7f3331]
Hardware.Mon.#1..: Temp: 33c Fan: 44% Util: 57% Core:2040MHz Mem:6800MHz Bus:1
Hardware.Mon.#2..: Temp: 25c Fan: 40% Util: 77% Core:1392MHz Mem:5005MHz Bus:1
Hardware.Mon.#3..: Temp: 37c Fan: 48% Util: 77% Core:2037MHz Mem:3802MHz Bus:1
Hardware.Mon.#4..: Temp: 38c Fan: 71% Util: 84% Core:1379MHz Mem:3304MHz Bus:1
Reply
#17
well , this is now -m 0, not -m 1000. we should compare apples to apples, not apples to oranges.

You didn't post the --benchmark value vs the real test with hash list for the same hash types.
we would need both values for a specific hash type. otherwise it's just getting more confusing
Reply
#18
*smacks forehead*

I apologize, I thought I had already posted that.

Quote:D:\hashcat>hashcat64.exe -b -m0
hashcat (v5.1.0) starting in benchmark mode...

Benchmarking uses hand-optimized kernel code by default.
You can use it in your cracking session by setting the -O option.
Note: Using optimized kernel code limits the maximum supported password length.
To disable the optimized kernel code in benchmark mode, use the -w option.

* Device #5: Intel's OpenCL runtime (GPU only) is currently broken.
            We are waiting for updated OpenCL drivers from Intel.
            You can use --force to override, but do not report related errors.
nvmlDeviceGetFanSpeed(): Unknown Error

OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: GeForce RTX 2080, 2048/8192 MB allocatable, 46MCU
* Device #2: GeForce GTX 1080 Ti, 2816/11264 MB allocatable, 28MCU
* Device #3: GeForce GTX 1070, 2048/8192 MB allocatable, 15MCU
* Device #4: GeForce GTX 980 Ti, 1536/6144 MB allocatable, 22MCU

OpenCL Platform #2: Intel(R) Corporation
========================================
* Device #5: Intel(R) HD Graphics 4600, skipped.
* Device #6: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz, skipped.

Benchmark relevant options:
===========================
* --optimized-kernel-enable

Hashmode: 0 - MD5

Speed.#1.........: 41232.7 MH/s (18.14ms) @ Accel:64 Loops:1024 Thr:256 Vec:4
Speed.#2.........: 22853.2 MH/s (40.54ms) @ Accel:128 Loops:1024 Thr:256 Vec:4
Speed.#3.........: 19592.4 MH/s (50.68ms) @ Accel:256 Loops:1024 Thr:256 Vec:4
Speed.#4.........: 18825.9 MH/s (38.65ms) @ Accel:128 Loops:1024 Thr:256 Vec:4
Speed.#*.........:  102.5 GH/s

Started: Fri Aug 30 13:31:18 2019
Stopped: Fri Aug 30 13:31:34 2019
Reply
#19
I'd guess the mask is still too short and doesn't provide enough work. Numbers are pretty close to the benchmark on all cards but the fastest, the 2080.
Reply
#20
Yeah not sure what that's about. I was playing with the hctune file and couldn't get them to do anything but crater, but since I'm not exactly an expert in tweaking hashcat, that's hardly a surprise.
Reply