hashcat Forum - Cant Output Cracked Password with Null Character

If an application UTF-8 encodes passwords before hashing them, it hashes them in the format SHA(0x41 0x00 0x42 0x00 0x43 0x00 0x44 0x00) with a null byte every other character.

If you successfully crack this password in hashcat, it will only output the first character, then terminate the file, even if the output is hex encoded.

Additionally, you can't crack passwords longer than 8 characters because of the 16 char length limit of masking rules, since each character takes up two bytes. Please let me know if there's a better way for this.

Very similar to this bug, although I think that it's an output bug, not a rule processing bug. I wasn't sure if i should bump that thread or create new.
https://hashcat.net/forum/thread-292.html

The C# App

Code:
UnicodeEncoding encoder = new UnicodeEncoding();

Byte[] s= encoder.GetBytes(password);

My Test Hash (python)

Code:
import hashlib

import binascii

#unicode ABCD

password = "\x41\x00\x42\x00\x43\x00\x44\x00"

print "Passwordplushhash: " + password

print "Passwordplushhashhex: " + password.encode("hex")

pwhash = hashlib.sha512(password).digest() 

try:

    f = open("~/asdfunicode", "w")

    f.write(binascii.hexlify(pwhash))

finally:

    f.close()

The Hash

Code:
cat ~/asdfunicode

b85bb505961426e951808b138ca0b93bb040e982de5c221431891aae026bfe2d1d2e83767d99c505f883db47ca62ef6e2c68be219e5238a495b960b7aa542391

The Command

Code:
./oclHashcat-plus64.bin -m 1700 -o ~/asdfunicode.output --outfile-format=4 --force --hex-charset -a 3 -1 ?l?d?s?u -2 00 ~/asdfunicode ?1?2?1?2?1?2?1?2

The Output File

Code:
cat ~/asdfunicode.output

41

Version: oclhashcat plus .12 I know it's a bit old, but I was asked not to upgrade anything on this GPU box right now. Let me know if you'd like me to upgrade.

OS: Ubuntu

Driver: Let me know if you need this. I dont know it off hand, but I think it's irrelevant to this.

ah, yeah, that's a tricky one since strings are null-terminated in C. it's a relatively easy fix, though.

please open a ticket in trac.

Thanks! Is Trac working okay? https://hashcat.net/trac/ doesn't show anything and login shows Trac Error - Authentication information not available.

Is there a better way to pass in null bytes than what I'm doing (a mask of every other byte)? If not, it seems like a Unicode option would be useful, since this limitation basically makes it so 8+char passwords are uncrackable by hashcat, since its max is 16 chars.

trac may not still be up after the db crashed the other day, i am not sure its status.

unfortunately there's no way to bypass this, the padding cannot be ignored. the 16 character limitation (which is actually a 15 character limitation, by the way) is better interpreted as a 15 byte limitation. unicode characters count as multiple characters toward the 15-char limit as well.

you could use the cpu version of hashcat for these hashes though.

(02-08-2013, 10:39 PM)epixoip Wrote: [ -> ]trac may not still be up after the db crashed the other day, i am not sure its status.

unfortunately there's no way to bypass this, the padding cannot be ignored. the 16 character limitation (which is actually a 15 character limitation, by the way) is better interpreted as a 15 byte limitation. unicode characters count as multiple characters toward the 15-char limit as well.

Bummer, but I appreciate the help. Seems like extending this limit would be good. I dont see this actually happening, but admins could use unicode encoding and require 8 char passwords to prevent hashcat from cracking anything.

(02-08-2013, 10:39 PM)epixoip Wrote: [ -> ]you could use the cpu version of hashcat for these hashes though.

The documentation says the CPU version does not support hex charsets.

https://hashcat.net/wiki/doku.php?id=mask...ets_in_hex

(02-08-2013, 10:47 PM)cyphear Wrote: [ -> ]Bummer, but I appreciate the help. Seems like extending this limit would be good. I dont see this actually happening, but admins could use unicode encoding and require 8 char passwords to prevent hashcat from cracking anything.

it's a trade-off between speed and flexibility. one of the ways oclHashcat-plus achieves such high speeds is that it does not use the full implementation of each algorithm. rather, the algorithms are reduced to the absolute minimum steps needed to calculate inputs of very specific lengths.

(02-08-2013, 10:47 PM)cyphear Wrote: [ -> ]The documentation says the CPU version does not support hex charsets.

the documentation is a bit outdated, the cpu version does indeed have support for hex charsets.