[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <12f1d9fe919f9c0e9592b6660905d8cb@smtp.hushmail.com>
Date: Mon, 13 Aug 2012 23:41:41 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Serious bug in -fixes and all other branches
On 2012-08-13 22:49, jfoug wrote:
> From: magnum
>> We have a serious loader problem. It often segfaults while reading
>> a pot file containing other formats than what we are loading. This
>> is in all branches, including -fixes :(
>>
> For 'fixes' version, lets simply roll back these changes to loader.
> The side effects, are that any found password of dynamic type, will
> not be removed from JtR on its next run, if the .pot line for that
> hash had a $HEX$ added. But this will remove the other 'bad' side
> effects of this change.
I now rolled it back (*only* the ldr_load_pot_line() changes, nothing
else, even in loader.c) in all branches.
> This problem is more difficult than it appears, since the INPUT file
> may have $HEX$ values, and thus, within loader, those should not be
> undone. I am at a quandary about this issue. It may be that I have
> to modify the part of dynamic that makes the initial change, right
> before storing the .pot line, and not use $HEX$, but use some
> 'internal' value, that is only set prior to the .pot writing, and
> THEN if we detect that string, we undo it at split time.
I would think all this can be solved with prepare() - although maybe not
with exactly the same behavior as you had here. For instance, even if NT
reads a pwdump file, it stores hashes in the pot file in the canonical
way. When you --show same pwdump file, it works fine (but is not shown
in pwdump format). I would think a similar scheme could apply here, but
I understand there may be caveats.
> For the loader call, I probably need to ONLY perform the split logic,
> if the format is a FMT_DYNAMIC type, otherwise, simply revert to the
> original behavior, and return. For dynamic, we will call split to
> 'possibly' chop back the hex. The 'other' option, is to make valid
> more complex, and slower (it already is the slowest valid() function
> by far).
OTOH, loading speed is not helped by calling split() for every single
hash in a 3 GB pot file ;-)
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.
