[<prev] [next>] [day] [month] [year] [list]
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.
