Date: Thu, 12 Jul 2012 14:29:13 +0400 From: Aleksey Cherepanov <aleksey.4erepanov@...il.com> To: john-dev@...ts.openwall.com Subject: Re: Re: Aleksey's status report #12 On Thu, Jul 12, 2012 at 12:01:28PM +0200, Frank Dittrich wrote: > On 07/10/2012 04:09 PM, Aleksey Cherepanov wrote: > > On Tue, Jul 10, 2012 at 06:04:58PM +0400, Aleksey Cherepanov wrote: > >> The scripts are attached. They are small. Very soon I will fix most > >> todos. > > I just looked more closely at your t.pl script. > > If I understand that correctly, you want to copy all the files needed > for a particular attack into a subdirectory (named like the attack) in > the "store", which is a directory on the client side. > > I'm afraid that's not really practical. > Users can have huge word list files like rockyou.txt, > facebook-names.txt, or even a collection of all words from a wikipedia dump. > If you always copy these files for every new attack (cracking a set of > hashes of a different fast and saltless format, or trying rules from > another [List.Rules:...] section, this will not only take time, the user > might also soon run out of disk space. It is a bug. I do not want to copy file for each attack. I intend to copy file once, only for the first attack. Then wrapper would replace reference to that file with reference to file in the store in subdir of the first attack that used this file. Though even one copy could be too big. I think in some cases it is possible to use hardlinks. > Another problem is your "short test run". > You should verify if the command line parameters really describe an > attack, before you do git add ..., git commit ..., git push ... > What is a short test run? For GPU formats, even processing the first > block of MAX_KEYS_PER_CRYPT candidate passwords can easily take several > minutes. You proposed short test run to verify options: http://openwall.com/lists/john-users/2012/05/23/1 I would like to implement these features today. > Also, what kind of wrapper parameters do you think you'll need? There will be options to overwrite config options. Just for convenience. More important to have options to modify attacks. I mean to make a copy of attack with small modifications (with automatic reference to original attack, to keep track of interconnections between attacks). As of I intend to prevent start of already existent attack I need an option to force such start. You could see that I store status of each attack in a file with user name to allow many users run the same attack (but one user could not run the same attack twice, practically he could do it and would overwrite status file, also a bug). And of course there will be an option to start attack by name. So user does not need to type all options to start some existent attack. Also I think some additional actions could be done with options. For instance I'd make an option to calculate overlap between attack keyspaces (on demand approach to (not popular and heavy) statistics). Maybe some other things just for convenience. For instance simple config file management: for chr file, action to make new charset and add a section about it into config (and probably start an attack with it). I think I could not predict all such small features but some practice will show what is needed. 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.