Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 12 Sep 2011 10:46:08 -0500
From: "jfoug" <>
To: <>
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 file that is stored), which is the file listed as having

0x50   P
0x4b   K

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

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.


>From: magnum []
>Both of the tests affected in the enclosed patch clearly gave false
>negatives on 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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ