Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20191103125620.GA19351@openwall.com>
Date: Sun, 3 Nov 2019 13:56:20 +0100
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: walkthrough for Crack The Password contest

Aleksey,

Thank you for this writeup, which contains examples useful outside of
contests as well.

On Tue, Oct 29, 2019 at 06:46:02PM +0300, Aleksey Cherepanov wrote:
> John's default length limit is 27 for NT format. Ad-hoc dynamic format
> --format='dynamic=md4(utf16($p))' may be used to extend it.

I think this is useful to a lot of people, but it's obscure.  We should
perhaps define e.g. nt-long as an alias for this format, so it'd come up
in the formats list, in default "--test" benchmarks, etc.  And have it
listed right after the main nt format.

As expected, this dynamic format is slower than the specialized one:

[solar@...l run]$ ./john -test -form=nt
Benchmarking: NT [MD4 256/256 AVX2 8x3]... DONE
Raw:	90110K c/s real, 90110K c/s virtual

[solar@...l run]$ ./john -test -form='dynamic=md4(utf16($p))'
Benchmarking: dynamic=md4(utf16($p)) [256/256 AVX2 8x3]... DONE
Raw:	23056K c/s real, 23056K c/s virtual

This is on one core in i7-4770K.

> A bare hash with 40-hex was provided.

When you write it like that, I'm reminded of the 40Hex e-zine:

http://www.textfiles.com/magazines/40HEX/
https://www.wired.com/1995/02/viruses/

> $ python -c '
> import string, sys;
> print ".include <john.conf>\n[List.Rules:rep]";
> [ sys.stdout.write("s{0}\\x{1:02x}\ns{2}\\x{1:02x}\n".format(
>     c, ord(c) - ord("a") + 1, c.upper()))
>   for c in string.lowercase ]
> ' > rep.conf
> 
> $ head -n 5 rep.conf
> .include <john.conf>
> [List.Rules:rep]
> sa\x01
> sA\x01
> sb\x02

I think we need a pre-defined ruleset like that, called Controlize.
And we need to compact these rules using the preprocessor, e.g.:

[List.Rules:Controlize]
s[aAbB]\p\r[\x01\x01\x02\x02] Q

Perhaps listing more characters per line.  I was just lazy here.

We should also consider rules for other ways to "controlize" - e.g., of
only some (not all) instances of a character, or of multiple different
characters at once.  Maybe we should add some rule commands into JtR
itself to do this efficiently.  This is similar to case toggling.

Maybe we should skip producing '\n' for now, as it would break the
john.pot file format until we finally implement hex-encoding there.

> $ (printf '.include <john.conf>\n[List.Rules:eff]\n';
>    perl -C0 -lpe 's/^/Az"/; s/$/"/' < eff_words.txt
> ) > eff.conf
> 
> $ head -n 4 eff.conf
> .include <john.conf>
> [List.Rules:eff]
> Az"aardvark"
> Az"abandoned"

Maybe we should add a pre-defined ruleset produced with a script from
our default password.lst (and updated along with it), appending or
prepending each one of those words, also with or without a space, e.g.:

[List.Rules:Password]
\r[:$:^][ ] A\p\r[zz00]"password"

and so on for the full password.lst.  Maybe we should also add length
checks to ensure the added string isn't fully beyond the format's
maximum length (when appending) and doesn't fully push out the original
word beyond the format's maximum length (when prepending).

And we should include that ruleset from [List.Rules:All], which
currently produces over 6 million candidates from one input word, while
[List.Rules:Jumbo] produces about 5000.  The addition of another
~3500 is definitely acceptable for "All", but perhaps not for "Jumbo".

Alexander

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.