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.