Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 17 Aug 2012 16:53:10 +0200
From: magnum <>
CC: Pavel Semjanov <>
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.


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.