[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6c07e3347b5c19795a3c7aa0a75e1b60@smtp.hushmail.com>
Date: Mon, 10 Jun 2013 07:47:01 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: peculiar problem with fmt->params.max_keys_per_crypt in bleeding
On 8 Jun, 2013, at 7:56 , Sayantan Datta <std2048@...il.com> wrote:
> I checked and rechecked my format methods like a thousand times but then I decided to go a little deeper because I am sure the segfault wasn't from any of the internal methods. Although it may be due to some wrong setup in the format. So I checked into cracker.c(and other relevant files) to find out any memory allocations based on max_keys_per_crypt. I modified line number 123 in cracker.c to the following and the problem was gone.
>
> if (db->loaded) {
> size = /*crk_params.max_keys_per_crypt*/2097152 * sizeof(int64);
> memset(crk_timestamps = mem_alloc_tiny(size,sizeof(int64)), -1, size);
>
The above code is core code, except core use mem_alloc() instead of mem_alloc_tiny().
This looks like a core bug to me, or I don't understand the intent. The above is in crk_init() - I hope this is after fmt_init() where we (even in OMP) normally tune max_keys_per_crypt. At what point is set_mask() called? Maybe that function should decrease max_keys_per_crypt accordingly, so that the total max_keys_per_crypt (which was reported at first and used for the allocation in crkinit()) will hold the "running" max_keys_per_crypt that is lower but will be amplified with the set_mask variations. However, I see that format.params are *copied* to crk.params so if you change it after crk_init(), cracker.c will still use the old value. So I can't see how all this can fit together without slight core changes.
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.
