[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120726075839.GA4316@debian>
Date: Thu, 26 Jul 2012 11:58:39 +0400
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Aleksey's status report #13
On Wed, Jul 25, 2012 at 11:56:43PM +0200, Frank Dittrich wrote:
> On 07/25/2012 09:52 PM, Aleksey Cherepanov wrote:
> > I missed two previous status reports. So this one covers two weeks. I
> > am sorry.
> >
> > During these weeks I rewrote file management system to use scp and to
> > be extensible. Currently it makes clients to download only files that
> > are needed for some attack (not all files available like before).
> > Possible improvement and extensions are already described. Also it
> > could useful to think about what to do we are offline: use old files
> > that we already have or give up and abort?
>
> Depending on how many clients we have, we could just let each client run
> an independent part of a markov attack against a particular hash file.
> (This can even be done without using MJohn.)
> In markov mode, the probability of password candidates range from
> minimal possible markov level to the maximum markov level specified,
> so each small part of a markov attack will have a more or less similar
> distribution of very likely passwords and less likely passwords (up to
> maximum markov level.
As of markov mode takes ranges in a parameter mjohn thinks about two
ranges of markov mode as about two different attacks at this time.
It is a problem to fix during adding support for attack options.
> We just need to decide if we want to use the default stats file, some
> other stats file generated from (a subset of) the rockyou.txt or some
> other file, or if we want to wait for enough passwords to be cracked
> during the contest...
>
> > I got (near) working restore functionality: user could start attack by
> > name. Problems here: I exclude cosmetic options (at this time:
> > dupe-suppression save-memory mem-file-size crack-status mkpc length
> > fix-state-delay) from attack (so they are not in 'parameters' file on
> > the server)
>
> How did you decide which parameters are "cosmetic"?
Quickly...
> IMO any parameter which changes the "output" (generated candidates) is
> not cosmetic.
I tried to follow this rule.
> At least --length will result in different candidates being generated.
> Not sure it makes sense to use this parameter.
It is a bug in mjohn. Fixed. --length is not a cosmetic option more.
> Also, --dupes-suppression is not really "cosmetic".
> If you start with dupes suppression switched off, and restore with dupes
> suppression switvhed on, you'll miss come words.
I guess you could not restore attack so, could you?
> > I got a question: could I restore a session with other (reduced) hash
> > file?
>
> Yes, this is possible.
> If you used --salts=N or --salts=-N, you'll continue the attack on a
> different subset or the remaining hashes, though.
>
> > It seems there are many actions I would like to perform that are tight
> > to ability to start attack from some point, not the begin. Something
> > like percentages for markov mode.
>
> Using percentages for markov mode, you really define separate,
> individual attacks.
> Although it might make sense to finally cover the complete range, and
> not cover some parts twice, other parts not.
I'll separate percentages from attack. So percentages will be a
property of session (each attack have different sessions: currently
sessions differ by hash type, then partial sessions should be
supported, i.e. percentages of markov).
> > Adding an ability to get a status in
> > percentages I'd be able to do a high-level restoration of attack. Also
> > it would provide an ability to split an attack into pieces.
>
> Please don't try to split attacks by manipulating .rec files.
> At least not for not. (The few exceptions where it might be acceptable
> to clone and adjust .rec files can be covered later.)
I do not intend to craft .ref files for attack split. We already
discussed disadvantages of that way.
To split I could use --node functionality: select quite small part of
attack (start point) and track its end and real progress (end point;
so to restore it and finish we do not make new part of attack that
covers remaining part, instead we just redo that whole part).
Then I think some better interface for that should be done. Maybe some
new option for john or something like this.
Thanks!
--
Regards,
Aleksey Cherepanov
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.
