Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 20 Jan 2012 03:49:35 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Jumbo patch breaks "--users=<uid>" for pwdump [was: john-users]

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.

The logic is that if field 1 (normally the hash) is between 1 and 7
characters, and field 3 and/or 4 are 32 characters, we assume pwdump.

> (and other formats that support non-standard input files, likely 
> NETNTLM and the likes).

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

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 :-)

magnum

View attachment "loader.diff" of type "text/x-patch" (2073 bytes)

Powered by blists - more mailing lists

Your e-mail address:

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