hashcat Forum

Hello,

I try find/verify password František1 for NTLM hash 902BD6FDDF5248CE7902174E408F3F1F

JtR find it. Input file utf-8

I try encode input word with different charset, but without result.


I try Franti?bek1 or Franti?b?bek1 for substitute special character, but not fount it.

Some idea ?


Thank you.

The special character š is a 2-byte hex value.
You need to force Hashcat to attempt 2-byte hex values. (with ?b?b or with --hex-charset)

The corresponding hex-value for š is 0xc5 0xa1.

When doing so, it does the job...


Probably your NTLM-hash is not correct.

Using https://tobtu.com/lmntlm.php I can turn František1 into the NTLM hash 902BD6FDDF5248CE7902174E408F3F1F which means your NTLM-hash is correct.

You also say you used ?b?b which did not lead to hashcat cracking it.

I too tried ./hashcat -a 3 -m 1000 902BD6FDDF5248CE7902174E408F3F1F Franti?bek1 and ./hashcat -a 3 -m 1000 902BD6FDDF5248CE7902174E408F3F1F Franti?b?bek1 but hashcat did not crack it.

If I make a NTLM hash of a variant without unicode char: Frantisek1 (64436D005F319C8AC790209424608CD2) and run ./hashcat -a 3 -m 1000 64436D005F319C8AC790209424608CD2 Franti?bek1 then hashcat does find it.

This is very strange, maybe hashcat doesn't do unicode well?

EDIT:

also trying  --hex-charset did not work, Franti in hex is 4672616e7469 and ek1 in hex is 656b31:

./hashcat -a 3 -m 1000 --hex-charset 902BD6FDDF5248CE7902174E408F3F1F 4672616e7469?b656b31

./hashcat -a 3 -m 1000 --hex-charset 902BD6FDDF5248CE7902174E408F3F1F 4672616e7469?b?b656b31

Nor does using ?h for hex chars:

./hashcat -a 3 -m 1000 --hex-charset 902BD6FDDF5248CE7902174E408F3F1F 4672616e7469?h?h656b31

./hashcat -a 3 -m 1000 --hex-charset 902BD6FDDF5248CE7902174E408F3F1F 4672616e7469?h?h?h?h656b31

(04-30-2018, 02:17 PM)DanielG Wrote: [ -> ]This is very strange, maybe hashcat doesn't do unicode well?

That's correct. At least for NTLM or any other kernel using the make_utf16* functions (defined in OpenCL/inc_common.cl).
NTLM is simply MD4 but the password is encoded in UTF-16.


This is what's supposed to be fed into the MD4 hash function.
make_utf16le() cheats a bit and simply appends a null byte after every input byte. That works fine as long as all the characters are ASCII.
But in your case hashcat feeds this into the MD4 hash function which results in a different hash.

(technically it's 0072 0046... etc. because of little endian)

So until someone contributes a valid UTF-16 encoder this will be an issue.

Shouldn't this then work?:

./hashcat -a 3 -m 1000 --hex-charset 902BD6FDDF5248CE7902174E408F3F1F 4600720061006e0074006900?b?b65006b003100

./hashcat -a 3 -m 1000 --hex-charset 902BD6FDDF5248CE7902174E408F3F1F 004600720061006e00740069?b?b0065006b0031

here you add the null bytes manually and the two byte unicode š (6101) should fall in the ?b?b ? However hashcat doesn't find it in this case either.

Good thinking but no that does not work. The reason: the UTF-16 expansion will still be applied (happens on GPU).
So 46007200 will become 46000000 72000000 etc. However if you use -m 900 (MD4) hashcat will find that hash.

The only workaround I can think of is to do the UTF-16 encoding like this.
But that means you can't use rules. Well you can but most of them will produce invalid UTF16 sequences.