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 18:17:09 +0300
From: Solar Designer <>
Subject: hashcat rules (in)compatibility (was: Judy array)

On Mon, Sep 21, 2015 at 05:43:04PM +0300, Solar Designer wrote:
> 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.

hashcat wanted to be JtR compatible:

but its documentation for 'x' describes this as a "delete" rather than
an "extract" command:

"Delete range 	 xNM 	 Deletes M characters, starting at position N
x02 	 p@...0rd 	 ssW0rd"

That's unfortunate.

BTW, with hindsight I regret I defined the 'D' command the way I did.
'D' wasn't in Crack, and I had the freedom to define it to delete range
rather than one char.  This would also happen to prevent hashcat's
misunderstanding, because it would (hopefully) be clear that there
aren't two commands that do exactly the same thing.  Or I could have
used the 'X' character for that (in fact, I vaguely recall thinking of
that use before putting it to use for another purpose), which wasn't
introduced until 2009-2010, (hopefully) still in time for hashcat.

Now we might want to introduce a new command character to do what
hashcat's 'x' does.  What do we call it?  'h' or 'H' for hashcat?  And
what would the other mean, then?  (It's good to use lower/uppercase
command chars for something related or opposed.)  Maybe 'e' for erase
(hashcat already defines 'E' for something else)?  Any better idea?

There are also compatibility issues with 'L', 'R' (different syntax and
semantics: keyboard vs. bitwise shifts), '+' (we define it only for
single crack mode, though), and '*' (vs. Crack's use of this command).

> 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.


Powered by blists - more mailing lists

Your e-mail address:

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