Date: Wed, 16 May 2012 01:21:01 +0300 From: Milen Rangelov <gat3way@...il.com> To: john-dev@...ts.openwall.com Subject: Re: RAR early reject True. If I understand correctly, it should never go beyond 63 as no rar archiver I've seen allows it. I think a similar check can be done for maxmb (winrar imposes a limit of 128MB). This helps. But we definitely need some early reject in the LZ case. On Wed, May 16, 2012 at 12:59 AM, magnum <john.magnum@...hmail.com> wrote: > 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 > > Content of type "text/html" skipped
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.