[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120712105617.GD6041@debian>
Date: Thu, 12 Jul 2012 14:56:17 +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:44:40PM +0200, Frank Dittrich wrote:
> On 07/12/2012 12:29 PM, Aleksey Cherepanov wrote:
> > On Thu, Jul 12, 2012 at 12:01:28PM +0200, Frank Dittrich wrote:
> >> 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.
>
> But in this case you have a problem if the user changes the content of
> that file between attacks.
So additional check is needed to compare files and to make a new copy
when file is changed.
> > Though even one copy could be too big. I think in some cases it is
> > possible to use hardlinks.
>
> Do hard links work on Windows? If not, is that important?
> If I look at the windows specific targets in the make file, it doesn't
> look line hard links are supported:
>
> ../run/unshadow.exe: symlink.c
> $(CC) symlink.c -o ../run/unshadow.exe
> strip ../run/unshadow.exe
As I know hard links depend on file system. Windows with ntfs has some
thing like hardlinks. Though it needs special investigation and
probably special code for that. Also I should admit that even unixes
with some filesystems hard links would not work. Though they would in
most cases.
> >> 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
>
> Yes, I think we somehow need to avoid that a lot of crap which doesn't
> work gets stored on the server.
> Not that implementing some checks in the wrapper would prevent a
> malicious user to directly use the git commands to upload crap.
> But I would ignore that case, at least for now.
> I am more concerned about a user accidentally inserting a typo somewhere.
>
> So the check could also be done by creating a new hidden option, say
> --verify, to john.
>
> If we make than hidden option accept optional parameters, we could even use
>
> --verify=0 just check the parameter for syntactical correctness
> --verify=1 additionally, check that the command line options describe an
> attack
> --verify=2 additionally check that there are (uncracked) password hashes
> left in the input file(s), either for the first format that finds a
> valid entry, or for the format specified on the command line
> --verify=3 add even more checks, like: are the rules referred to by the
> --rules parameter syntactically correct
> ...
>
> This approach would avoid a real test run, but it has some drawbacks as
> well. (Some drawbacks are the same as with a real test run.
>
> --verify=3 wouldn't need to check the correctness of rules everytime I
> wan to use the same rules in a different attack (different word list or
> different hashes)
>
> If we verify the command to run, a user who hasn't hardware with a GPU
> cannot create and upload attack descriptions for formats implemented for
> OpenCL or CUDA.
> That means, he cannot create attacks for less experienced users with
> more suitable hardware.
Test run seems to be enough good, easy and general to be implemented
first.
> >> Also, what kind of wrapper parameters do you think you'll need?
> >
> > There will be options to overwrite config options. Just for
> > convenience.
>
> Just make sure you care for the "convenience" part *after* the mandatory
> functionality is there.
I already did it in a general manner. So now all options could be
overwritten using --config-<option>=<value> style. For instance if a
user want to run another john (for instance gpu version) he could
supply --config-john=john-gpu (or something like that).
> > 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).
>
> I don't know if it is more important now. May be later.
> The drawback is that users would need to learn a new syntax, whereas
> with a simple wrapper, they use normal john syntax.
> They can grab old commands from bash history and modify them.
> (It should even be possible to reuse john's bash completion logic with
> little effort.)
New syntax is minimal here. User would say to modify attack and supply
options for john. Supplied options overwrite old ones and add new so
user get old options, old options with new values and new options.
For bash history I think it is possible to compare new call with the
last one and say that commands are similar if only one option is
different (or other amount of options, or we could have a weights for
different options, or we could track interconnections by other means
and we get back to discussion of meta-attacks:
http://openwall.com/lists/john-users/2012/05/27/1 ).
Even having meta-attacks it is nice to have an ability to overwrite
some keys in existing attack. One way is to show command line for that
attack so user could copy it into shell and change it. Other way is an
option.
I just realized that option to modify attack could be merged with
option to run existent attack: without new arguments it just run old
attack, with new arguments it creates new attack.
> > As of I intend to prevent start of already existent attack I need an
> > option to force such start.
>
> If you want to force starting such a command, just don't use the
> wrapper. Shouldn't this work?
Then we loose tracking of progress.
> > 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).
>
> Why would a user want to run the same attack more than once?
For instance it could have two computers and he want to try attack on
other computer due to speed considerations. Though user could have
different user names in script so second wrapper would not create new
attack and would not conflict with the first. Hm, probably I need
additional option (like machine number) to make it less hackish.
> > Also I think some additional actions could be done with options. For
> > instance I'd make an option to calculate overlap between attack
> > keyspaces
>
> This is hard to do for certain attacks.
> Also, the key space an incremental mode attack covers is "all the
> passwords up to the max. length, assuming you didn't forget to include
> some of the possible characters. But usually such an attack will never
> finish.
If we get first N candidates from incremental mode it would be a
meaningful keyspace. I think N could reflect the time before the end
of contest multiplied by greatest speed in team. Though speed could be
increased by --fork. So it may be better to supply N (or speed)
manually. Because efficiency of incremental mode decreases it could be
the case.
> More interesting could be to identify how much several [List.Rules:...]
> sections overlap. But this probably shouldn't be done by a perl script
> (alone). Instead, a new helper function is needed in john to parse a
> Rules section and to write the results to stdout.
>
> > 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 don't think this is done so frequently that it justifies support by a
> script.
Probably there should separate script that does so each few hours.
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.
