[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <01bf0cfaca7d85c4b5ed5f0f0bffbb07@smtp.hushmail.com>
Date: Wed, 30 Jan 2013 03:12:34 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Re: dmg2john
Here might be a fixed version (with a little debug output). However, it still does not crack. But 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.
This version also avoids the almost cute insanity of reading all of the file into memory. That would be a dubious idea for a 300 GB file.
magnum
Download attachment "dmg2john.c.gz" of type "application/x-gzip" (1874 bytes)
On 30 Jan, 2013, at 1:42 , Jeremiah Grossman <jeremiah@...tehatsec.com> wrote:
> I agree, I think we're experiencing a separate issue.
>
> With respect to the all-zero issue, this behavior was seen after the segfaulting issue was fixed, with >11GB DMGs, using the most recent git clone several hours ago and adding supplied patches before building.
>
> In @jmgosney words when helping me debug, "i think changing the print format from %d to %lu will fix the all-zero hash issue."
>
> I can't speak to the accuracy of this statement though. We did't make any progress.
>
>
> From: magnum <john.magnum@...hmail.com>
>
>>
>> I have reproduced Jeremiah's problems and I am running 64-bit. Even when using size_t or ULL, I get the two last blobs all-zero. I believe we are looking at a different issue now - the initial one is fixed.
>>
>> Jeremiah, what was that you wrote about @jmgosney? Did he see this? Was that with a version of this code or some other?
>>
>> magnum
>
> On 30 Jan, 2013, at 1:12 , Milen Rangelov <gat3way@...il.com> wrote:
>
>> Sorry my mistake, long would be 64-bit on x86_64. That's rather strange, only explanation would be it was run on a x86 host.
>>
>>
>> On Wed, Jan 30, 2013 at 2:03 AM, magnum <john.magnum@...hmail.com> wrote:
>> On x86_64, long int is 64-bit in Linux as well as OSX. The same goes for GPU by the way. But I should have made it long long anyway. It was just meant as a quick fix/test and I knew Jermeiah was using 64-bit.
>>
>> magnum
>>
>>
>> On 30 Jan, 2013, at 0:45 , Milen Rangelov <gat3way@...il.com> wrote:
>>
>>> uint64_t I meant. I don't know if C99 stdint.h stuff is acceptable for jtr though, but it really helps in situations like that. But definitely long is 32-bit int on both x86 and x86_64. Also the compiler likes to do some implicit casts, I would never trust it to do that even if unsigned long long was used. Better thing is assign that to a variable that is definitely 64-bit int, then use it.
>>>
>>> On Wed, Jan 30, 2013 at 1:32 AM, Milen Rangelov <gat3way@...il.com> wrote:
>>> I think you should declare an uint64, do the calculations, then pass it to print_hex. Also long is not long long, result would likely not be what you expected.
>>>
>>>
>>> On Wed, Jan 30, 2013 at 12:42 AM, magnum <john.magnum@...hmail.com> wrote:
>>> On 29 Jan, 2013, at 23:15 , magnum <john.magnum@...hmail.com> wrote:
>>>> On 29 Jan, 2013, at 22:37 , magnum <john.magnum@...hmail.com> wrote:
>>>> On 29 Jan, 2013, at 2:04 , Solar Designer <solar@...nwall.com> wrote:
>>>>>> On Tue, Jan 29, 2013 at 01:28:57AM +0400, Solar Designer wrote:
>>>>>> I chose to post a different patch in response to Jeremiah's message on
>>>>>> john-users. That's because there's also a printf format string that
>>>>>> uses "%d", and cno and data_size are also of type int in dmg_fmt_plug.c.
>>>>>>
>>>>>> The patch that I posted should be good for up to 8 TB.
>>>>>
>>>>
>>>> I sent a patch to Jeremiah for trying out. It just adds this (to be used with Solar's patch as well):
>>>>
>>>> @@ -161,7 +161,7 @@ static void hash_plugin_parse_hash(char *filename)
>>>> printf("*%d*", header2.encrypted_keyblob_size);
>>>> print_hex(header2.encrypted_keyblob, header2.encrypted_keyblob_size);
>>>> printf("*%d*%d*", cno, data_size);
>>>> - print_hex(chunk + cno * 4096, data_size);
>>>> + print_hex(chunk + (long)cno * 4096, data_size);
>>>> printf("*1*");
>>>> print_hex(chunk, 4096);
>>>> printf("\n");
>>>>
>>>> This works for me, except the output is mostly zeros and John can't crack it. Maybe that is the other bug mentioned that I see now?
>>>
>>> Unfortunately he got the same mostly zero output with the real file. I give up here.
>>>
>>> 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.
