Date: Mon, 12 Sep 2011 13:46:23 -0500 From: "jfoug" <jfoug@....net> To: <john-dev@...ts.openwall.com> Subject: RE: Rewrite of the pkzip format posted (on the wiki). I have updated the wiki. A new patch. YES we do need to roll up these patches into something much easier to apply, and I think I will start down that path today. These are the changes in this patch: Properly handle 'stored' files. This logic was lost from the original pkzip format to the new one. Turn the 'magic' logic back on. This was #defined off, but the code still there. The 'magic' logic looks for file signatures (like PK\x3\x4 for pkzip). Added logic to get_salt, so that the magic is removed for most cases. The times when it IS important, is on some 1 file zips, and when only stored files were found in the zip. Added a switch (-nm) into zip2john, to tell that app NOT to try to find 'magic' file types. That auto file type Within the valid() function, we have to allow zips for 2.0 (0x14), and 1.0 (0x0A) to be allowed as valid. The old code only allowed 0x14. For stored files, the version needed to extra is set to 0x0A (1.0), by most zippers (probably all of them). So john has to allow that version as being 'valid' for processing of stored files. Re-added the checking logic which magnum removed for the inflate-code 0 section of code. >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. > >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. > >Anyways, I believe this must be in until we get something better. We now have something better (the correct logic, lol). Jim.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ