oclHashcat returning incorrect results

[TheFire]

I find that for sha1($salt.$pass) mode on ATI hardware, it cracks the password, but displays and saves an incorrect string (lacking the right hand characters, or a weird corrupt unicode). This only seems to happen for runs that involve a dictionary (it works fine when I use only the rules).

For what it's worth, the same issue is there in the hex output. A password of "nova1" becomes 0x6e6f76e1. It's marked as cracked, but the output is not correct. Additionally, the password "peaches3" gets truncated to simply "peaches" in the output (no weird unicode or hex).

A typical run looks like this: http://pastebin.com/qA26rcjG

oclHashcat returns:

7436bc3103e2c79f217f60d6f9d635292fc9d2ac:91f2b:1234jkl

but

sha1('91f2b1234jkl') = 58d213cc1cd8b969069879700a78707f14144c46

It seems to be omitting the right hand portion from the output. This problem is present in both the 32 and 64 bit versions.

It'd be really nice if we had access to the previous version while this one is broken. I didn't save a copy, and am now unable to do anything other than brute force.

[atom]

hello! thanks for the report, but i can not reproduce it

root@sf:~/oclHashcat-0.26# cat hash
58d213cc1cd8b969069879700a78707f14144c46:91f2b

root@sf:~/oclHashcat-0.26# ./oclHashcat64.bin --quiet -m 102 hash 1234 jkl
58d213cc1cd8b969069879700a78707f14144c46:91f2b:1234jkl

root@sf:~/oclHashcat-0.26# echo 1234 > dict_l
root@sf:~/oclHashcat-0.26# echo jkl > dict_r
root@sf:~/oclHashcat-0.26# ./oclHashcat64.bin --quiet -m 102 hash dict_l jkl
58d213cc1cd8b969069879700a78707f14144c46:91f2b:1234jkl

root@sf:~/oclHashcat-0.26# ./oclHashcat64.bin --quiet -m 102 hash 1234 dict_r
58d213cc1cd8b969069879700a78707f14144c46:91f2b:1234jkl

root@sf:~/oclHashcat-0.26# ./oclHashcat64.bin --quiet -m 102 hash dict_l dict_r
58d213cc1cd8b969069879700a78707f14144c46:91f2b:1234jkl

[TheFire]

right, but what does it find if you tell it to solve

7436bc3103e2c79f217f60d6f9d635292fc9d2ac:91f2b

That's the hash it screws up on. I know it starts with 1234jkl and has a special character at the end, but it won't print that character even when it finds a solution.

[mastercracker]

I was able to reproduce the problem with the mode 102. I am working on Windows Vista 32 bit with 2 x HD5750. I was doing a simple dictionary attack by using a dictionary on the left side with ?1 on the right side (-1 ?s?d?u?l) and the "]" rule for the left side. Out of 107 found passwords, 10 were correct, 50 were missing the last character and most of the remainder had a weird character at the end which you have to replace by 2 chars. I will PM you my file of found passwords so that you will have the hash, salt and passwords alltogether.

[atom]

i will not try to reproduce oclHashcat bugs any longer since all its features are getting migrated into oclHashcat-plus

[forti]

Just to complete the thread with more informations about configuration.
Here is my test case :

Configuration:
SDK_NAME="AMD-APP-SDK-v2.5-RC2-lnx64.tgz
Ubuntu 11.04
i7 / 8 Go
Linux BigRed 2.6.38-12-generic #51-Ubuntu SMP Wed Sep 28 14:27:32 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
2xATI HD6990

I provide the way I computed the hash from the password in case I made this wrong.
Hash was generated this way using python:

import hashlib
salt = '\x41\x42\x43\x44'
pwd = 'Der5?d3X'
h = hashlib.sha1(salt + pwd).hexdigest().upper()
print h
2DC595158F9EFEE2DF8BB8CC92CD38C61B425167

hashfile contains : 2DC595158F9EFEE2DF8BB8CC92CD38C61B425167:41424344

Command executed :
./oclHashcat64.bin --outfile-format=2 -m 102 --hex-salt ../hashfile -1 '?l?d?u?s' 'De?1?1?1' '?1?1?1'
oclHashcat v0.26 by atom starting...

Digests: 1 entries, 1 unique
Salts: 1 entries, 1 unique
Bitmaps: 8 bits, 256 entries, 0x000000ff mask, 1024 bytes
Platform: AMD compatible platform found
Watchdog: Temperature limit set to 90c
Device #1: Cayman, 1024MB, 0Mhz, 24MCU
Device #2: Cayman, 1024MB, 0Mhz, 24MCU
Device #3: Cayman, 1024MB, 0Mhz, 24MCU
Device #4: Cayman, 1024MB, 0Mhz, 24MCU
NOTE: gpu-accel auto-adjusted to: 32
Device #1: Kernel ./kernels/4098/m0102.Cayman.64.kernel
Device #2: Kernel ./kernels/4098/m0102.Cayman.64.kernel
Device #3: Kernel ./kernels/4098/m0102.Cayman.64.kernel
Device #4: Kernel ./kernels/4098/m0102.Cayman.64.kernel
[s]tatus [p]ause [r]esume [q]uit => s
Status.......: Running
Hash.Type....: sha1($salt.$pass)
Mode.Left....: Mask 'De?1?1?1' (857375)
Mode.Right...: Mask '?1?1?1' (857375)
Speed.GPU*...: 1160.1M/s
Recovered....: 0/1 Digests, 0/1 Salts
Progress.....: 569520881664/735091890625 (77.48%)
Running......: 8 mins, 17 secs
Estimated....: 2 mins, 22 secs
HW.Monitor.#1: 24% GPU, 82c Temp
HW.Monitor.#2: 24% GPU, 83c Temp
HW.Monitor.#3: 24% GPU, 71c Temp
HW.Monitor.#4: 24% GPU, 71c Temp
2dc595158f9efee2df8bb8cc92cd38c61b425167:41424344er5?X:446572353f580000
[s]tatus [p]ause [r]esume [q]uit =>
Status.......: Cracked
Hash.Type....: sha1($salt.$pass)
Mode.Left....: Mask 'De?1?1?1' (857375)
Mode.Right...: Mask '?1?1?1' (857375)
Speed.GPU*...: 1174.1M/s
Recovered....: 1/1 Digests, 1/1 Salts
Progress.....: 610918662144/735091890625 (83.11%)
Running......: 8 mins, 53 secs
Estimated....: 1 min, 45 secs
HW.Monitor.#1: 22% GPU, 82c Temp
HW.Monitor.#2: 21% GPU, 83c Temp
HW.Monitor.#3: 21% GPU, 72c Temp
HW.Monitor.#4: 21% GPU, 71c Temp

Started: Sat Dec 10 22:49:23 2011
Stopped: Sat Dec 10 22:58:17 2011

The bug was quite reproductible using differents masks and passwords/hash combination
It seems also to depends on the length of the mask used.