[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <501FB573.90605@semjanov.com>
Date: Mon, 06 Aug 2012 16:15:47 +0400
From: Pavel Semjanov <pavel@...janov.com>
To: john-dev@...ts.openwall.com
CC: magnum <john.magnum@...hmail.com>
Subject: Re: Patch for pkzip_fmt_plug.c from jumbo-6
> On 2012-07-27 11:10, Pavel Semjanov wrote:
>> Hello,
>>
>> I've tested and fixed some errors (one is severe, the code was not
>> working on some files!) in function check_inflate_CODE1().
>> The patch is attached.
>>
>
> Pavel,
>
> Thanks, this is really appreciated! Could you possibly supply test files
> showing the problem? This would make our audit a lot easier and faster.
I've attached two files. The first one (future.zip) has a false early
reject. The second one passes ok early reject, but only by accident - it
has end-of-block marker in the first 8 bytes, so the logic of the
function is wrong.
>
> BTW, could you by any chance help us with better early rejection in the
> RAR format? I'm just asking :)
It's quite simple. In CPU code, the block is checked for LZ type or PPM
type. If it's LZ, the Huffman table test is used, like ZIP does. If it's
PPM, the reset bit should be set and MaxMB size can't be grather than
7f. If yes, the decompression begins and password is rejected quite fast
in RAR PPM code.
In GPU code, only standard parameters (i.e, -m0 .. -m5) are allowed.
This makes very effective early reject by checking MaxOrder and MaxMB sizes.
--
SY / C4acT/\uBo Pavel Semjanov
_ _ _ http://www.semjanov.com
| | |-| |_|_| |-|
Download attachment "9bytes.zip" of type "application/zip" (158 bytes)
Download attachment "Future.zip" of type "application/zip" (342 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.
