[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 11 Jul 2012 22:45:13 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Re: Aleksey's status report #10
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.
>> 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=...).
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...)
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.)
Frank
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.
