Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 21 Sep 2015 17:43:04 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Judy array

Fred -

On Mon, Sep 21, 2015 at 05:07:51PM +0300, Solar Designer wrote:
> There are 947 hashes that MDXfind cracked and JtR did not.  The
> corresponding passwords are of at least 7 characters long (none are
> shorter than 7).  No other obvious pattern yet.  I've tested a couple
> against john --stdout for the same wordlist and rules, and they are not
> in there, so at least for these two it's some discrepancy in the
> candidates stream rather than in the hashing or comparisons.  One such
> password is noimage.  A similar line in the wordlist is geoimagen,
> although there are several other (not so) similar ones.  A rotate rule
> might be producing noimage on MDXfind, but somehow not on JtR.

I figured this out.  You implement the 'x' command incorrectly.  You
implement it as a "delete" command, but it is an "extract" command.

Maybe hashcat has the bug too, given that this rule from best64:

x02 { { { { { {

is quite meaningless when 'x' is implemented to mean what it does in
Crack and John.  If so, we have a major compatibility problem between
hashcat and JtR rules, worse than what we previously thought we had.

I call it a bug in MDXfind and likely hashcat because 'x' was first
defined in Crack in early 1990s, and has been in JtR since 1996.  It may
be worth double-checking JtR behavior against Crack's now, but even if
they differ (I hope not) JtR with this rule command has been around for
long enough that this isn't something we'd change now.  What we may do,
though, is add a hashcat compatibility flag (perhaps to be specified
before a rule, or at the start of a ruleset).  I guess hashcat may do
something similar for JtR compatibility, or just fix the bug if they
feel they're still young enough.

Can you test hashcat for this issue, please?

There are no other discrepancies.  With the above rule replaced with:

\[ \[ { { { { { {

I get the same 1710650 hashes cracked (no more, no less) that you did
(but you're misreporting many cracked passwords).

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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