[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFMma9MrJvtLfe6HohmAjMcGQ6KJ0PztR+=M_wGnuteR82Lp8w@mail.gmail.com>
Date: Fri, 16 Nov 2012 15:16:10 -0600
From: Richard Miles <richard.k.miles@...glemail.com>
To: john-users@...ts.openwall.com
Subject: Re: How does incremental mode works?
Hi Solar Designer,
Thanks for your answer, very appreciated.
I began testing the markov and it's nice, but I have a few questions and I
will be very thankful if you could answer.
1) Is there a command-line parameter to replace the default path of
$JOHN/markov.stats?
2) How big should be a wordlist to generate a stats file? I mean, the
bigger is not always the best, right? Or too short will be bad as well,
right? Does the size of the generated stats file influence on the attack's
time?
3) What is the proper kind of wordlist that I should use to generate a
stats file? A default one such as passwords.lst? Rockyou leak? PHPbb leak?
All of them together?
Thanks a lot.
Best regards.
On Tue, Nov 13, 2012 at 10:17 PM, Solar Designer <solar@...nwall.com> wrote:
> On Tue, Nov 13, 2012 at 07:44:33AM -0600, Richard Miles wrote:
> > These links helped me a lot. It's very interesting, suppose that I have a
> > custom list of words already with some manipulation for a custom target,
> is
> > there anything that I may do to use it with jTr that will give me better
> > results in comparison with default incremental mode? Examples are
> welcome.
>
> Yes, although the standard way of doing it is through cracked passwords
> (real john.pot) rather than a customized wordlist (fake john.pot). One
> of the examples in doc/EXAMPLES is on how to reuse statistics from
> cracked passwords for a new .chr file. You may try the same with a fake
> john.pot produced from a wordlist, too.
>
> Unless you have many cracked passwords from your target already (at
> least thousands), you'll probably want to use the standard .chr files as
> well, though - and yes, this means overlap.
>
> > I was reading this thread and I found this link (
> > https://twitter.com/hashcat/status/239636316499869696/photo/1/large), do
> > you know where is jTr in comparison in this chart?
>
> Like I said in the other reply, no. I'd expect JtR's incremental and
> Markov mode lines to be somewhere near the BF++ line, but we have not
> performed such a comparison.
>
> > Also, I found this nice project (http://thepasswordproject.com/passpal),
> is
> > there a way to "integrate" passpal to create more robust rules based on
> my
> > targeted wordlist already manipulated to generate more strong candidates
> > for jTr in incremental mode or similar?
>
> Again like I said in the other reply, optimizing wordlist rulesets is
> also a topic that we'll soon release more info on. The rulesfinder tool
> is already public:
>
> https://github.com/bartavelle/rulesfinder
>
> This is not easy to use.
>
> > My main concern is not run two different instances of jTr to test
> basically
> > the same thing, so I would like to try avoid as much as possible repeat
> > candidate passwords, however, since the output wordlist may be huge the
> > cost to do sort and uniq may be too unacceptable.
>
> You have to strike a balance between the cost of avoiding duplicates
> and the cost of testing them. For slow hashes, you'll want to avoid
> duplicates. For fast hashes, you'll have to let some duplicates be
> tested along with the unique candidate passwords.
>
> When you're attacking slow and salted hashes, and the number of
> different salts is large, you won't test all that many candidate
> passwords - so you'll have to limit the number of candidate passwords
> generated by each of your incremental and wordlist with rules runs, and
> you may in fact pass their combined output through "unique -mem=25".
>
> Yes, you'll generally prefer to use JtR's "unique" program rather than
> "sort -u". You don't want to sort the candidate passwords
> alphabetically, because they had already been ordered for decreasing
> estimated probability of each being one of the actual passwords.
> You merely want to eliminate duplicates.
>
> > This guy called atomu looks very brilliant, but he also looks very
> > arrogant. Anyway, I impressed by what he claimed and the results. One
> thing
> > that called my attention is that appear to be agreed between this guy and
> > solar d. that their mask filters are more efficient in comparison with
> > current jTr incremental mode. Is it correct?
>
> No, this is not correct. This is apples and oranges.
>
> > Is there a workaround or
> > something similar to archive similar results with jTr?
>
> It depends. Mask mode is quicker to use when you know a pattern and
> need to have the program test that specific pattern. In JtR, this is
> currently more cumbersome to do and it runs slower - e.g., with
> KnownForce external mode.
>
> When you don't know a specific pattern (or when there are too many such
> patterns to be worth enumerating, or when they'd overlap), you'd use
> other cracking modes anyway.
>
> 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.
