Date: Fri, 9 Sep 2011 16:59:16 -0500 From: "jfoug" <jfoug@....net> To: <john-dev@...ts.openwall.com> Subject: Rewrite of the pkzip format posted (on the wiki). The pkzip_fmt has been re-written, and the patch posted on the wiki (The patch 0011-pkzip-format-rewrite-1.diff. and found on http://openwall.info/wiki/john/patches) This format is faster. How much faster depends upon the type of zip file, and the size of the smallest file, and how many encrypted zip files are in that zip file. The format now should run pretty closely for 1 byte checksum and 2 byte checksum files. The 1 byte checksums simply run a few percent slower than the 2 byte ones. Prior version could be VERY slow, for a 1 byte checksum, if there was only 1 encrypted file in the zip (even slow for 1 byte checksum if there were 2 files). The prior version was also slower for the single zip blob file if the zip was 2 byte checksum. The new format performs incremental work, trying to do as little as possible, to determine that a password is bogus. There 3 steps done in the crypt_all (possibly 4, if the ascii/magic logic is turned back on). The first 2, are done completely by code within the format, decryption logic, and some custom zip-inflation code to check for bogus 'zip'data. The last check done in crypt_all, is ONLY done on the file we have the full zip-blob data for (always the last file checked), and is ONLY done if all prior testing says that this password 'could' be correct. This check is done with zlib. If all tests pass, then in cmp_exact, there is FULL decryption, zip-inflation, crc32 checking code added. That code will allow us to know that we have the proper password. This format still uses quite a bit of memory resources, but the memory useage has been cut down A LOT. This should only be an issue if trying to crack 100's or 1000's of zip file hashes. I am working on a document about the format, how the cracking is done, some information about what/how john is running, and some hints on building the hashes. Now with the 'magic/text file' logic being removed somewhat, the usage of the format is MUCH simpler. Simply run zip2john, and then run john. NOTE, the zip files DO have to be available for john to run, since it will load the zip data at run time if it needs it. This limitation is due to the line length limitations in john, and due to trying to reduce some of the memory requirements for the format. NOTE, the format of the lines has changed. Any hashes created with the prior pkzip (zip2john) format will not be read by this format. Thus, any zip input hash files should be re-created (with the zip2john). However, any work done with the prior version, should be 'valid' and would not need to be re-done. It is simply those input files will need to be update. Jim. 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.