hashcat Forum

Hello

I have been wondering about why it seems to be impossible to crack a super easy password from an Excel 2007 document.
I have created two empty xlsx documents, one encrypted with one letter password: "C" and another one with one letter password "Ć" - this is a polish letter.

C in UTF8 is 0043
Ć in UTF8 is c486

I tried to crack the C password and of course succeded with this command to launch hashcat:

• hashcat64.exe -a 3 -w 3 -m 9400 testhash-C.lst --hex-charset -1 0043 ?1
  

So i thought that it should work exactly the same way for the Ć password:

• hashcat64.exe -a 3 -w 3 -m 9400 testhash-Ć.lst --hex-charset -1 c486 ?1
  

Of course the "Ć" password is exhausted and nothing seems to make it work.
I tried to break the hex values to base code and character code by using two separate charsets - still EXHAUSTED:

• hashcat64.exe -a 3 -w 3 -m 9400 testhash-Ć.lst --hex-charset -1 c4 -2 86 ?1?2
  

Could you please tell me what am I doing wrong in this case?
I am attaching this empty file from Excel with Ć password - in case if it helps.

Thank you in advance!

this is a known limitations of utf16le encoding within the kernel:
https://github.com/hashcat/hashcat/blob/...xt#L25-L34

Allright, if it is a kernel deep issue, then I guess that cracking such Office document with any multibyte character in the password is basically impossible at this moment.

If it is not true - please correct my thought process

Thank you very much for response!

Regards,
Sławek

Hey,
I have got following question. Is it be possible to somehow (in a easy way) alter the code so it would just take the mask as is and tried to use it withou any guarantees? I know it would would be huge requirement on user to keep this in mind. Also, I'm not proposing it as new "feature" which should be added I'm simply asking about the possibility and potential inpact on the performance?

Thank, Azaran

P.S.: Could you point me to source file when that utf16le convertion magic happens? Is it in kernel files or in some CPU code?