[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53461d5e6e00ab65ab87c59457463da3@smtp.hushmail.com>
Date: Thu, 31 Jan 2013 00:47:09 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: DMG (was: dmg2john)
On 30 Jan, 2013, at 18:54 , Milen Rangelov <gat3way@...il.com> wrote:
> On Wed, Jan 30, 2013 at 7:48 PM, magnum <john.magnum@...hmail.com> wrote:
> On 30 Jan, 2013, at 3:12 , magnum <john.magnum@...hmail.com> 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.
magnum
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.
