[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d6ccd8ff785c30bc024cd468b054e843@smtp.hushmail.com>
Date: Wed, 28 Apr 2021 11:04:50 +0200
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: Extracting the hash from MS word
On 2021-04-27 17:05, magnum wrote:
> On 2021-04-27 03:14, Ian B wrote:
>> I am going through an old directory and binning/checking some old
>> documents ~2005/6 there's a few encrypted word documents for which I
>> have forgotten the password. I successfully recovered the hash and
>> hence the password from a few with the office2john.py script. However,
>> for two of them this fails with the following issue
>>
>> em1.doc : invalid keySize
>> Traceback (most recent call last):
>> File "./office2john.py", line 3148, in <module>
>> ret = process_file(sys.argv[i].decode("utf8"))
>> File "./office2john.py", line 3109, in process_file
>> passinfo = find_rc4_passinfo_doc(filename, workbookStream)
>> File "./office2john.py", line 2553, in find_rc4_passinfo_doc
>> if typ == 3:
>> UnboundLocalError: local variable 'typ' referenced before assignment
>
> If latest code give you an error, we have a bug somewhere. If you're
> willing to share one of those files with us (or just me, in private
> email) we can have a look at it.
Ian kindly sent me a copy of the file in question (Thanks!) and some
debug prints reveal this:
em1.doc : providerType d algId 6801 algHashId 8004 keySize 56
8004 means SHA-1 and 6801 means RC4 so that's normal, but the keysize is
56. Until now we've only ever seen 40 (courtesy of NSA) or 128 but
trying to parse the specifications, 56 is also valid.
Actually MS-OFFCRYPTO doc says "When using CryptoAPI RC4 encryption, be
aware that the Microsoft Base Cryptographic Provider v1.0 is limited to
56-bit key lengths". We've seen many documents using RC4 and 128 bits,
so maybe that text just means those documents used RC4 from somewhere
else than CryptoAPI, or version later than 1.0... I have no idea yet.
Anyway apparently it's just a matter for us to support it. I'll need to
experiment further but one problem is our current $oldoffice$ hash
format: Instead of separately storing hash algorithm and key size, we
have just a "type" which currently boils down to
0 ... MD5, RC4, 40-bit
1 ... MD5, RC4, 40-bit
2 ... currently never used but treated as MD5, RC4, 40 bit
3 ... SHA1, RC4, 40-bit
4 ... SHA1, RC4, 128-bit
I would rather put the actual algHashId, algId and keySize figures in
there but to be backwards compatible that's a bad idea. So maybe I
should just pick type 5 for "SHA1, RC4, 56-bit". This would also stop
older versions of John from accepting it then handle it incorrectly - so
probably better than repurposing type 2.
Also, until we know how to reproduce *creating* such document samples,
or we crack one of Ian's, we can't be sure it's simply a matter of
truncating to 56 instead of 40 all else equal: There may be some other
magic involved.
I enclose a diff that might make Jumbo support this type but I have no
idea it's correct.
magnum
View attachment "oldoffice56.diff" of type "text/plain" (4104 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
