[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120712105308.GC6041@debian>
Date: Thu, 12 Jul 2012 14:53:08 +0400
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Re: Aleksey's status report #10
On Wed, Jul 11, 2012 at 10:45:13PM +0200, Frank Dittrich wrote:
> On 07/10/2012 07:42 AM, Aleksey Cherepanov wrote:
> > On Wed, Jun 27, 2012 at 02:55:34PM +0200, Frank Dittrich wrote:
> >> --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.
>
> If there is already a '=' char, as in --markov=200:0:0:12 or
> -markov=section:0:0:0:10, replacint the first ':' with '=' would be wrong.
My mistake. I replace first delimiter (either = or : ) with = so there
is no problem.
> >> 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.
>
> Yes, I think the options should be used with 2 leading dashes, as
> mentioned in the usage output or --list=hidden-options (for options
> which don't appear in the usage output.
>
> There is one option which doesn't appear in the usage output and which
> doesn't (yet) appear when using --list=hidden-options, but it is not
> relevant for attacks: --make_check.
> You an just ignore this option.
>
> It should be relatively easy to create a mapping from abbreviated option
> names to their long names.
> (Don't do it by hard coding all possible combinations like I did for
> several options in john.bash_completion - I intend to change that as well.)
>
> The generic approach is:
> collect all the options listed in the usage output or in
> -list=hidden-options output.
> Remember which options do have an optional parameter (those with
> --option[=...]), and which have a mandatory parameter (--option=...).
I think we do not need to remember this. We normalize -/-- and =/: ,
then we just cut and remember option's value and delimiter if there is
one, expand name, append value back.
> Now store mappings of abbreviated option names ("--o" ... "--optio") to
> the complete option name ("--option"), as long as this abbreviated name
> is not ambiguous):
> Built abbreviated forms for all of these options, by deleting the last
> character, check if there is already an existing mapping.
> If no, store the new mapping. If yes, that means, the abbreviated option
> is ambiguous, just map it to an empty string.
> (If it is easier for further processing, you can also store a mapping
> from "--option" to "--option", or you may prefer to store mappings for
> abbreviated options with just one leading dash...)
It seems that later it would be better to have an option for john
itself to print normalized options and/or even the full cmd line.
> Then, if the user specified abbreviated option names, just replace a
> single dash at the start with two dashes, and look up the long option
> name for the abbreviated option name.
> This way, the server will receive just long option names in the attack
> description, making sure those attack descriptions will continue to work
> even with future john versions which might have more options, possibly
> colliding with abbreviated forms of other option names.)
>
> >> 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.
>
> But file names are more likely to be not unique.
> You can't prevent a user to overwrite a file my_wordlist after creating
> one attack description and prior to the next attack description.
> So, storing the file name is useful, but a checksum makes sure to
> recognize if two files are unique, even if the name given by the user
> differs. (Instead of storing multiple names for the same file, I'd think
> about responding with an error message instead.)
Yes, one user could change a file or two users could have different
wordlists with the same name. That's why I put files into subdirs.
I.e. file is located in folder of respective attack. Two attacks - two
files, names does not matter (I intend to avoid copies of the same).
So virtually I add attack name (including user name) to the file name.
Though currently file name could collide with file for attack
description or other service files. So I think to move user files
deeper, into subsubdir, i.e. into store/user-name_attack-name/files/ .
The opposite problem: how to find the same files? In general before
addition we should compare new file with all existing in the store. I
think I will speed it up with index file (consisted of checksums) in
the store (I will not push that file to avoid conflicts). Though there
is a race condition: two users could add the same file in parallel. So
we could get two equal files. But it does not really matter.
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.
