Old Office and KDF - Printable Version

Old Office and KDF - Printable Version

+- 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: Old Office and KDF (/thread-7216.html)

Pages: 1 2

RE: Old Office and KDF - Mem5 - 02-25-2018

Thanks atom.
I use this cmdline: hashcat64 -m 9800 -a 3 -w 4 -O office.hash ?a?a?a?a?a?a?a?a?a

After 30 hours (on 2x1080), nothing cracked so far.

Wha do you mean by "pretty soon" ? Big Grin

RE: Old Office and KDF - undeath - 02-25-2018

atom suggested mode 9700

RE: Old Office and KDF - Mem5 - 02-25-2018

Same behaviour with 9700 by the way. I've tried both.

RE: Old Office and KDF - philsmd - 02-27-2018

I just had a glance at how easy it is to decrypt office document with the old RC4 encryption (and therefore get access to the whole file content) with the correct RC4 key and it turned out to be even much easier than I could imagine.

Actually, you can just put the RC4 key that hashcat found with the collider mode (-m 9710 for instance) into the source code of libreoffice etc and it will open the file for you. I have no clue why you are struggling to get access to the data. You can even (mis)use freely available open source tools to do all the steps for you without even bothering about the decryption details etc.

I did the test and replaced this line:
https://github.com/LibreOffice/core/blob/9fcef57a34dbd88a98621dfaf8668fa076dd98f1/filter/source/msfilter/mscodec.cxx#L350

Code:
(void)memcpy(m_aDigestValue.data(), aKey.getConstArray(), m_aDigestValue.size());

with this example output for a test word document:

Code:
(void)memcpy(m_aDigestValue.data(), "\xd3\x93\x47\xa9\xf2", 5);

(note: d39347a9f2 was the 5-byte that hashcat cracked with the mask -a 3 ?b?b?b?b?b in -m 9710 collider mode)

and it opens correctly and all the data/words are displayed correctly, no error is shown etc.

Of course it also opens correctly if you input the wrong password now, since the password will be kind of ignored and the hard coded key will be used.
This of course could be done much more flexible i.e. without recompiling the source all the time (for instance by (mis)using the password field as input field for the decryption key instead of the password itself etc... this of course requires much more source code changes compared to the single line patch from above)

One minor problem of this hard-coded approach is that the libreoffice unit tests will fail of course and therefore you will see errors when running the default "make" target. This can be ignored (and probably you can also skip the tests somehow, but it's not important at all).

My example hash was this one (rc4 key is d39347a9f2):

Code:
$oldoffice$1*dea5c95e9b48f12f939963da750d07ec*50a7083023ac7a9798b9ef79f6723afd*f7f4280aa2740f6954fe1e02d2925045

and the file can be found here (password "hashcat"):
https://nofile.io/f/7txY80TyzFt/password_protected_word.doc (sha256 file checksum: 72b980e636a3d95a097e2b89e31dbc94d899b2b1608739c0e1396d686e05a158)

Note: to make this post a little bit more useful, here are some interesting observation about the function calls that libreoffice uses:
Init97Codec () is called from here: https://github.com/LibreOffice/core/blob/9fcef57a34dbd88a98621dfaf8668fa076dd98f1/sw/source/filter/ww8/ww8par.cxx#L5778
within Init97Codec () the code calls rCodec.InitKey () which sets the RC4 decryption key: https://github.com/LibreOffice/core/blob/9fcef57a34dbd88a98621dfaf8668fa076dd98f1/sw/source/filter/ww8/ww8par.cxx#L5581
The final decryption key (normally derived from the password) is set here: https://github.com/LibreOffice/core/blob/9fcef57a34dbd88a98621dfaf8668fa076dd98f1/filter/source/msfilter/mscodec.cxx#L350