Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Possible OCLhashcat+ bug
02-11-2011, 05:28 PM
Post: #1
Possible OCLhashcat+ bug
Hi. I ran the following attack on about 2 million hashes:

cudahashcat+32.exe -d 1,2 -m 0 -o found2.txt -r "C:\rules\basic.txt" test.hash "F:\Dictionaries\Dict\All.txt"

Rules:
Code:
:
r
d
f
p3
p4

I get good hash:password pairs but also got those that seems to be erroneous:

93b885adfe0da089cdf634904fd59f71:
25daad3d9e60b45043a70c4ab7d3b1c6:
fead052eeedcfb31c49b19f91edded24:1
cb824d9f595e14ba63698fa5fe07002a:x
c5940e567348894860e9e45434682f5f:2
86ce15a7f39fc14323b76c9b95c66165:1
Find all posts by this user
02-11-2011, 05:50 PM
Post: #2
RE: Possible OCLhashcat+ bug
sometimes passwords gets salted with a trailing null byte. or newline or other crazy things. run it in --output-format=2 mode and verify results
Visit this user's website Find all posts by this user
02-15-2011, 03:58 PM
Post: #3
RE: Possible OCLhashcat+ bug
any news here?
Visit this user's website Find all posts by this user
02-16-2011, 03:28 AM
Post: #4
RE: Possible OCLhashcat+ bug
(02-15-2011 03:58 PM)atom Wrote:  any news here?
I assumed that you were correct and did not do anything further but just to make sure that we are not missing something out, I will do it tomorrow once my current attack finish.
Find all posts by this user
02-16-2011, 10:17 AM
Post: #5
RE: Possible OCLhashcat+ bug
thanks Smile
Visit this user's website Find all posts by this user
02-17-2011, 06:07 AM
Post: #6
RE: Possible OCLhashcat+ bug
Oops. Looks like a problem here's the -output-format=2

4144e195f46de78a3623da7364d04f11:a:61
93b885adfe0da089cdf634904fd59f71::
dd1c7ceb4c92653a696b7907a4dd4df1:C:43
13757e0fb71915e385efa4dc9d1e08fd:g:67
Find all posts by this user
02-23-2011, 07:02 PM
Post: #7
RE: Possible OCLhashcat+ bug
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 Hash:Password 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?).
Find all posts by this user
02-26-2011, 05:59 AM
Post: #8
RE: Possible OCLhashcat+ bug
Replicated the problem with mode 1000...
Find all posts by this user
02-26-2011, 09:36 AM
Post: #9
RE: Possible OCLhashcat+ bug
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:

4144e195f46de78a3623da7364d04f11:a:61

if i so this:

thumbstone ~ # perl -e 'print "a"' | md5sum
0cc175b9c0f1b6a831c399e269772661 -

but then i did this:

thumbstone ~ # perl -e 'print "a\x00"' | md5sum
4144e195f46de78a3623da7364d04f11 -

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.
Visit this user's website Find all posts by this user
02-27-2011, 03:59 AM
Post: #10
RE: Possible OCLhashcat+ bug
(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:

4144e195f46de78a3623da7364d04f11:a:61

if i so this:

thumbstone ~ # perl -e 'print "a"' | md5sum
0cc175b9c0f1b6a831c399e269772661 -

but then i did this:

thumbstone ~ # perl -e 'print "a\x00"' | md5sum
4144e195f46de78a3623da7364d04f11 -

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.Smile
Find all posts by this user