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.