UTF-16 in dictionary files

[Waffle]

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.

[epixoip]

are you positive that it's not outputting them properly, or is the real issue that whatever you are using to read the pot is unable to display them properly?

[Waffle]

are you positive that it's not outputting them properly, or is the real issue that whatever you are using to read the pot is unable to display them properly?

I'm very, very positive that no matter what outfile-format you use, oclhashcat is not properly outputting them. hashcat, on the other hand, does work ok. See TRAC ticket 162 for examples.

Beware, if you are using UTF-16 in your dictionary files.

[atom]

Fixed in latest beta