[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120713043816.GA22125@openwall.com>
Date: Fri, 13 Jul 2012 08:38:16 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: XSHA_fmt_plug.c should support hashes in lower-case
On Fri, Jul 13, 2012 at 12:23:42AM -0400, jfoug@....net wrote:
>
> ---- Solar Designer <solar@...nwall.com> wrote:
>
> > If in some other formats you support hex-encoded hashes without the
> > all-lowercase or all-uppercase restriction and you don't have split()
> > unify the case or/and you don't have the flag set, that's a bug, which
> > may result in misbehavior of the loader and especially of --show when
> > differently-looking instances of the same hash are present.
>
> With the above description of the how/why of the FMT_SPLIT_UNIFIES_CASE flag (and processing within split), it becomes obvious that the dynamic format (and likely all of the 'thin' formats) suffer from this bug.
>
> However, (and this is WHY the prepare function was created), there is no way within the existing JtR structure to fix this problem. That is due to the dynamic format behaving like an object oriented polymorphic class, however, the split method does not pass in a this pointer.
In the core tree copy that I am currently hacking on (this is
unpublished code at this time), it does:
char *(*split)(char *ciphertext, int index, struct fmt_main *self);
> Can the split function modify the buffer that is passed in, or should it copy to it's own static buffer?
I was assuming that split() does not modify its input string, but I
don't know if the current code (split() callers) actually depends on
this assumption or not.
Alexander
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.
