Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 9 Nov 2016 10:34:38 -0600
From: jfoug <>
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, 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.


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.