Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 29 Aug 2011 00:40:18 +0400
From: Solar Designer <>
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:

.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.:

File = $JOHN/digits.chr
MinLen = 1
MaxLen = 8
CharCount = 10

.include [Incremental:Digits]
MaxLen = 7

.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.



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.