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.