[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <02c401cc717c$45199690$cf4cc3b0$@net>
Date: Mon, 12 Sep 2011 13:46:23 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: Rewrite of the pkzip format posted (on the wiki).
I have updated the wiki. A new patch. YES we do need to roll up these
patches into something much easier to apply, and I think I will start down
that path today.
These are the changes in this patch:
Properly handle 'stored' files. This logic was lost from the original pkzip
format to the new one.
Turn the 'magic' logic back on. This was #defined off, but the code still
there. The 'magic' logic looks for file signatures (like PK\x3\x4 for
pkzip).
Added logic to get_salt, so that the magic is removed for most cases. The
times when it IS important, is on some 1 file zips, and when only stored
files were found in the zip.
Added a switch (-nm) into zip2john, to tell that app NOT to try to find
'magic' file types. That auto file type
Within the valid() function, we have to allow zips for 2.0 (0x14), and 1.0
(0x0A) to be allowed as valid. The old code only allowed 0x14. For stored
files, the version needed to extra is set to 0x0A (1.0), by most zippers
(probably all of them). So john has to allow that version as being 'valid'
for processing of stored files.
Re-added the checking logic which magnum removed for the inflate-code 0
section of code.
>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.
>
>OTOH I don't see much of a performance hit. But I do not possess any 1-
>byte checksum zipfiles. These checks are the fourth and fifth so lots of
>false positives are already sorted.
>
>Anyways, I believe this must be in until we get something better.
We now have something better (the correct logic, lol).
Jim.
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.
