[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
