11-27-2019, 06:18 PM
I'm pretty sure the --encoding-from and --encoding-to only works correctly with -a 0, i.e. only works with dictionary attacks.
The solution for this problem is quite easy, but also not perfectly ideal... the problem is that every 2nd byte could be a 00 byte, but it won't be a 00 byte if a multi-byte characters is used (yeah, that's confusing and encoding is challenging !!!).
This works with -a 3
result is (hash masked as per forum rules):
13edXXXe66580c90XXXXfad6b0XXX7fb:$HEX[32004604]
There are some caveats here... you should be aware that all tools here have some limitations... let's start from the .hcchr file.. it cannot really deal with the new line character 0a, but you can use --hex-charset for that... test.pl also doesn't assume 0a in the input , it's a newline for it... and also for hashcat itself it would be more "safe" to use the $HEX[] notation, just to be 100% sure the right input is applied (when dealing with some strange encodings it's always difficult to exactly be sure beforehand which chars are in the input/output)
btw 32d186 is the hex converted and UTF-8 encoded 2ц password, which is 32004604 in utf16le (note the missing 00 after the 46, that's why -m 1000 fails, but it's a known limitation)
The solution for this problem is quite easy, but also not perfectly ideal... the problem is that every 2nd byte could be a 00 byte, but it won't be a 00 byte if a multi-byte characters is used (yeah, that's confusing and encoding is challenging !!!).
This works with -a 3
Code:
echo -e "\x32\xd1\x86" > pass.txt
./hashcat --stdout pass.txt --encoding-to utf16le > chars.txt
cat chars.txt | ./tools/test.pl passthrough 900 > hash.txt
./hashcat -m 900 -a 3 -1 chars.txt hash.txt --increment ?1?1?1?1?1?1
result is (hash masked as per forum rules):
13edXXXe66580c90XXXXfad6b0XXX7fb:$HEX[32004604]
There are some caveats here... you should be aware that all tools here have some limitations... let's start from the .hcchr file.. it cannot really deal with the new line character 0a, but you can use --hex-charset for that... test.pl also doesn't assume 0a in the input , it's a newline for it... and also for hashcat itself it would be more "safe" to use the $HEX[] notation, just to be 100% sure the right input is applied (when dealing with some strange encodings it's always difficult to exactly be sure beforehand which chars are in the input/output)
btw 32d186 is the hex converted and UTF-8 encoded 2ц password, which is 32004604 in utf16le (note the missing 00 after the 46, that's why -m 1000 fails, but it's a known limitation)