[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 29 Aug 2011 00:40:18 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: #include "john.conf2" (a wish list item)
Jim, Aleksey, all -
Here's my opinion on what we need (and what we don't need), listed below
in arbitrary order:
1. I currently prefer the following syntax:
.include "file"
.include [section]
This will result in errors in most contexts if parsed by an older
version of JtR. I think we _want_ this behavior - that is, prefer
explicit error messages over having the directives silently ignored.
Unfortunately, the error messages won't be very specific - obviously,
older versions of JtR won't know that these are directives.
Why the leading dot? - to introduce a check for "unknown directive".
That way, when/if in a distant future another version of JtR introduces
more directives - e.g., .if and .endif - our next version will complain
about those in a specific way.
Also, it will be easy to say in doc/RULES that rules that happen to
start with a dot at the very start of a line need that dot escaped.
Luckily, '.' is not a valid rule command currently, so this does not
affect any existing rules.
Why a dot and not another character? - the dot is already used in
similar contexts elsewhere, e.g. by assemblers. And it's not in use as
a rule command.
2. Optionally, we may also have:
.include <file>
.include <path/file>
which will be synonymous to:
.include "$JOHN/file"
.include "$JOHN/path/file"
That is, it will use the provided pathname relative to John's home
directory, using the same meaning that $JOHN has e.g. when referencing
.chr files in incremental modes.
3. No special syntax for includes of rules - instead, have includes of
sections. So to include one rule section from another, we can use
something like:
[List.Rules:Wordlist]
.include [List.Rules:Simple]
.include [List.Rules:Complex]
.include [List.Rules:Crazy]
The same syntax will also work e.g. for shared portions of external mode
definitions - e.g., if two external modes share the same init() or the
same generate().
I think it should work for non-List sections as well, e.g.:
[Incremental:Digits]
File = $JOHN/digits.chr
MinLen = 1
MaxLen = 8
CharCount = 10
[Incremental:Digits1-7]
.include [Incremental:Digits]
MaxLen = 7
[Incremental:Digits8]
.include [Incremental:Digits]
MinLen = 8
4. No rule appends at this level. Instead, as a separate development
task, we may replace the current hard-coded batch mode with configurable
batch modes - and the syntax definition for batch modes may/should
include combining multiple cracking modes at once (not only
sequentially), including mixing two sections of rules as a special case,
but also supporting e.g. incremental mode plus wordlist rules.
I'd appreciate any comments, although at this time I feel pretty
strongly about 1, 2, and 4 above - I am unlikely to implement these
things in a different fashion in the main JtR tree. So if -jumbo does
it differently, it will likely be incompatible with future
implementation in the main tree.
Since 4 involves invasive changes (affecting .rec file format), I think
it might not be a candidate for jumbo (rather, I should work on it for
the main tree), or alternatively jumbo may implement a prototype under a
separate name, without touching the existing hard-coded batch mode yet.
Either way, it's a separate development task from 1, 2, 3.
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.
