SHA1 speed difference
#1
Hi all,

I have the following issue.

Trying this on GeForce GTX 1080 whit CUDA API (CUDA 11.2). Hashcat is v6.2.3.
Code:
hashcat.exe -m 100 -w 3 -O -a 3 b89eaac7e61417341b710b727768294d0e6a277b

I get speed of 8408.5 MH/s. Which looks OK.
Code:
b89eaac7e61417341b710b727768294d0e6a277b:hashcat

Session..........: hashcat
Status...........: Cracked
Hash.Name........: SHA1
Hash.Target......: b89eaac7e61417341b710b727768294d0e6a277b
Time.Started.....: Sat Aug 14 19:30:54 2021 (2 secs)
Time.Estimated...: Sat Aug 14 19:30:56 2021 (0 secs)
Kernel.Feature...: Optimized Kernel
Guess.Mask.......: ?1?2?2?2?2?2?2 [7]
Guess.Charset....: -1 ?l?d?u, -2 ?l?d, -3 ?l?d*!$@_, -4 Undefined
Guess.Queue......: 7/15 (46.67%)
Speed.#1.........:  8408.5 MH/s (77.38ms) @ Accel:64 Loops:512 Thr:1024 Vec:1
Recovered........: 1/1 (100.00%) Digests
Progress.........: 12079595520/134960504832 (8.95%)
Rejected.........: 0/12079595520 (0.00%)
Restore.Point....: 0/1679616 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:8704-9216 Iteration:0-512
Candidate.Engine.: Device Generator
Candidates.#1....: v77eran -> Lurzto8
Hardware.Mon.#1..: Temp: 62c Fan:  0% Util: 99% Core:1759MHz Mem:4513MHz Bus:16

Applying a mask like this
Code:
hashcat.exe -m 100 -w 3 -O -a 3 b89eaac7e61417341b710b727768294d0e6a277b --hex-charset ?b?b?b?b?b?b
I still get the same speed
Code:
Speed.#1.........:  8550.0 MH/s (77.38ms) @ Accel:32 Loops:1024 Thr:1024 Vec:1

Prepending up to two fixed bytes to the mask the speed remains
Code:
hashcat.exe -m 100 -w 3 -O -a 3 b89eaac7e61417341b710b727768294d0e6a277b --hex-charset 0102?b?b?b?b?b?b
Speed.#1.........:  8635.6 MH/s (76.57ms) @ Accel:32 Loops:1024 Thr:1024 Vec:1


Prepending 3 fixed bytes to the mask the spped drops to 5000 MH7s,. Which is also fine.
Code:
hashcat.exe -m 100 -w 3 -O -a 3 b89eaac7e61417341b710b727768294d0e6a277b --hex-charset 010203?b?b?b?b?b?b
Speed.#1.........:  5028.6 MH/s (37.89ms) @ Accel:64 Loops:256 Thr:1024 Vec:1


Now the problem. Prepending 4 or more fixed bytes the speed drops to 50 MH/s.
Code:
hashcat.exe -m 100 -w 3 -O -a 3 b89eaac7e61417341b710b727768294d0e6a277b --hex-charset 01020304?b?b?b?b?b?b
Speed.#1.........: 45324.1 kH/s (0.66ms) @ Accel:64 Loops:1 Thr:1024 Vec:1


Funny. If the fixed bytes are in the middle or at the end like this. The speed ramps up again to 5 to 8 GH/s
Code:
hashcat.exe -m 100 -w 3 -O -a 3 b89eaac7e61417341b710b727768294d0e6a277b --hex-charset ?b01020304?b?b?b?b?b
Speed.#1.........:  5067.4 MH/s (37.64ms) @ Accel:64 Loops:256 Thr:1024 Vec:1

hashcat.exe -m 100 -w 3 -O -a 3 b89eaac7e61417341b710b727768294d0e6a277b --hex-charset ?b?b?b?b?b?b01020304
Speed.#1.........:  8569.8 MH/s (77.08ms) @ Accel:32 Loops:1024 Thr:1024 Vec:1

The question. What am I doing wrong?
Thanks for your help.

Regards
rste
Reply
#2
Nothing, that's exactly the expected behavior. The first 4 byte are used as amplifiers. If you really need to brute force the first 4 byte you can use hybrid rules in -a 0 mode for almost full speed.
Reply
#3
(08-14-2021, 07:10 PM)atom Wrote: Nothing, that's exactly the expected behavior. The first 4 byte are used as amplifiers. If you really need to brute force the first 4 byte you can use hybrid rules in -a 0 mode for almost full speed.

Thank you. 
I couldn't make it with rules in -a 0, because I found no way to append in byte mode when used with --hex-charset.

What worked was generating a dictionary 
Code:
$PSDefaultParameterValues['Out-File:Encoding'] = 'utf8'
0..255 | % {
  $L1 = [System.Convert]::ToString($_,16).PadLeft(2,'0')
  0..255 | % {
    $L2 = [System.Convert]::ToString($_,16).PadLeft(2,'0')
    echo ('000102030405060708090A0B0C0D0E0F'+$L1+$L2) >> prependmask.txt
 }
}

and using -a 6
Code:
.\hashcat.exe -m 100 -w 3 -O -a 6 b89eaac7e61417341b710b727768294d0e6a277b --hex-charset  prependmask.txt  ?b?b?b

The only problem is in -a 6 mode I get "Integer overflow detected in keyspace of mask" with only 4 ?b regardless of the dictionary size. In -a 3 mode overflow happens with 8 ?b. So to test for 6 bytes I have to add another loop to the dictionary generation.
Reply