[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e717d14672d68c7ad43bdf755884780e@smtp.hushmail.com>
Date: Tue, 06 Mar 2012 01:16:11 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: RAR format finally proper
Thanks to Milen's advice I am now committing a working version of RAR
format that does not spawn unrar yet can attack all modes. It was fairly
simple to get the clamav code running, I changed it to work on a memory
buffer instead of a file handle, and removed legacy RAR stuff and
autoconf macros. It now decrypts and CRC's on the fly. I also added OMP
to the format. We do not support solid archives yet but I think that's
doable with a little research (it's supported by the clamav code).
I can see now the AES decryption get significant with larger files.
For small files the speed is about the same as for the -hp mode. I
tried a 2 MB file and speed went down from ~36 c/s per core to one-digit
figures :-/ But rar2john will now scan the whole archive and pick the
smallest file possible.
There are a lot more optimisations possible. I'm not sure the unpack
code bails out immediately on any kind of bad data, it may continue
longer due to laxed checking. But in many cases it does bail out early,
it averaged rejecting after 41% of the available data in a small test
with various files. Anyway we now have a decent base to work from so
things will only get better.
We still need OpenCL of course. Samuele, hit it! :-)
Note that input files created with any older version of rar2john need to
be recreated.
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.
