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.