|
Message-ID: <000401cf96ec$bdfb3940$39f1abc0$@net> Date: Thu, 3 Jul 2014 13:29:35 -0500 From: "jfoug" <jfoug@....net> To: <john-users@...ts.openwall.com> Subject: RE: Possible bug in zip_fmt_plug.c, bleeding edge >From: Dennis Glatting [mailto:jtr@...2.com] >Sent: Thursday, July 03, 2014 1:19 >> ..... >> There is a working CPU version now in bleeding jumbo. The set_salt >> properly sets the 2 values (mode and passverify). These are part of >> the salt. > >Confirmed. Thanks. I have been digging into the zip format a bit more, and it looks like it should be pretty easy (relatively easy) to convert the JtR zip-aes format into a format that is not FMT_NOT_EXACT (i.e. remove the false positives), and not depend upon spawning code out to a 7z process to test. It looks like there is a 10 byte block of data that follows the encrypted/compressed file data. This 10 byte data is the real authentication block. What we are using now is a 2 byte 'quick verifier' block. To get to this real authentication value, it appears that we simply hmac-sha1 the encrypted/compressed file data using data created when we found the verifier (the verifier is the key setup). So for zip-aes, there appears to be no need to decrypt or inflate the compressed data. We simply need to hmac-sha1 the existing unmodified data, and do a comparison. Now we could/may actually do some aes decryption / inflate logic (like is done in the pkzip format), IF we detect that the file has some 'magic' header signature (like a stored .rar or .jpg or gif or zip, etc file) HOWEVER, this is going to require a new hash signature for john, and will likely deprecate the existing format (and hash layout), which should be deprecated anyway, once we have the real password finding code. This is a simple heads up message. It will take some time to do this.
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.