+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Support (https://hashcat.net/forum/forum-3.html)
+--- Forum: hashcat (https://hashcat.net/forum/forum-45.html)
+--- Thread: Encoding: Recovered password seems wrong (/thread-11246.html)
Encoding: Recovered password seems wrong - digicromo - 01-12-2023
Hello,
I want to understand how hashcat handles multibyte character encoding.
my OS: Ubuntu 22.04.1
hashcat: v6.2.6
I made a simple test with "aá" and the NTLM hash:
$ echo -n "aá" | iconv -f UTF-8 -t UTF-16LE | openssl dgst -md4 -provider legacy
8fdba81f5a363a5b13c653cbe1325d60 (confirmed with https://crackstation.net/)
In UTF-16LE (used on Windows and NTLM) "aá" has a total of 4 bytes:
$ echo -n "aá" | iconv -f UTF-8 -t UTF-16LE | xxd
00000000: 6100 e100
So, I was expecting this command to work (brute force with 4 bytes):
hashcat -m1000 -a3 8fdba81f5a363a5b13c653cbe1325d60 ?b?b?b?b
but it results in "Recovered: 0" (zero) 😒
However, this one works (notice: only 2 bytes):
hashcat -m1000 -a3 8fdba81f5a363a5b13c653cbe1325d60 ?b?b
and it displays this as solution: $HEX[61e1] (which is wrong, it should be 6100 e100) 🤔
Why is the 4-byte attack not working?
Is the 2-byte solution showing a result on a different encoding (other than UTF-8, or UTF-16LE)?
RE: Encoding: Recovered password seems wrong - buka - 01-12-2023
Hashcat doesn't encode to UTF16-LE properly, that's why. Instead, it adds a zero byte after each byte. Which works for the lower half of the ASCII table, but doesn't for multi-byte characters.
RE: Encoding: Recovered password seems wrong - digicromo - 01-12-2023
Thank you @buka
Meanwhile, I found the solution after reading this post: https://hashcat.net/forum/archive/index.php?thread-8418.html
So, the solution to the "aá" NTLM hash is:
hashcat -m 900 --encoding-to utf16le -a3 8fdba81f5a363a5b13c653cbe1325d60 ?b?b?b?b
8fdba81f5a363a5b13c653cbe1325d60:$HEX[6100e100]
Conclusion: don't use -m1000 for NTLM multibyte characters