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.
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.