Posts: 621
Threads: 57
Joined: May 2010
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:
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
Posts: 5,185
Threads: 230
Joined: Apr 2010
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
Posts: 5,185
Threads: 230
Joined: Apr 2010
Posts: 621
Threads: 57
Joined: May 2010
(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.
Posts: 5,185
Threads: 230
Joined: Apr 2010
thanks
Posts: 621
Threads: 57
Joined: May 2010
Oops. Looks like a problem here's the -output-format=2
4144e195f46de78a3623da7364d04f11:a:61
93b885adfe0da089cdf634904fd59f71::
dd1c7ceb4c92653a696b7907a4dd4df1:C:43
13757e0fb71915e385efa4dc9d1e08fd:g:67
Posts: 621
Threads: 57
Joined: May 2010
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
assword 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?).
Posts: 621
Threads: 57
Joined: May 2010
Replicated the problem with mode 1000...
Posts: 5,185
Threads: 230
Joined: Apr 2010
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.
Posts: 621
Threads: 57
Joined: May 2010
(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.