[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <854818a9e1c11de7e11c9cefd75cc1ea@smtp.hushmail.com>
Date: Tue, 14 Aug 2012 23:56:23 +0200
From: magnum <john.magnum@...hmail.com>
To: Pavel Semjanov <pavel@...janov.com>
CC: john-dev@...ts.openwall.com
Subject: LZSS rejection (was: Patch for pkzip_fmt_plug.c from jumbo-6)
On 2012-08-06 14:15, Pavel Semjanov wrote:
>> 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.
Pavel,
I still haven't figured LZ out. It's is not exactly like pkzip - from
what I can see, I got:
1. bit 0 (PPM flag) is zero for LZ
2. bit 1 (keepOldTable) we can't use (or does it have to be zero?)
3. bit 2-5 is first bit length
...and so on.
So we don't have any CODE (or BTYPE) field, right? Does this mean RAR
always use CODE 1, or always CODE 2? Or is there something else I do not
get here?
> 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.
I got PPM rejection working fine in RAR CPU code now but it's not much
faster - rar_unpack29() is pretty good at rejecting PPM anyway. I expect
much more from early LZ rejection.
Thanks,
magnum
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.
