[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 9 Oct 2010 00:03:59 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Rule to replace strings
I've just addressed Matt's actual question in another posting, so this
one is merely to clarify why the line proposed by Rich did not work the
way Matt expected it to:
On Fri, Oct 08, 2010 at 01:43:30PM -0500, Charles Weir wrote:
> > /[2009] s[2009][2010]
> > something like that isn't it?
>
> Hey thanks Rich but the rules preprocessor treats those as individual
> characters. Aka I ran that on the word "test2009" and it output the
> following guesses:
>
> test2009
> test0009
> test1009
> test2229
> test2009
> test2119
> test2002
> test2000
> test2001
>
> The weird thing was it didn't create nearly as many guesses as I
> thought it would. Aka I would expect test0000 to show up.
Rich's proposed ruleset line:
/[2009] s[2009][2010]
contains just one "s" command. So it can't possibly turn "2009" into
"0000", which would require two different "s" commands at once (one for
"2" and the other for "9") or totally different commands. For the same
reason, there's no "2010" in the output.
Specifically, the line expands into 27 rules, as seen in the log:
0:00:00:00 - Rule #1: '/2 s22' accepted as '/2s22'
0:00:00:00 - Rule #2: '/2 s20' accepted as '/2s20'
0:00:00:00 - Rule #3: '/2 s21' accepted as '/2s21'
0:00:00:00 - Rule #4: '/2 s02' accepted as '/2s02'
0:00:00:00 - Rule #5: '/2 s00' accepted as '/2s00'
0:00:00:00 - Rule #6: '/2 s01' accepted as '/2s01'
0:00:00:00 - Rule #7: '/2 s92' accepted as '/2s92'
0:00:00:00 - Rule #8: '/2 s90' accepted as '/2s90'
0:00:00:00 - Rule #9: '/2 s91' accepted as '/2s91'
0:00:00:00 - Rule #10: '/0 s22' accepted as '/0s22'
0:00:00:00 - Rule #11: '/0 s20' accepted as '/0s20'
0:00:00:00 - Rule #12: '/0 s21' accepted as '/0s21'
0:00:00:00 - Rule #13: '/0 s02' accepted as '/0s02'
0:00:00:00 - Rule #14: '/0 s00' accepted as '/0s00'
0:00:00:00 - Rule #15: '/0 s01' accepted as '/0s01'
0:00:00:00 - Rule #16: '/0 s92' accepted as '/0s92'
0:00:00:00 - Rule #17: '/0 s90' accepted as '/0s90'
0:00:00:00 - Rule #18: '/0 s91' accepted as '/0s91'
0:00:00:00 - Rule #19: '/9 s22' accepted as '/9s22'
0:00:00:00 - Rule #20: '/9 s20' accepted as '/9s20'
0:00:00:00 - Rule #21: '/9 s21' accepted as '/9s21'
0:00:00:00 - Rule #22: '/9 s02' accepted as '/9s02'
0:00:00:00 - Rule #23: '/9 s00' accepted as '/9s00'
0:00:00:00 - Rule #24: '/9 s01' accepted as '/9s01'
0:00:00:00 - Rule #25: '/9 s92' accepted as '/9s92'
0:00:00:00 - Rule #26: '/9 s90' accepted as '/9s90'
0:00:00:00 - Rule #27: '/9 s91' accepted as '/9s91'
The preprocessor is smart enough to omit the duplicate rules that could
result from having two 0's in 2009 and 2010, however it is not smart
enough to detect other redundancies (in fact, it knows nothing about the
rule commands). This has nothing to do with not producing "test0000",
though - it would not be produced regardless of preprocessor optimizations
or lack thereof. The line simply does not specify that translation.
Here's a curious alternative along the lines of Matt's original question
and Rich's line:
/?d Dp =p?d Dp =p?d Dp =p?d Dp Ap"[0-9][0-9][0-9][0-9]"
For "test2009", this one produces 10000 candidate passwords - from
"test0000" to "test9999" - and it would also "catch" (and replace)
4-digit sequences in the middle of input "words".
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.
