[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3b75259bfc0300664f368ac4bf8a32ed@smtp.hushmail.com>
Date: Wed, 30 Jan 2013 03:48:11 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Re: dmg2john
I just committed an unrelated bugfix to the dmg formats, just so you know and don't get confused. That bug would have led to false positives or segfaults if it surfaced, but not false negatives.
magnum
On 30 Jan, 2013, at 3:12 , magnum <john.magnum@...hmail.com> wrote:
> 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
>
> <dmg2john.c.gz>
>
>
>
> 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.
