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:28:18 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: Rewrite of the pkzip format posted (on the wiki).

I think I have found the problem here.  I am hopeful this will be an easy
fix.

The file was no deflated.  It was stored, but the code was still using the
deflate checking code.  Big mistake.  The original checks are valid.  From
the pkzip app-notes.txt file, there is this algorithm:

do
   read header from input stream.

   if stored block
      skip bits until byte aligned
      read count and 1's compliment of count
      copy count bytes data block
   otherwise
      loop until end of block code sent
         decode literal character from input stream
         if literal < 256
            copy character to the output stream
         otherwise
            if literal = end of block
               break from loop
            otherwise
               decode distance from input stream

               move backwards distance bytes in the output stream, and
               copy length characters from this position to the output
               stream.
      end loop
while not last block

The 'skip bits until byte aligned', is why I only allow a 0 or 1.  We are
only looking at the first code, and have used the first 3 bits to detect we
have a code 0.  I can easily remove this check, but I am pretty sure it IS
valid.    The 2nd check (the v1!=(v2^0xFFFF)) IS there, it is the 'read
count and 1's complement of count).  That is a check, and without it many
passwords will be require additional work to determine they are bogus
password.

However, for this file, we should have NEVER used this logic anyway. It is
stored.


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

Your e-mail address:

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