Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20101009003359.GA19478@openwall.com>
Date: Sat, 9 Oct 2010 04:33:59 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: #include in config files and other related enhancements (was: KoreLogic rules)

On Sat, Oct 09, 2010 at 01:15:34AM +0200, magnum wrote:
> This reminds me of an enhancement request I thought of: Either allow 
> multiple --rules arguments, or have some sort of #include statements in 
> rules. Actually both have pros and cons depending on situation. If I had 
> that include statement, I'd make a superset including most every weird 
> rule I have (like all KoreLogic rules) for very fast ciphers or very 
> small wordlists, and smaller supersets for use with slow ciphers.

Yes, this was on my to-do for years, and it is becoming higher priority
now that we actually have many rulesets to include with JtR.

For the #include statements, I have not yet decided whether they should
apply to config file sections and/or to entire files (maybe both kinds
should be supported).

Similarly, the use of multiple wordlists at once needs to be supported
(both sequential and mixed).

Then, since in practice it makes sense to use different rulesets with
different wordlist sets, perhaps there should be a new section listing
these combinations.  In fact, maybe it should list invocations of any
cracking modes, not just wordlist mode, which would let it replace the
current hard-coded batch mode.  This could be further enhanced to be
able to invoke multiple modes at once (e.g., have initial substrings
produced by "incremental" mode, but then apply wordlist rules to them).

Moreover, there could be multiple batch sections like this, and one of
them could #include or invoke another (where "invocation" would differ
in that it could be combined with yet another mode).  The top-level
batch section would be specified via the command-line (and there should
be some default).

With the multi-mode invocations I have imagined above, a difficulty is
in changes that will be required to the .rec file format.  Yet this is
quite possible.

Thanks,

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.