[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <b93d70b748d82507f3213a27140f11fa@smtp.hushmail.com>
Date: Fri, 16 Jun 2017 20:54:50 +0200
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: Extracting CRC of files from RAR archive
On 2017-03-07 22:33, Юлиан Машаев wrote:
> 2017-03-05 16:10 GMT+02:00 magnum <john.magnum@...hmail.com>:
>
>> On 2017-03-04 17:13, Юлиан Машаев wrote:
>>
>>> I want to obtain few bytes from password protected RAR file,
knowing all
>>> other bytes. I tested "brute-force" attack and I obatined 10 bytes(just
>>> enough for me). Now the problem is that sometimes this RAR file can be
>>> encrypted both data and file list. E.g. on file without full encryption
>>> rar2john returns:
>>> 2017_04_roul.rar:$rar3$**1**de8ad915db6e3d57**69ad6816*(this is
>>> CRC32)*19424*125278*...
>>> but when filelist is encrypted:
>>> 2017_04_roul_n.rar:$rar3$**0*
>>> *61f78a76817adc3d*5023d65d291834942e414015cca48084
>>>
>>> No CRC is returned :(
>>> Is it possible somehow to obtain it?(there is just one text file, and I
>>> know most of the data except few bytes)
>>>
>>> As far as I remember, CRC is also encrypted in second case, and at
opening
>>> - both CRC and data are decrypted, then CRC of decrypted data is
compared
>>> with decrypted CRC. Seems safe enough, but still, I would like to find
>>> some
>>> methods to extract checksum of the file.
>>>
>>
>> I'm not sure what you are trying to accomplish. For a "rar -hp" archive,
>> we decrypt a certain single block of the data and compare it with a
static
>> known plaintext of (hex) 'c43d7b00400700'. If it matches, we're
done. How
>> would knowing the CRC of some file in that blob of data make it any
better?
>> It would still be a known plaintext but a whole lot harder to find
(if at
>> all possible).
>>> The point is - I recover the whole file from to get the remaining 8-10
> bytes by brute-force generating last lines of file and computing theirs'
> CRC - if it matches - I'm done. I'm not brute-forcing the password, since
> it is 64 characters long, lowercase, upercase, digits, special
symbols, and
> no way it can be guessed in rational time.
>
> As I understand c43d7b00400700 is "Terminator" block, and it is constant,
> that's why it is possible to speed up brute-force of password by testing
> encryption on small block, not on whole file. But it seems that with -hp
> there is no way to extract CRC of non encrypted files(unrar uses them to
> test if files were correctly deciphered with given password), because
file
> headers are encrypted just as usual data. Still there is a hope,
because it
> is just a single file, even with known filename and size, but without
> CRC(of original file) it is not possible to perform successful attack.
Like I said, we decrypt a *single* block (as in 16 wee bytes) of AES
data regardless of archive size. You seem to completely overlook that. I
can't see how anything you vaguely suggest would speed things up? If you
prove me wrong, I'll be very happy to acknowledge that.
Cheers,
magnum
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.
