[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100307162456.GA10465@openwall.com>
Date: Sun, 7 Mar 2010 19:24:56 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: rules with ":"
On Sun, Mar 07, 2010 at 10:50:45AM +0100, websiteaccess@...il.com wrote:
> :[:cu] A0,[0-9]\0\0, Az,[0-9]\0\0, works fine (able to crack
> password 000john000 )
This looks fine to me. You can improve it for better efficiency with
case-insensitive hash types:
-\r[:cc] \p0[:cu] A0"[0-9]\0\0" Az"[0-9]\0\0"
This will reject 200 out of the 300 rules if the target hash type uses
case-insensitive passwords. You can improve it even further to also
reject some input words that would result in effective duplicates with
length-limited hashes:
-\r[:cc] \p0[:cu] A0"[0-9]\0\0" Az"000"
-\r[:cc] \p0[:cu] A0"[0-9]\0\0" <* Az"[1-9]\0\0"
Both of these changes would be beneficial when cracking LM hashes.
The "\r" and "\p0" flags require JtR 1.7.5+.
> but
> [:cu] A0,[0-9]\0\0, Az,[0-9]\0\0, returns me an error
That's because when you start a line with the opening square bracket, it
gets misinterpreted by the config file parser as a new section start.
> and
> :[cu] A0,[0-9]\0\0, Az,[0-9]\0\0, works but don't crack 000john000
Indeed. This one gets expanded into 200 rules of the form:
c A0,000, Az,000,
c A0,000, Az,111,
[...]
c A0,999, Az,999,
u A0,000, Az,000,
[...]
u A0,999, Az,999,
whereas your original line would also include:
: A0,000, Az,000,
: A0,000, Az,111,
[...]
: A0,999, Az,999,
which would be optimized to:
A0,000, Az,000,
A0,000, Az,111,
[...]
A0,999, Az,999,
> in the jtr's doc rules, ":" = try words as they are (my dictionay is
> all lowercase), if I'm right
> the following rule ":[:cu] A0,[0-9]\0\0, Az,[0-9]\0\0," do 2 times the
> same works about lower case.
No, it does not, and it's not exactly a rule - it is a ruleset line
that contains rule preprocessor expressions, and it gets expanded into
300 rules. It is important for you to start distinguishing rules from
preprocessor expressions as this is what appears to be confusing you.
When trying to understand specific preprocessor expressions, I suggest
that you check what they actually expand into. You can find this out
from the .log file. For example, with this in john.conf:
[List.Rules:Wordlist]
-\r[:cc] \p0[:cu] A0"[0-9]\0\0" Az"000"
-\r[:cc] \p0[:cu] A0"[0-9]\0\0" <* Az"[1-9]\0\0"
a test run against LM hashes produces the following in john.log:
0:00:00:00 - 300 preprocessed word mangling rules
0:00:00:00 - Rule #1: '-: : A0"000" Az"000"' accepted as 'A0"000"Az"000"'
0:00:00:00 - Rule #2: '-: : A0"111" Az"000"' accepted as 'A0"111"Az"000"'
0:00:00:00 - Rule #3: '-: : A0"222" Az"000"' accepted as 'A0"222"Az"000"'
[...]
0:00:00:00 - Rule #9: '-: : A0"888" Az"000"' accepted as 'A0"888"Az"000"'
0:00:00:00 - Rule #10: '-: : A0"999" Az"000"' accepted as 'A0"999"Az"000"'
0:00:00:00 - Rule #11: '-c c A0"000" Az"000"' rejected
0:00:00:00 - Rule #12: '-c c A0"111" Az"000"' rejected
[...]
0:00:00:00 - Rule #29: '-c u A0"888" Az"000"' rejected
0:00:00:00 - Rule #30: '-c u A0"999" Az"000"' rejected
0:00:00:00 - Rule #31: '-: : A0"000" <* Az"111"' accepted as 'A0"000"<*Az"111"'
0:00:00:00 - Rule #32: '-: : A0"000" <* Az"222"' accepted as 'A0"000"<*Az"222"'
[...]
0:00:00:00 - Rule #39: '-: : A0"000" <* Az"999"' accepted as 'A0"000"<*Az"999"'
0:00:00:00 - Rule #40: '-: : A0"111" <* Az"111"' accepted as 'A0"111"<*Az"111"'
0:00:00:00 - Rule #41: '-: : A0"111" <* Az"222"' accepted as 'A0"111"<*Az"222"'
[...]
0:00:00:00 - Rule #119: '-: : A0"999" <* Az"888"' accepted as 'A0"999"<*Az"888"'
0:00:00:00 - Rule #120: '-: : A0"999" <* Az"999"' accepted as 'A0"999"<*Az"999"'
0:00:00:00 - Rule #121: '-c c A0"000" <* Az"111"' rejected
0:00:00:00 - Rule #122: '-c c A0"000" <* Az"222"' rejected
[...]
0:00:00:00 - Rule #209: '-c c A0"999" <* Az"888"' rejected
0:00:00:00 - Rule #210: '-c c A0"999" <* Az"999"' rejected
0:00:00:00 - Rule #211: '-c u A0"000" <* Az"111"' rejected
0:00:00:00 - Rule #212: '-c u A0"000" <* Az"222"' rejected
[...]
0:00:00:00 - Rule #299: '-c u A0"999" <* Az"888"' rejected
0:00:00:00 - Rule #300: '-c u A0"999" <* Az"999"' rejected
> why :[cu] A0,[0-9]\0\0, Az,[0-9]\0\0, but don't crack
> "000john000"
>
> In my mind :[cu] = ":" try words as is "john" then convert to
> "John" then convert "JOHN"
":[cu]" gets expanded into two rules (or into two kinds of rules if
there are other preprocessor directives and/or rule commands on the same
line) - ":c" and ":u". ":c" has two commands - the first command is
"don't change the word", the other is "capitalize the word". Indeed,
this rule is the same as "c". Ditto for ":u", which is the same as "u".
Note that the expansion of ":[cu]" does not include a ":" rule. This
would only be the case if you included a colon inside the square
brackets - e.g., "[:cu]" gets expanded into three rules, not two, and
the three are - ":", "c", and "u", respectively. If you also include a
colon before the opening square bracket (such as for the technical
reason mentioned above) - that is, specify ":[:cu]" - then it will get
expanded into "::", ":c", and ":u", which is effectively the same as
":", "c", "u".
Your problem appears to be that you do not fully distinguish the
following three things:
1. Preprocessor expressions (which get expanded into multiple rules).
2. Rules (which include multiple commands).
3. Rule commands (which are processed sequentially for each rule).
Next time you try to understand how a ruleset line works, please try to
determine whether it's a preprocessor expression or a rule. In the
former case, how many rules the expression expands into and what they
are. Once you have the rule(s), please try to identify their commands.
Maybe this rigorous approach will help.
On top of the three categories above, there's a fourth one:
4. Rule reject flags.
Can you identify those in the examples I provided? When do they come
into play? OK, I'll answer the latter: rule reject flags apply to
entire rules (#2 on the list above), so they come into play after the
preprocessor expansion, but before a rule is processed any further.
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.
