[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 9 Nov 2016 10:34:38 -0600
From: jfoug <jfoug@...nwall.net>
To: john-users@...ts.openwall.com
Subject: Re: alter default rules or filter, best way to focus on
proper candidates?
On 11/9/2016 10:21 AM, jfoug wrote:
On 11/9/2016 10:11 AM, p+password@...atpro.net wrote:
> Thank you Jim,
>
> If I understand correctly, this kind of exclusion let the rule create the candidate, and just drop it if it does not match the exclusion parameter.
> If I take a look at lines +517 of john.conf (bleeding-jumbo at 20161106):
No, if you put the rejects first, then the rules engine first does the
rejection logic on the original word. If that word fails, then the rules
engine does no more work at all, it simply discards that word. THAT is
why you should put rejection items as early as possible. NOTE, there
can be times when you want to do rejections later (and sometimes you
HAVE to reject later, such as the Q rule).
> # Weird order, eh? Can't do anything about it, the order is based on the
> # number of successful cracks...
This comment is not about the rejection rule 'primitive' commands in the
rules, BUT in what the rules do. The rule engine rules all words
against rule #1 in the list before moving on to running all words
against rule #2, then #3, ... until all rules have been completed. This
is what I would call a 'depth-first'. I would like to add a mode to
john jumbo that would do a 'breadth-first' rules mode (where each word
would be run through the entire set of rules, then the next word would
run through the full set of rules, etc). There are benefits to both
methods, but john only does the first mode.
As for the other items you are trying to do, simply write rules, and use
--stdin and --stdout (with echo "test word" | ./john ..... to test that
the rule does what you expect) to build and improve your rules. The
more you work with them, the better you will be with writing them
better. Note, there are often multiple ways to write the same rule, and
often times you can use fewer rule primitives to do the same thing
(optimizations). That along with order (especially when rejecting),
can make rules run with less overhead (i.e. faster). For slow formats
this is not that big of a deal. The % of runtime in the rules engine is
negligible, but for fast formats, it can make significant improvements
in overall throughput. Sometimes you will find that cutting a wordlist
up with grep into multiple input files also improves overall throughput
(but at the expense of more files and more disk space used, and at the
time taken to create these sub-wordlist files). But if you are
already at the level of writing your own rules, then you are certainly
moving up into more of the advanced usage status of john users.
Jim.
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.
