[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 31 Jan 2013 07:55:26 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: DMG (was: dmg2john)
On 31 Jan, 2013, at 7:28 , Milen Rangelov <gat3way@...il.com> wrote:
> Hello,
>
> Ah, thanks. How did you ever get the idea to hardcode that!?
>
>
> At that time, all of the dmg files I tried had 1000 iterations. Since I used vilefault as a starting point, I noticed it is a hardcoded constant there. Not very wise I admit. BTW what version of OSX are you using to generate the dmgs?
Latest, 10.8.2.
>
> 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.
>
>
> This doesn't sound good. That many iterations don't render even GPU attacks very practical :( The good news is that consecutive zeros. In that case though checks would be done for data in the last two sectors. Could you post the decrypted final 3-4 blocks of the dmg file?
The zeros were in both block. The test I added was for the last sectors. I'll submit files to Dhiru's repo. These were newly-created, never used dmg files using defaults + encryption. I will do more tests soon-ish.
>
> 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.
>
>
> Isn't the v1/v2 check performed on host? The GPU part should be the same for both. Unless of course you do the key unwrap on the GPU.
Exactly, only host code was missing and it was identical to the CPU format. I just used Meld to merge CPU code into the host part of the OpenCL format. This is one reason we should put formats like this in one source file, and actually use the same functions.
> 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.
>
>
> My problem with dmg is that I don't have access to Apple machines so all the inputs I have are several sample files (from vilefault project, from JtR, from CMIYK contest and several others people sent to me in the past). All of them had the same well known structure (and the 1000 iterations). So I guess the iterations thing changed in some recent OSX version. Hopefully, the layout of the image did not change though as it would require a lot of additional work.
I think our biggest problem now is to know "known plains" for all kinds of images. We need to create files for all combinations of format options.
magnum
Content of type "text/html" skipped
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.
