Need redirection, can't find the answer anymore

[mastercracker]

I have recently read a post about something similar but can't find it anymore. Sorry for the possible duplication. I am running a computer on Vista 32 bit with 2 x GTS250 cards. I have upgraded the driver to 301.42.

I decided to create a series of short attacks to test every Oclhashcat-plus attack modes (-a) with a series of different password length for each mode. I will eventually post this as a tool in the forum but basically, you take the passwords, encode them in the hash type (-m) that you want to test and run the attack (basic attack file and dic file will be included). Now the problem... I have tested this on OClhashcat-plus 0.07 and everything gets cracked perfectly. On 0.08 and 0.081, it cracks only a couple. If I run the attack again, it cracks a few more (new ones, --remove is present). I can do this a couple of times and crack some more up to a point where it does not crack anything anymore (more than half of the hashes are left to crack). This was done for plain MD5 (-m 0). What changed between 0.07 and 0.08 that can cause this?

The post that I remember was about skipping some hashes and I think that the solution was to replace some kernels but I am not sure. The kernel used in my case was 4318/m0000_a1.sm_11.32.cubin.

Thanks

[ntk]

Does status screen suddenly appear? Or do you key status screen to monitor the process?

---

I help a group to break hash recently, so I can say I have observed this strage status screen's behaviour in 0.08 many times.

My machine can run long hour until it has checked 100%. But If I am too nosy/curious and have a peep on the status screen for speed or how far left to run, system 'die' variously after 2 to 5 min max, GPU and temp gone down.

I know the response would be "Don't be nosy"

[mastercracker]

Does status screen suddenly appear? Or do you key status screen to monitor the process?

---

I help a group to break hash recently, so I can say I have observed this strage status screen's behaviour in 0.08 many times.

My machine can run long hour until it has checked 100%. But If I am too nosy/curious and have a peep on the status screen for speed or how far left to run, system 'die' variously after 2 to 5 min max, GPU and temp gone down.

I know the response would be "Don't be nosy"

No, it behaves normally beside the fact that it does not crack the password it's supposed to crack. I suspect that it's a kernel specific issue.

[mastercracker]

I think Atom that you are the only one that can solve this one. I have tried also NTLM and Joomla algos. They all have the same problem. Can you see if you can reproduce it.

[atom]

OK, I've made some tests:

root@sf:~/oclHashcat# head -100000 /root/dict/untouched/rockyou.txt | /root/hashcat-utils-1.0/len.bin 4 14 | sort -u > dict

root@sf:~/oclHashcat# perl tools/test-plus.pl passthrough 1000 < dict > hash

root@sf:~/oclHashcat# ./oclHashcat-plus64.bin -m 1000 -o found hash dict --remove --quiet

root@sf:~/oclHashcat# wc -l found hash
99829 found
0 hash
99829 total

As you can see, they all get cracked and the hashlist is empty. That means it works perfectly. So what makes the difference? Its either because of my catalyst driver, my hashlist or v0.09 fixed it accidentialy

[mastercracker]

Hey Atom. I got the answer. Luckily the problem was also with the SHA1 algorithm. I used the v.0.09 special version to test it and it was "accidentaly" fixed. However since the only mode available is 150 for SHA1, I would appreciate an access to the beta v0.09 so that I can actually do some work in the mean time and also test all the algorithms with my new tool.