[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sun, 26 Sep 2010 14:46:10 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: KoreLogic rules
Minga, all -
I finally got around to reviewing/reworking the KoreLogic rules.
I now have a new test ruleset that is based off KoreLogic's, yet I
mostly reworked it to make better use of the preprocessor (the file
became 3 times smaller, and the number of lines 10 times smaller), to
produce fewer duplicates (especially with length-limited and/or
case-insensitive hash types), to generate some kinds of candidate
passwords that were inadvertently missed by KoreLogic (because of
implementation bugs in the original rules.txt), and to avoid generating
candidate passwords that were likely being generated unintentionally
(again, because of bugs). This is
korelogic-rules-20100801-reworked-2.txt available on this new wiki page:
http://openwall.info/wiki/john/rules
There are also three other files: the original KoreLogic's rules.txt
(redistributed as korelogic-rules-20100801.txt), a revision of it with
all sections combined into one (korelogic-rules-20100801-all-1.txt), and
a revision of my reworked rules similarly combined into one section
(korelogic-rules-20100801-reworked-all-2.txt).
In their present form, I doubt that these rulesets are great for actual
use. At the very least, the combined ones are incorrect in that they
include the different kinds of rules in highly non-optimal order, and in
that the rules were meant for use with wordlists of different size.
One assumption I made when adding constraints to the rules was that if
we have a certain complicated rule, we also have all obviously-simpler
rules - e.g., if we have a rule that appends two characters of a certain
kind, then we also have a rule (somewhere else) that appends just one
character of that kind. Unfortunately, this natural assumption appears
to be wrong for KoreLogic's rules on their own. Perhaps the rules
were/are meant for use along with or after other/simpler ones.
Speaking of the minor likely-bugs I found, there were two typos in
KoreLogicRulesAppendMonthDay, erroneous handling of the letter "L" (on
as many as 175 lines, it seems) and missed "sl!" substitution in
KoreLogicRulesL33t, missing "*" in KoreLogicRulesReplaceSpecial2Special,
missing double-quote character in many substitutions, "s--" (a no-op) in
KoreLogicRulesReplaceSpecial2Special, not replacing of the backslash
character in KoreLogicRulesReplaceSpecial2Special, and
KoreLogicRulesReplaceLetters truncated after "/zszr". These are fixed
in -reworked-2, and comments on many of them are added.
As a test, I ran korelogic-rules-20100801-all-1.txt vs.
korelogic-rules-20100801-reworked-all-2.txt with a wordlist containing
just one word "defcon" against the contest NTLM hashes. The former
cracked 449, the latter cracked 448. The only password not cracked by
my reworked ruleset was "defcon" itself - which shouldn't have passed
through a ruleset like this as-is.
Overall, I think many of these reworked rules may be considered when
building new rulesets to include with JtR, and it is easier for me to
look at 10x fewer lines. (I understand that it could be the other way
around for someone not that familiar with the preprocessor.)
The individual sections may in fact be reasonable to use now along with
appropriately-sized wordlists.
I'd appreciate any comments.
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.
