[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 12 Sep 2011 10:46:08 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: Rewrite of the pkzip format posted (on the wiki).
We 'may' need to keep magics. The 'logic' is still there in the fmt, and
zip2john still can do that 'if needed'.
If the file is stored, then there are NO 'quick' checks at all. The ONLY
check, is to decrypt the entire blob and then crc32 it, FULLY. Unless you
'know' some bytes within the blob, that is the ONLY check at all. The
deflate algorithm gives us all sorts of validation checks, which allows only
a few bytes of a file blob to have to be decrypted and run through the
inflate algorithm, to find errors. In the worse case, a couple hundred
bytes. For the store method, we have nothing, IN the bit stream that unzip
would use to validate, other than the entire stream.
Here are the first few decrypted bytes from the crackmeifucan zip blob (the
challenge1.zip file that is stored), which is the file listed as having
problems:
0x50 P
0x4b K
0x03
0x04
0x14
0x00
Look familiar? It is the start of a pkzip file. Thus the only possible
quick check we could use IS the magic check (pkzip signature is
\x50\x4b\x03\x04).
NOTE, I have not seen many zip'ers that use store, when encrypting data. It
has been listed in documentation NOT to do that, to always use the deflate,
even if there is no data compression, or only a little. From my personal
observation of the data, there is NO gain using deflate vs store, but the
ppl writing the zippers think so. They think it inserts some 'unknown' to
the start of the stream, but it does not. It is simply a few bytes which can
be EASILY computed, followed by the known plaintext of the start of the file
(if you have that file, or the magic values from it). Oh well.
This has figured out the stored issue. I am going to put some additional
logic into zip2john, to try to NOT use stored files, UNLESS we are using
magics (and pretty good ones), or unless the stored file is small (which
they usually are not). It will use them if that is all there is, but if no
magic, then there only needs to be one zip data blob in the hash. Each time
we test, we are going to fully decrypt and crc it. This is ugly, and
possibly slow.
Jim.
>From: magnum [mailto:rawsmooth@...dband.net]
>
>Both of the tests affected in the enclosed patch clearly gave false
>negatives on 2011-CrackMeIfYouCan_part1.zip. However, there *might* be
>better ways than just commenting them out like I did. In this case, C
>was 80 (decimal) in the first test and v1 was 0x034b while v2 was 0x1404
>(v2^0xffff was 0xebfb). We might be able to put these back with some
>correction for what is valid or not. If not, there are some more code
>that should be commented out 'cause it's currently unnecessary.
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.
