[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20110815093226.GA17657@eee>
Date: Mon, 15 Aug 2011 13:32:27 +0400
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: john-users@...ts.openwall.com
Subject: extensive mutations of one word; rules, external mode (was Re:
[john-contest] What I did and learned.)
Frank, all,
I am sorry for so later reply.
I moved this mail from john-contest to john-users because discussion
is about general John's usage.
On Mon, Aug 08, 2011 at 02:50:18PM +0200, Frank Dittrich wrote:
> Am 08.08.2011 13:41, schrieb Aleksey Cherepanov:
> > As addition to "IDE" for rules I think it would be great to have
> > common tips for them and list of common tricks like "-[c:] \p[c:]" and
> > "'*M" (I saw such tricks during contest; I think "'*" could be used
> > instead, could not it?).
>
> Usage of M is only necessary if you want john to "memorize" the current
> contents of he already mangled input, instead of the original input or
> the state prior to the last M in the rule.
>
> Say, max password length is 8, your input word ist
> testtesttest
>
> When you have
> '*lQ
> (l: lower case, Q to reject the word unless it has been changed by
> mangling rules)
> john would not reject testtest.
>
> But if you used
> '*MlQ
> john would reject the word, because the M causes john to memorize
> "testtest" instead of "testtesttest".
> l doesn't change anything, so the Q causes john to reject the word.
>
> Using M at the end of a rule, however, doesn't make sense.
Thanks! Your explanation is very good. Now it is clear for me.
> > I think the best thing would be some book
> > (guide, tutorial or manual, not documentation) to help learn rules
> > writing? Something like "John rules for dummies" because learning with
> > documentation was rather hard (for me).
>
> What if you use doc/RULES together with the commented rules already
> present in john.conf?
This way is good. I would like to do it like: pick rule from
john.conf, try understand what it does using documentation, if it
is not clear then try to run it with modifications, make conclusions,
pick next rule and so on. However it is slow so I would like also to
have book with explanation like one you provided above to short
learning loop. Maybe detailed explanations for all rules from
john.conf would be enough for such manual.
> > Also I would like to know how to generate one mutated word because I did it
> > using wordlist containing all variations of first letter and rule to
> > append other letters.
>
> I was surprized this worked for so many different resulting rules.
>
> You can greate a leetify.pl script which takes stdin and generates all
> possible permutations, one per line.
>
>
> Then you just need a list of mappings per possible input character
> (characters not mentioned will not be permuted, but remain unchanged).
>
> Lets say, for 'e', possible "replacements" will be 'e', 'E', and '3'.
> For 's', you might have 's', 'S', '$', and '5'.
>
> You could even implement one-to-many replacements, e.g., replace 'l'
> with any of the following: 'l','L', '1', '7', "|_", and so on.
>
> Or, you want to be more flexible, and read possible replacements from a
> config file, to make adjustments for different mangling rules needed.
It did not seem to me to be the easiest solution during the contest.
However if it would be written before the contest it could be handy. As
generalization I see external rules engine that provides easier way to
make things like any case for any character, leet any character and
their combinations. It refers back to question about new syntax for
rules.
For instance I have two rules: any case any character (I saw such big
rule in default john.conf) and append 1 alnum 'Az"[a-zA-Z0-9]"'. With
such rules we could cover one mississippi pattern using mississippi
word as input (only that word in wordlist). However as I
understand to use this rules together we need to append second rule's
text to each string of first rule (am I right?). It does not seem
handy for me. However sometimes rules are very complex so such
combination could not be applied for all rules as is but with some
non-trivial modifications. But on the other hand I see some blocks
that could be combined easily. So may be it would be great to support
such modularity and reusability of rules? Or am I wrong at all?
> For instance I would like to generate 'si' '5i'
> > 's1' '51' so I would write wordlist with 's' and '5' and rule
> > 'Az"[i1]". Could it be done easier?
>
> That would be
> Az"[s5][i1]"
> in this case, of course.
>
> I'm not sure to support such replacements in john.
> The rules are complicated enough already.
> And, in most cases, you just want to replace all occurrences of al
> character, which can be done with the s command (peferably in
> conjunction with /, like this
> /ese3
> or
> /isi[1!]
Ok, I wrote rule Az"[s5][i1]" but I did not have success with it because
for empty wordlist and wordlist with 1 empty line John produces 0
passwords. However if there is 'a' in wordlist John produces 'asi'
'as1' 'a5i' 'a51' as expected. So my question "how to generate entire
word from 'nothing'?" seems to have "it is impossible" as answer. In
practice mississippi and obsessiveness had different rules in relation
1 rules set for 1 word so I think it could be useful at least for
contest however it seems to be rare in real world so to write down one
letter and append others with rule seems to be the most easiest way for me
because I am not sure that substitution rules could be written easier
for one word.
Other approach to have rules to generate multiple words from one
input word when we have several words as input (during the contest
vegas, defcon and others were such words). Rules could do it
well.
> If you really want to generate multiple words per input words, I think
> the --external mode implementation should be enhanced.
> Currently, you can only generate single output word, or reject a word
> (by setting word[0] to 0).
> John would need to be enhanced to support a way of signalling that more
> than one word will be produced. (May be by implementing a function with
> a different name than filter(). what about generate(), which is
> currently only used for external modes that produce a candidate list on
> their own, without any input?
> Or may be a new name for such a function is he better alternative.
However external mode seems to lack ability to generate multiple words
from one word as input. I could imagine something between filter and
generate: one word would be handled while this function modifies it,
when it returns 0 then next word would be picked; like filter but
sticks on each word for modifications.
Regards,
Aleksey Cherepanov
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.
