[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F18D63F.3070405@hushmail.com>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
