Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 31 Jan 2013 00:47:09 +0100
From: magnum <>
Subject: DMG (was: dmg2john)

On 30 Jan, 2013, at 18:54 , Milen Rangelov <> wrote:
> On Wed, Jan 30, 2013 at 7:48 PM, magnum <> wrote:
> On 30 Jan, 2013, at 3:12 , magnum <> wrote:
> > I think the remaining problem is in the formats - I just found out that smaller files does not crack either, neither with this version or the original (this version outputs the same for small files). Not even a 100 MB file works. So we still have issues and I'm still not sure this dmg2john is right for large files (but it seems to be). I actually can't find any version of dmg in the git history that works at all for even a small file.
> Here's a thought: I bet there is an iteration count parameter stored somewhere that we fail to read. Our format is fixed at 1000. That would explain why I can't produce *any* crackable DMG file on this computer.
> magnum
> Hello,
> In the header structure, there is a member,  uint32_t kdf_iteration_count which holds the iteration count. I've never seen a dmg file having iteration count different than 1000, but you could check that if the image has different parameters. I am very interested in the results as well since I have also fixed 1000 iterations.

Ah, thanks. How did you ever get the idea to hardcode that!?

Bad news: The iterations count in my test files varies a little and it's not even numbers, but it's over 200,000 (how many SHA-1's is that per candidate, for a key length of 32? About 800,000 I think?). That's a good bump from 1000. At first this did not seem correct (still did not crack) but when I dumped the resulting plaintext I could see lots of consecutive zeros when the right key is used, so this is actually right. Over 200 times slower than older versions.

So I added a known-plain test of "8 consecutive nulls" and voila, my test files can be cracked. But you will need a lot of luck to crack any file with this speed (CPU format can do about 9 c/s per core, OpenCL format just hits hits the watchdog timer on my laptop - we have to use a split kernel here).

When I incorporated the same to the OpenCL format I noticed that it did not support v1 hashes at all although its valid() did not reject them. I really hope we don't have more such bad things in unstable. I made it up to par with CPU code.

Anyway, please test. Try old files, new files, different kinds of formats, encryption types, partition tables and so on. I bet we need even more known plains to test for in order to get every kind of them. This format needs its own README stating its limitations.

If you find a file that doesn't crack, uncomment the #define DMG_DEBUG in the CPU format and see what the plaintext looks like.

Speeds on Bull when attacking one of my test files: GTX 570 637 c/s, Tahiti 1559 c/s. This was with tweaked but not likely optimal work sizes.

Jeremiah, you need to use the latest code, and re-generate all input files with a fresh dmg2john. Please do not hold your breath while cracking.


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.