Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

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