Date: Mon, 12 Sep 2011 10:46:08 -0500 From: "jfoug" <jfoug@....net> To: <john-dev@...ts.openwall.com> Subject: RE: Rewrite of the pkzip format posted (on the wiki). We 'may' need to keep magics. The 'logic' is still there in the fmt, and zip2john still can do that 'if needed'. If the file is stored, then there are NO 'quick' checks at all. The ONLY check, is to decrypt the entire blob and then crc32 it, FULLY. Unless you 'know' some bytes within the blob, that is the ONLY check at all. The deflate algorithm gives us all sorts of validation checks, which allows only a few bytes of a file blob to have to be decrypted and run through the inflate algorithm, to find errors. In the worse case, a couple hundred bytes. For the store method, we have nothing, IN the bit stream that unzip would use to validate, other than the entire stream. Here are the first few decrypted bytes from the crackmeifucan zip blob (the challenge1.zip file that is stored), which is the file listed as having problems: 0x50 P 0x4b K 0x03 0x04 0x14 0x00 Look familiar? It is the start of a pkzip file. Thus the only possible quick check we could use IS the magic check (pkzip signature is \x50\x4b\x03\x04). NOTE, I have not seen many zip'ers that use store, when encrypting data. It has been listed in documentation NOT to do that, to always use the deflate, even if there is no data compression, or only a little. From my personal observation of the data, there is NO gain using deflate vs store, but the ppl writing the zippers think so. They think it inserts some 'unknown' to the start of the stream, but it does not. It is simply a few bytes which can be EASILY computed, followed by the known plaintext of the start of the file (if you have that file, or the magic values from it). Oh well. This has figured out the stored issue. I am going to put some additional logic into zip2john, to try to NOT use stored files, UNLESS we are using magics (and pretty good ones), or unless the stored file is small (which they usually are not). It will use them if that is all there is, but if no magic, then there only needs to be one zip data blob in the hash. Each time we test, we are going to fully decrypt and crc it. This is ugly, and possibly slow. Jim. >From: magnum [mailto:rawsmooth@...dband.net] > >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.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ