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.