Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ