[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP35237F66D850485518DC816FD3F0@phx.gbl>
Date: Tue, 17 Apr 2012 23:29:41 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-users@...ts.openwall.com
Subject: Re: Crowd-sourcing statistics and rules
On 04/17/2012 10:54 PM, Rich Rumble wrote:
> On Tue, Apr 17, 2012 at 1:48 PM, Frank Dittrich
> <frank_dittrich@...mail.com> wrote:
>> For very small word lists and for single mode, the reported rule will
>> more frequently be wrong.
> That is good to know, maybe it can be patched or an additional option
> added that gives a more "real time" log, I assume doing so has the
> potential to slow JtR down.
> If so perhaps a small warning when Jtr
> starts with that option or config option enabled that it print some
> "JtR performance may suffer due to -vv (or whatever) being enabled" to
> stdout.
To implement this functionality, it would be necessary to not just
generate password candidates, but to store information about the rule
and input word (or step of incremental mode or markov mode), and report
this in the log file, depending on compile time flags, or variables in
an [Options...] section in john.conf.
This will produce a constant overhead, due to additional computation and
memory requirements.
Another alternative to implement this could be:
Since most of the password candidates will not crack any hash, try to
rebuild that information whenever at least one password in the buffer
has been cracked. E.g., for single mode, john will in addition to the
latest rule also keep track of the oldest rule that is still in use.
SO, starting from here, it should be possible to generate a new set of
password candidates, check which one matches the password candidate
which cracked a hash, and report the correct rule in the log file.
For the normal operation, this shouldn't have a measurable run time
impact, but it would mean more overhead for whenever at least one
password hash gets cracked.
May be the overhead is too large anyway, so that none of these
alternatives gets implemented.
Then, the only way to obtain his information without changing john's
logic I can think of is:
Copy the current dummy format to dummy1, set the buffer size to 1.
(This will slow down this dummy1 format compared to dummy, but it should
still be faster than most real hash algorithms.
When I have time for this during the next days, I'll try it out and do
some measurements.)
Convert your pot file into an input file for --format=dummy1, and re-run
your cracking session for this format, may be in a separate directory,
or using --pot=....
Because the buffer size is 1, the log file should contain the correct
rule.
Frank
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.
