Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 13 Jun 2016 18:05:02 +0300
From: Solar Designer <>
Subject: Re: dmg2john's dmg file header parsing

On Fri, Jun 10, 2016 at 10:06:08PM +0300, Solar Designer wrote:
> Upon a second thought, maybe padding the IV to 32 bytes with zeroes, and
> reporting its size in the "hash" as 32, is actually correct for our
> cracker?

Reviewing dmg_fmt_plug.c and opencl_dmg_fmt_plug.c, I see that they use
only first 8 bytes of IV anyway, and this appears correct (it's IV for
DES, which then gets replaced by 20 bytes of HMAC-SHA1 output and that
is finally used as IV for AES).  The IV length specified in the "hash"
is only used to determine how many bytes to decode from hex.  valid()
checks for it to be no more than 32, and there's room only for up to 32.
Perhaps we should enhance valid() to check that ivlen is also no less
than 8.

		memcpy(iv, cur_salt->iv, 8);

In other words, it should not matter whether it's ivlen=8 followed by 8
bytes, or ivlen=32 followed by 32 bytes where the first 8 are correct.
It would be cleaner to only output 8 bytes into the "hash", though.

The issue with encrypted_keyblob_size 48 vs. 64 in for v2
headers still looks like a critical bug in that Python script to me.

Dhiru, would you take care of these issues, please?

And we need a .dmg file that we know the passphrase for to experiment
with this.  Do we have one with encrypted_keyblob_size = 64?  Perhaps
that's what (more) recent OS X uses by default now, so it should be easy
to generate such samples?  Can someone try, please?  magnum, Dhiru?
(I don't have recent OS X.)


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.