[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTik9gpQ6BxXHD4-WD5U0z3uHzWq6qvyE9m3Dw7u6@mail.gmail.com>
Date: Fri, 8 Oct 2010 15:45:26 -0500
From: Minga Minga <mingakore@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: KoreLogic rules
On Sun, Sep 26, 2010 at 5:46 AM, Solar Designer <solar@...nwall.com> wrote:
> 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
Thanks for doing this. I learned tons about rules/preprocessor rules after
you corrected a bunch of stuff. There are so many cool tricks that I didn't
know about. I will try to base any new rules I write off of your rewrites
of my rules.
> 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
I can explain this. For our jobs, we need to crack as many password as
possible. One method of doing this, is to pick a single wordlist, and
then running multiple 'john' processes each with a different --rules:
setting. It is assumed that _all_ of the "KoreLogicRules" will eventually
be run. So if you are running a "complex" rule, it is assumed that you are
also running a "simpler" rule on another machine/core. I have shell scripts
(That I'm about to share) that does all this work for you.
Here is a quick example:
If you notice your client is using the seasons in a majority of their passwords
(likely due to password rotation being every 3 months).
I would do something like this: (excuse the long line and poor use of 'cut')
# for rule in `grep :KoreLogicRules john.conf | cut -d: -f2 | cut
-d\] -f1`; do echo Rule = ${rule}; ./john --rules:${rule} --fo:nt
-w:seasons.dic pwdump.txt; done
This is not _actually_ what I do - but it gives you an idea, and it works.
What I _actually_ do is - put these command lines in a queue - and send that
one queue, one command at a time, to a large list of UNIX systems
(each with multiple 'cores'). Using this method, I can run 48 'john' processes
at once with (theoretically) very little wasted effort (assuming the rules
do not over lap with each other - which some of them do on purpose).
When I use this method, the wordlists and rules are sorted by priority level
and the rules that are more likely to be successful are run before less-likely
rules (such as Append6Num which is a dog and is slow).
What methods do other people do to distributed work across multiple systems?
> 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
Thanks for fixing that stuff.
> 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.
Good stuff. Thanks for mentioning this, because now I can just 'trust' your
edits and not have to go back and confirm everything.
> 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.)
Admittedly, some of the 'reworked' rules are harder to read. But I think its
a good idea to use the preprocessor as much as possible. **EXCEPT** that
I have started using 'hashcat' and 'oclhashcat' a lot recently, and rules that
take advantage of the preprocessor are not understood by it. The way around
this is to use john.log 's output to make "uglier" rules that don't use the
preprocessor.
One question I have (and can answer myself later) is that do these
re-written rules run faster? Or is the main reason for using preprocessor
rules just to limit the amount of lines in john.conf?
P.S. We are pretty certain that "Crack Me If You Can" will be at next
year's DEFCON. Start planning now! ;)
-Rick / Minga
KoreLogic
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.
