[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E6CF80D.3050204@bredband.net>
Date: Sun, 11 Sep 2011 20:03:57 +0200
From: magnum <rawsmooth@...dband.net>
To: john-dev@...ts.openwall.com
Subject: Re: Rewrite of the pkzip format posted (on the wiki).
On 2011-09-11 00:52, magnum wrote:
> Both of the tests affected in the enclosed patch clearly gave false
> negatives on 2011-CrackMeIfYouCan_part1.zip. However, there *might* be
> better ways than just commenting them out like I did. In this case, C
> was 80 (decimal) in the first test and v1 was 0x034b while v2 was 0x1404
> (v2^0xffff was 0xebfb). We might be able to put these back with some
> correction for what is valid or not. If not, there are some more code
> that should be commented out 'cause it's currently unnecessary.
>
> OTOH I don't see much of a performance hit. But I do not possess any
> 1-byte checksum zipfiles. These checks are the fourth and fifth so lots
> of false positives are already sorted.
I realised I could hack my infiles so they use a 1-byte checksum, for
testing. The test file was 2.5 MB uncompressed.
With the offending early tests in place, 1-byte or 2-byte checksums run
almost the same speed. With the tests disabled, 1-byte checksum runs a
couple percent slower, but there is still not a single full decryption +
decompression made for a false positive. My test ran --inc:digits to
completion so there were >100 million candidates tried. The remaining
tests rejected every one of the false positives semi-early. Good stuff!
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.
