Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ