+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Deprecated; Ancient Versions (https://hashcat.net/forum/forum-46.html)
+--- Forum: Very old oclHashcat-plus Support (https://hashcat.net/forum/forum-23.html)
+--- Thread: Possible OCLhashcat+ bug (/thread-292.html)
Possible OCLhashcat+ bug - mastercracker - 02-11-2011
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
p4I get good hash:password pairs but also got those that seems to be erroneous:
93b885adfe0da089cdf634904fd59f71:
25daad3d9e60b45043a70c4ab7d3b1c6:
fead052eeedcfb31c49b19f91edded24:1
cb824d9f595e14ba63698fa5fe07002a:x
c5940e567348894860e9e45434682f5f:2
86ce15a7f39fc14323b76c9b95c66165:1
RE: Possible OCLhashcat+ bug - atom - 02-11-2011
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
RE: Possible OCLhashcat+ bug - atom - 02-15-2011
any news here?
RE: Possible OCLhashcat+ bug - mastercracker - 02-16-2011
(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.
RE: Possible OCLhashcat+ bug - atom - 02-16-2011
thanks
RE: Possible OCLhashcat+ bug - mastercracker - 02-17-2011
Oops. Looks like a problem here's the -output-format=2
4144e195f46de78a3623da7364d04f11:a:61
93b885adfe0da089cdf634904fd59f71::
dd1c7ceb4c92653a696b7907a4dd4df1:C:43
13757e0fb71915e385efa4dc9d1e08fd:g:67
RE: Possible OCLhashcat+ bug - mastercracker - 02-23-2011
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?).
RE: Possible OCLhashcat+ bug - mastercracker - 02-26-2011
Replicated the problem with mode 1000...
RE: Possible OCLhashcat+ bug - atom - 02-26-2011
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.
RE: Possible OCLhashcat+ bug - mastercracker - 02-27-2011
(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:Good to see that there nothing wrong with it. Personally, I don't mind having those extra ones cracked as a bonus.
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.