Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Thu, 3 Jul 2014 13:29:35 -0500
From: "jfoug" <>
To: <>
Subject: RE: Possible bug in zip_fmt_plug.c, bleeding edge

>From: Dennis Glatting [] 
>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.