[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120709202339.O79Q8.468449.imail@eastrmwml213>
Date: Mon, 9 Jul 2012 20:23:39 -0400
From: <jfoug@....net>
To: john-dev@...ts.openwall.com
Cc: magnum <john.magnum@...hmail.com>
Subject: Re: magnum-jumbo and magnum-bleeding (NOT J7), and the
source() function
---- magnum <john.magnum@...hmail.com> wrote:
> On 2012-07-10 00:46, jfoug wrote:
> > I do think the interface for source()
>
> We have seen some need for also passing the index though. This is
> currently worked around in the linkedin format, by looping to mkpc and
> finding out what index we want. Would this be tricky to change?
I do not see how index does us any good. The index is and index to the password being used.. The reason we needed this in LI, is due to the binary pointer within the db_password structure was inadequate. Thus, we went looking through the just cracked values, for a 'matching' binary. But there is no way to know the index, until after the crack was made.
Again, I am pretty sure that the data being given to the source() function is correct, proper, and as minimal in size as I can get it. We did hi-jack the (now unused) source pointer in the db_password and use it for the actual salt pointer if this is a salted hash. That ended up being key to getting salted formats working. The LI format itself, simply added specialized code to it's source() method to be able to properly re-create a native sha1 hash, right after the crypt_all was successful, knowing that JtR would be calling source while the crypt_out buffers were still valid.
Jim.
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.
