[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120710054254.GA26537@debian>
Date: Tue, 10 Jul 2012 09:42:54 +0400
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Re: Aleksey's status report #10
Hi Frank,
On Wed, Jun 27, 2012 at 02:55:34PM +0200, Frank Dittrich wrote:
> On 06/26/2012 11:47 PM, Aleksey Cherepanov wrote:
> > On Wed, Jun 27, 2012 at 01:40:23AM +0400, Aleksey Cherepanov wrote:
> >> This status report has attached code not for users so it is on
> >> john-dev.
> >
> > Sorry! I forgot the code...
> >
> > Frank, please look onto this.
>
> I'll just copy some source code snippets into my reply and comment on
> them, I think you'll recognize those...
I think that is the right way to do things. That's why the attachment
was not compressed.
> May be in the source code comments you should replace "keys" with
> "options" or "parameters".
Fixed.
> In the first comment, you should also list (and adjust during future
> development) the preconditions for using the script:
> -git
> -ssh
> -...
Yes, list of preconditions is needed.
Though I am not sure that ssh is needed directly. However for tests on
remote server I used git+ssh scheme that surely needs ssh.
> my $store = '/home/a/desktop/wrapper/test-store1';
>
> IMHO you should avoid absolute path names, and use path names relative
> to the current directory whenever possible.
I have some absolute paths: to john (after some new changes, I will
extend this to relative paths also), to the store, to the config. The
store is intended to be independent of current directory. I am not
sure how to avoid this.
The store is a folder where everything is copied to and then
synchronized with the server. So user could work anywhere but
everything is tracked. It is not really nice because it copies
everything while some users could have "huge wordlists and small hard
drives".
> # TODO: does john accept only = and : as separater for keys?
>
> john accepts : and = as separator between (possibly abbreviated) option
> name and value.
>
> --markov can have several colons, e.g.
>
> --markov=200:0:0:12
> --markov=section:0:0:0:10
> --markov:section:200
> and so on.
> The first : (or =) separated the option name from the parameters passed
> into the markov mode function.
I replace only first : with = and only in parameters started with - so
everything should work well.
> We should prefer = (the separator used in the usage output) if possible.
By the way should I prefer double dash or single dash? '-key' or
'--key'? I guess double dash is preferred due to john's usage output
and general idea of long and short options.
> For other section names, you might even need to implement new
> functionality to john, like listing the contents of a section (with
> include statements for sections or file names being resolved).
> Or at least functionality to get the value of a certain variable from a
> config section, so that you can parse
>
> File = $JOHN/my.chr
>
> and know which file is needed for that attack.
>
> To send the attack description to the server, you could also require
> attacks to specify --config=..., so that you can grab the whole config
> file (FIXME: What if that file uses includes) instead of reading/parsing
> the contents of the section(s) required and sending that contents.
Maybe the easiest way is to wrap fopen into macro that shows requested
file name if some option is passed to john then it would be easy to
grab all files.
> For naming attacks, files, and so on:
> You could generate a checksum (sha1sum ...) on the contents, and use
> (part of) that as the name for storage on the server.
Checksums are not good for names of files used by john because
original names could have valuable meaning. And I guess it is easier
to store checksum for files separately, not in file name.
In general use of checksums is nice but I am not sure how to do it
right. I think it will be more clear with more code.
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.
