[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121114041729.GC2868@openwall.com>
Date: Wed, 14 Nov 2012 08:17:29 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: How does incremental mode works?
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.
