Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 21 Jan 2012 21:48:44 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Jumbo patch breaks "--users=<uid>" for pwdump [was: john-users]

magnum -

On Fri, Jan 20, 2012 at 03:49:35AM +0100, magnum wrote:
> On 01/19/2012 09:23 PM, magnum wrote:
> > On 01/19/2012 08:50 PM, Kurt Grutzmacher wrote:
> >> During testing we noticed a little oddity today between the 
> >> standard John release and the -jumbo release when requesting UID 
> >> vs. Username in the --user option with PWDUMP files. For example:
> > 
> > Thank you for reporting! This was just on oversight, easy fix and 
> > will work correctly in next Jumbo for both LM and NT
> 
> This, and more, is now fixed. I need a second opinion on this patch so I
> did not screw anything up.

What you write here sounds reasonable to me, but I haven't actually
reviewed the changes in context - in fact, I am not 100% familiar with
the previous revision of the code (in jumbo).  I suggest that we just
try this.

> Furthermore, if field 1 is empty and fields 3-5 are of certain lengths,
> we assume l0phtcrack. The NETNTLM formats was not affected, they do not
> have any uid. But there was another problem: when loading l0phtcrack
> style input, we got large hashes in the "gecos" field, resulting in lots
> of crap candidates in single mode. I now mute that

Do we have a sample of "L0phtCrack style input"?  Perhaps we should have
samples of all supported input file formats somewhere on the wiki.

> The rest of the patch is just an attempt to make these strlens faster. I
> change the field split so for trailing empty fields, it returns the
> input's last zero byte instead of a constant "". This let me safely use
> the SPLFLEN(f) macro (pointer subtraction) instead of
> strlen(split_fields[f]). It did not end up that much faster though the
> gain may be larger on a system lacking SSE strlen. Maybe this whole
> thing was just silly :-)

Your SPLFLEN(f) approach looks fine to me.

Thanks,

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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