[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b45078c650f9c379e122827130690363@smtp.hushmail.com>
Date: Tue, 15 May 2012 23:59:09 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: RAR early reject
On 05/15/2012 09:05 AM, Milen Rangelov wrote:
> I am reaching the same conclusion. I was able to do another check for the
> PPM part, order should never be more than 63 (as this is the archiver
> limit) and this is safe I think.
Do you mean max_order in ppm_decode_init() right after reading it from
rar_get_char()? Or did you test somewhere else?
I also found from original unpack.cpp that filter_pos in add_vm_code()
should never be > 1024 but I haven't ever seen it happen. Maybe I'll
drop that test again even though it's there in the original code (for
some reason it was not in clamav's code). BTW I only recently realized
how easy it is to compare the original .cpp code with clamav's code.
They really just ported it. The original code has more comments.
We are currently rejecting 93% of the data on average, compared to
reading all of the data each time. That may sound good, but for a 500 MB
file we still need to decrypt and read 3.6 MB on average.
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.
