[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
```Date: Tue, 18 Dec 2012 08:34:53 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: new user help with list vs. incremental modes

Hi,

On Mon, Dec 17, 2012 at 12:54:00PM -0600, Raleigh Rinehart wrote:
> My question is this:  how do I best configure JtR to run for a known
> going to be of the form 3-6 alpha-numerical characters followed by 3-8
> digits?  I've gone through the documents, mailing lists and other resources
> but am still confused on the best approach attack to this.

You need to start by doing some math to determine which of these
sub-patterns are realistic for you to search exhaustively.  Then only
consider running "dumb" attacks on those.  For the rest, only consider
"smarter" attacks, if any.

For example, if by "alpha-numerical characters" you mean mixed-case
letters and digits - 62 different characters total - then at length 6
followed by 8 digits (14 characters total) this gives you a keyspace of:

62^6*10^8 = 5680023558400000000

At 100M c/s (about the best you can get on one high-end GPU at raw
SHA-512 currently), this will take:

62^6*10^8/(100*10^6*86400*365) = 1801 years

So clearly you need to either omit this sub-pattern entirely or leave it
for smarter attacks that you'd try later.

On the other hand, 3 alphanums followed 8 digits (11 total) is realistic:

62^3*10^8/(100*10^6*86400) = 3 days

(or more since your actual speed is likely to be somewhat less than 100M)

6 alphanums followed by 3 digits (9 total) is also realistic:

62^6*10^3/(100*10^6*86400) = 7 days

As to how to tell JtR to do this, your approach with rules and
incremental is good for relatively quick sub-patterns.

Another approach is by customizing the KnownForce external mode, but
it'll be slower.

> Here is what I've done so far.
>
> I tried creating a "digits_list.txt" file by running:
>   john --incremental=digits --stdout=8 > digits_list.txt
>
> Then I created a new List rule like this:
>     [List.Rules:Foo]
>     A0"[0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z]"
>     A0"[0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z]"
>     A0"[0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z]"
>
> A0"[0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z]"

These are 3, 5, 6, and 7 alphanums.  Didn't you say the range was 3 to 6?

Anyhow, JtR performs preprocessor expansion on ruleset lines at startup,
to validate the syntax of the resulting rules.  (Yes, this functionality
was not meant to be used like you use it above.)  So once you have more
than roughly a million of rules (after preprocessor expansion), startup
becomes slow.  With your rules above, it can take forever to even start
cracking.  Yet if you limit this to just 3 and 4 alphanums, the startup
time will be a few seconds (62^3+62^4 is 15 million, which is acceptable).
You can try 5 too.  6 is too much.  7 is more than you wanted.

> When I run that with:
>     ./john --format=raw-sha512-cuda --device=1 --session:foo
> --wordlist=digits_list.txt -rules:Foo crackme.txt
>  JtR just seems to do nothing.  I let it run for a couple of hours but it
> never seemed to do anything.
> Running the status command returns this:
>     ./john --status=foo
>     fopen: foo.rec: No such file or directory
>
> And I don't see any log files get created either (i.e. foo.log)
>
> I am guessing it is because the digits_list.txt is too big (~950meg) or the
> way I've tried setting up the mangling is too inefficient.

Your digits_list.txt file size is not a problem, but the number of
expanded rules is.

Once you trim down the ruleset and get this working, I also recommend