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:16:26 -0500
From: "jfoug" <>
To: <>
Subject: RE: Rewrite of the pkzip format posted (on the wiki).

I have chopped out ALL files/dirs from the 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 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

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

>From: magnum []
>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
>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.
>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

>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.


[ CONTENT OF TYPE application/x-zip-compressed SKIPPED ]

[ CONTENT OF TYPE application/octet-stream SKIPPED ]

Powered by blists - more mailing lists

Your e-mail address:

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