Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 30 Jan 2013 02:12:42 +0200
From: Milen Rangelov <gat3way@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: dmg2john

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
>>>
>>
>>
>
>

Content of type "text/html" skipped

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ