Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.