[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1FE7079469854AB6A2DF2464A4BF6D62@D9VGLK61>
Date: Sun, 28 Aug 2011 19:31:36 -0500
From: "JimF" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: Re: #include "john.conf2" (a wish list item)
That syntax (#1) is just fine.
I do have a question. The .include "file" loading is done during the loop
that reads in the lines of the .conf file. However, as written (and I
believe it is MUCH easier to do this), I do the .include [section] includes
during initialization, before running the wordlist, or other mode. Do you
believe that to be the right choice of implementation? Along the same line
of question, I used an easy to find init within the rules to load more
rules. I assume there are equivelent locations within the code for inc and
extern, where we could grab other sections, and insert them.
So, for #2, you would list that "file" would find the file in ./file or in
mode -config=/path/conf_file would also search in /path/file (the second
one is only a jumbo command I think). Then <file> 'appends' $JOHN/ the
path. That works fine, and is very easy for a C programmer to grasp.
So, #1, #2, #3 look pretty simple for me to change what I have done right
now, into something that works for them. The only difference between core
john, and jumbo john, may be in the -config=path path also being part of the
searchpath for conf includes. The rest should be a simple port between core
and jumbo, with exact same logic.
I had a look a little at some of the issues with #4. That one is a much
deeper project.
Jim.
From: "Solar Designer" <solar@...nwall.com>
> 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.
