06-15-2013, 08:04 AM
For those that are working with hashes that involve UTF-16, there are problems with oclHashcat.
For example, consider the hash of the UTF-16 string 234567, which is 69ab...30e37fa0. The ASCII or UTF-8 encoded version of this string would be 508d...58cfb975.
When a dictionary file used with oclHashcat or hashcat contains a UTF-16 string, both hashcat and oclHashcat do properly read it, and will properly process it. In oclHashcat, if a hash resolves to a UTF-16 password, the password is truncated at the first UTF-16 character (really, the first NUL), no matter what output format is selected.
This is made even more vexing when you are using rules - it becomes virtually impossible to figure out what the password might have been.
So, if you are using UTF-16 in your dictionaries, beware; oclHashcat will not properly output the passwords. I have filed a ticket on this.
Until this is fixed, you may wish to verify your passwords with hashcat, after the oclhashcat.
For example, consider the hash of the UTF-16 string 234567, which is 69ab...30e37fa0. The ASCII or UTF-8 encoded version of this string would be 508d...58cfb975.
When a dictionary file used with oclHashcat or hashcat contains a UTF-16 string, both hashcat and oclHashcat do properly read it, and will properly process it. In oclHashcat, if a hash resolves to a UTF-16 password, the password is truncated at the first UTF-16 character (really, the first NUL), no matter what output format is selected.
This is made even more vexing when you are using rules - it becomes virtually impossible to figure out what the password might have been.
So, if you are using UTF-16 in your dictionaries, beware; oclHashcat will not properly output the passwords. I have filed a ticket on this.
Until this is fixed, you may wish to verify your passwords with hashcat, after the oclhashcat.