[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <2a365e52fc33de5cf794b129e25f99ee@smtp.hushmail.com>
Date: Fri, 17 Aug 2012 16:53:10 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
CC: Pavel Semjanov <pavel@...janov.com>
Subject: Re: RAR early reject
On 2012-08-17 15:52, Pavel Semjanov wrote:
> On 17.08.2012 17:22, magnum wrote:
>>>
>>> Reset bit is placed in plain[0], isn't it? Why you're using plain[2]?
>>
>> I believe it is plain[2]. From unrarppm.c from libclamav:
>>
>> Reset = (max_order& 0x20) ? 1 : 0;
>>
>> and from model.cpp from official unrar:
>>
>> bool Reset=(MaxOrder& 0x20)!=0;
>
>
> Right. MaxOrder is the first byte of stream, i.e. plain[0]. It contains
> reset bit. MaxMB is plain[1]. Please check it out again.
Oh, man. You are right. I really had this straight for a while but I
must have confused things in the process. Strange that my test did not
catch it. Thanks a billion for reviewing!
>> Also, this is now tested with well over 100,000 files with no false
>> reject.
>
> It sounds fantastic.
In hindsight, I ran most of it using -m3 (I did not know there was a
direct connection between -m and LZ/PPM) so I probably just had bad luck
with the relatively fewer -m4 and -m5 I tried.
> BTW, among all those test files (-m1 to -m5) I have yet to see a
>> valid stream use PPM in the first block. I start to think we can reject
>> all PPM. Do you know something to the contrary?
>
> Something strange again.
> -m4, -m5 option really forces PPM code. -m1 to -m3 should force LZ code.
That is even more odd. Why do I not get false rejects if I detect this
wrong? I know I double-checked yesterday and the clamav debug output
agreed with my readings. I need to re-check everything. I'm glad I asked.
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.
