[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <02b501cc715e$f0b65f10$d2231d30$@net>
Date: Mon, 12 Sep 2011 10:16:26 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: Rewrite of the pkzip format posted (on the wiki).
I have chopped out ALL files/dirs from the challenge1.zip file, other than
this one file.
I am not sure what exactly to do. The first check (for inflate code 0), was
to only proceed if that first byte was 0 or 1. That was my own conjecture.
This zip file has an 0x80 as the first byte. The other 5 bits get dropped,
so I am not sure why they were anything other than 0, but it is pretty easy
to remove that check. This .zip file is the 'singleton' file that was
causing problems. There is also a problem in validation, I have to handle
zip version 0x14 and 0x0A (the 0A is version 1, pkzip, which a 'stored'
value is set to). There is a new patch (on the wiki),
0011-pkzip-rewrite-fix-1.diff that will add this new check to valid().
With this patch (so the cmiyc_chal1.zip will pass valid), it will NOT be
detected (at least it is not detected for me). This is because zlib will
not properly handle the zip blob either. The v1!=(v2^0xffff) causes zlib to
bail out. HOWEVER, unzip from unix (and pkunzip) both handle this just
fine.
The other check was in zlib. I thought that the zlib code was used in unix
unzip, but obviously it is not. The unix unzip program will unzip this
blob. My code AND zlib both fail to inflate this blob. I am going to dig
into sources and find out just why zlib is using that check, if it is not
valid.
>From: magnum [mailto:rawsmooth@...dband.net]
>
>On 2011-09-10 23:18, JimF wrote:
>> If there is problems you find (or a patch I have left out, as it
>> appears may have happened from a post you made a little after this
>> one), then post them, if at all possible. I will try to work through
>> any issues as soon as I have time.
>
>Wiki is updated. Here is what I had to do, to get that last zipfile
>cracked.
>
>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.
This lets 1/4 of the passwords which pass the checksum to get past the
'quick' checks, and into partial or full zlib checking (which is much
slower).
>Anyways, I believe this must be in until we get something better.
I will find out what is required. It 'IS' possible, that the 0x0A (pkzip
version 1) handles these checks a little differently. I will dig through
some older APP-NOTES from pkzip, if I can find them.
Jim.
Download attachment "cmiyc_chal1.zip" of type "application/x-zip-compressed" (20782 bytes)
Download attachment "cmiyc_chal1.in" of type "application/octet-stream" (90 bytes)
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.
