Encoding: Recovered password seems wrong

[digicromo]

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)?

[buka]

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.

[digicromo]

Thank you @buka

Meanwhile, I found the solution after reading this post: https://hashcat.net/forum/archive/index....-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