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.