Just in case Atom missed it, the problem is existant. From what I noticed, it seems to crack a password but sometime then assign it to the wrong hash. For all the wrong Hashassword pair, the password is present elsewhere with the correct hash. Sometimes the "wrong hash" is also there with it's correct password. Since I was using the --remove, it means that it is an output problem since the "wrong" hash was still available for cracking after. Again, I will repeat the conditions, large amount of hashes > 3 millions, multiple rules and multi-GPU. I don't know if anyone can replicate the behavior (does anyone else double-check the hash:pass that OCLhashcat spits out?).

that was a good hint mastercracker. i found somthing. it is exactly as i said in the beginning. it is salted with a null-byte. or better said its the unicode version of something. take the first example:

so what we can call a bug is that the hex-output does not indicate a null-byte. however it just looks like wrong hash:password pair but it is not. it is because a null-byte is "invisible".

i guess the reason behind is a way how i optimize the rule processing on gpu. it can happend that some values are generated additionally. some that you do not instruct with the rule configurations. however it also generates all you have programmed so this is usually not a problem. sometimes its better to check some "garbage" data instead of skipping it because the skipping if () would take more time than checking the garbage. this is what happend here but accidentially the garbage was a real plain so it found it.

(02-26-2011, 09:36 AM)atom Wrote: that was a good hint mastercracker. i found somthing. it is exactly as i said in the beginning. it is salted with a null-byte. or better said its the unicode version of something. take the first example:

so what we can call a bug is that the hex-output does not indicate a null-byte. however it just looks like wrong hash:password pair but it is not. it is because a null-byte is "invisible".

i guess the reason behind is a way how i optimize the rule processing on gpu. it can happend that some values are generated additionally. some that you do not instruct with the rule configurations. however it also generates all you have programmed so this is usually not a problem. sometimes its better to check some "garbage" data instead of skipping it because the skipping if () would take more time than checking the garbage. this is what happend here but accidentially the garbage was a real plain so it found it.

Good to see that there nothing wrong with it. Personally, I don't mind having those extra ones cracked as a bonus.