Slow/no status response in Windows 10
#1
I have an issue on Win 10 where I have a wordlist that I am running against a hash file. Wordlist contains about 160,000,000 entries and the hash file contains about 140,000,000 entries. I am running 2 x 1080's and the option to show a status doesn't respond (though I think it might after it has exhausted it's current set). The Cracked.txt file continues to grow in size, so it is cracking the hashes. On my laptop that has a 980 (linux) I run the same files and commands and it will respond quickly. I was hoping someone could shed some light on this issue (guessing it's something I'm doing or have misconfigured). I do not have the cards in SLI nor is the bridge connected.  

Additionally, when I do get a status it's only running at 9500 kH/s per card for the 1080's. The 980 in the laptop is doing ~820 MH/s. The benchmark on windows shows 52000 MH/s so something isn't working right.

Version is 3.5

hashcat64.exe --status -a 0 -m 0 -o Cracked.txt g:\Downloads\hashes\raw-md5.hashes.txt massiveSortedWordlist.txt

p.s. Kudos to the Hashcat team for a holy excellent piece of software.
#2
Well, that's a comparison of 2 completely different (operating) systems. I'm not sure if that is a good comparison. Furthermore, the 2 system also have different hardware (so everything changes). A better comparison would be either: different hardware, but same operating system OR the same hardware, but different operating system (not changing everything and then compare apples and oranges).

I also do not understand why you use --status (normally you would not use it, except for pipes - where it is enabled by default - or if you use hashcat together with some wrappers etc).

What is very important here is the question if you are using any particular shell/terminal emulator. Do you use mingw/cygwin/powershell etc ? If so, please test with cmd.exe

Also you might need to read the output of hashcat carefully (eventually there are some warnings like the one about the timeout patch etc https://hashcat.net/wiki/timeout_patch )
#3
I understand it's 2 different OS. The purpose is to troubleshoot. Again, I used --status to troubleshoot, to see if there was any difference.

No emulator. I'll try the reg patch.

Thanks for the quick response!

(06-02-2017, 08:09 AM)philsmd Wrote: Well, that's a comparison of 2 completely different (operating) systems. I'm not sure if that is a good comparison. Furthermore, the 2 system also have different hardware (so everything changes). A better comparison would be either: different hardware, but same operating system OR the same hardware, but different operating system (not changing everything and then compare apples and oranges).

I also do not understand why you use --status (normally you would not use it, except for pipes - where it is enabled by default - or if you use hashcat together with some wrappers etc).

What is very important here is the question if you are using any particular shell/terminal emulator. Do you use mingw/cygwin/powershell etc ? If so, please test with cmd.exe

Also you might need to read the output of hashcat carefully (eventually there are some warnings like the one about the timeout patch etc https://hashcat.net/wiki/timeout_patch )
#4
Tested with the patch, no change. It still seems that the status won't update until it has exhausted the current set.
#5
Wait, how did you test this that quickly? (you had to reboot your system and wait until the whole dictionary exhausted, shouldn't that take at least several minutes/hours?)

How much time does it take to exhaust ? Are we speaking about several hours or just some seconds?

If hashcat doesn't react to key presses in its initialization phase, that is perfectly normal. On the other hand, it should react whenever you press a key after you see this line "[s]tatus [p]ause [r]esume [b]ypass [c]heckpoint [q]uit". Do you see this prompt?

It might also make sense to test with a different set of input, e.g. a command like this (MD5 hash type):
Code:
hashcat -a 3 00000000000000000000000000000000 ?a?a?a?a?a?a?a?a
#6
If it doesn't respond to a status check immediately then it's obvious. I may not have communicated the issue clearly.


When I press "s" for a status update it doesn't respond until (maybe?) the set is exhausted. So, when I start a crack running and I press "s" and nothing happens then it's obvious that it is still not fixed.

A restart only takes 30 sec. and I'm not going to wait for the set to exhaust. The last set took 1.5 hrs. and I don't need to wait that long. 

I just uninstalled CUDA (forgot it was installed) and I can get a status update 2x before hashcat stops responding. This is slightly different behavior than before in that I can get 2 status updates before it stops responding. It is still cracking at a very degraded level.
#7
Oh that might explain it (you shouldn't install CUDA at all for using hashcat, it might ship with conflicting .dll/drivers).

You should try to follow this: https://hashcat.net/faq#i_may_have_the_w...hould_i_do
#8
Yes, I know. It's been installed for a while and I had forgotten.
#9
So I tested "hashcat32.exe -a 3 00000000000000000000000000000000 ?a?a?a?a?a?a?a?a" and it works fine. I'm wondering if the hash or dictionary files are too big? It was cracking that config you provided at around 50000 MH/s.
#10
Ok, it's working now.

So, after having removed CUDA AND added in a hcmask file it's working. When I don't have the hcmask file the status hangs/doesn't respond. I had tried to set the workload to 4 and nothing changed. It's looking good now. Could it be because the cards are too fast that there isn't enough of a workload when in "straight" mode?

hashcat64.exe --status -a 6 -m 0 -w 4 -o Cracked.txt g:\Downloads\hashes\raw-md5.hashes.txt massiveSortedWordlist.txt masks\dict.hcmask

(I had tried this config prior to removing CUDA and the problem occurred).