Hashcat slow (solved)

[rsberzerker]

Update: Solution below

I have a large list of NTLM hashes I got from my company's IT. I'm trying to crack them mostly for fun. I'm running hashcat 6.1.1 on Win10 using a Nvidia geoforce gtx 1060 (6GB). Judging by the lack of warnings, I finally got CUDA and the latest drivers installed correctly.

If I do a benchmark (hashcat.exe -b -m 1000), I get a cracking speed of about 22 BH/s. Looks good.

But when I run it against the my list, my speed becomes 2.2 MH/s. Right now I'm running a simple mask attack (?a x6) to eliminate some of the [should be] simple and easy hashes.

I remember reading that Nvidia is deliberately reducing the efficiency of its latest card by 50% when it is used to mine the crypto-currency Ethereum. It seems to be driver based. Could this be the reason my real hash rate is so low? I do see that my GPU utilization is near 0%.

The command line I use to start it is:

%hashcat% -m %hashtype% -a 3 --remove -O -o %outfile% --outfile-format=2 --status --bitmap-max=28 --session=rsmask %hashfile% "<path to mask file>rsmask.hcmask"

I did bump up the bitmap-max because when I used a lower value, hashcat warned me about running out of bitmap space and increasing it would help, so I did some trial and error and this is the lowest value that didn't give me that warning. But increasing it didn't seem to help, other than getting rid of the warning.

What can I do to get a better rate?

Solution: I found that by adding a limit to --markov-threshold (-t 5), my hashrate for the above jumped to ~650MH/s, a huge improvement. My GPU utilization rate also climbed. If you plan to let the mask go to exhaustion, your hashrate will be even faster if you add --markov-disable . Mine almost doubled to about 1.2BH/s with this.

[Snoopy]

I have a large list of NTLM hashes I got from my company's IT. I'm trying to crack them mostly for fun. I'm running hashcat 6.1.1 on Win10 using a Nvidia geoforce gtx 1060 (6GB). Judging by the lack of warnings, I finally got CUDA and the latest drivers installed correctly.

If I do a benchmark (hashcat.exe -b -m 1000), I get a cracking speed of about 22 BH/s. Looks good.

But when I run it against the my list, my speed becomes 2.2 MH/s. Right now I'm running a simple mask attack (?a x6) to eliminate some of the [should be] simple and easy hashes.

I remember reading that Nvidia is deliberately reducing the efficiency of its latest card by 50% when it is used to mine the crypto-currency Ethereum. It seems to be driver based. Could this be the reason my real hash rate is so low? I do see that my GPU utilization is near 0%.

The command line I use to start it is:

%hashcat% -m %hashtype% -a 3 --remove -O -o %outfile% --outfile-format=2 --status --bitmap-max=28 --session=rsmask %hashfile% "<path to mask file>rsmask.hcmask"

I did bump up the bitmap-max because when I used a lower value, hashcat warned me about running out of bitmap space and increasing it would help, so I did some trial and error and this is the lowest value that didn't give me that warning. But increasing it didn't seem to help, other than getting rid of the warning.

What can I do to get a better rate?

the used mask is yet to small to use the power of your card, you can easily check this if you make a fast check with ?a *10 or so) and you should see that your hashrate rises

[rsberzerker]

the used mask is yet to small to use the power of your card, you can easily check this if you make a fast check with ?a *10 or so) and you should see that your hashrate rises

I tried that and got an "Integer overflow detected in keyspace of mask". I changed it to ?a x8 ?d x2 and the hashrate did jump, but only to about 1.2 BH/s and hashcat reported gpu utilization at 99%. That rate is way short of the 22 BH/s I got with the benchmark but still an improvement. Interestingly, both Task Manager and Process Explorer both showed the GPU usage near 0. Not sure why they didn't detect the obvious usage that was happening.

I also noticed hashcat seemed more responsive. When doing the 6x ?a mask, if I press S, either nothing happens or I get the exact same report as before (eventually it does update on it's own), but with the 10 character mask, S responses right away with a real update.


Kind of sucks that a smaller keyspace can take as long to search as a larger keyspace. Could the size of my hashlist be slowing it down? It is big - about 10 M lines. (My thought was to eliminate the short, don't care about hashes, then I can attack the more interesting ones easier.)

[Snoopy]

Yeah did a fast try with ?a and 9 positions working 10 resulting in integer overflow so bruteforcing ?a till 9 will work or you have to change the mask to something like

-1 ?u?l?d -2 ?l?d NTLM.txt ?1?2?2?2?2?2?2?2?2?2?2?a

there is maybe a workaround with princeprocessor / maskprocessor to pass this behavior

fast check with maskprocessor
22* ?a
mp64.exe --combinations ?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a
works like a charm, so use mp as input (dont know how fast this would be

[philsmd]

btw: -w 3 is also important here and the fact that the benchmark uses the single hash (1 hash only) optimizations while your hash lists contains a lot of hashes (test it yourself by using the same command and a new/modified hash list with only one hash).

[rsberzerker]

btw: -w 3 is also important here and the fact that the benchmark uses the single hash (1 hash only) optimizations while your hash lists contains a lot of hashes (test it yourself by using the same command and a new/modified hash list with only one hash).

I have tried the -w 3 and didn't see any real change. I think you are correct that a large hashlist is a bit slower than just 1 hash.