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.