[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120713091907.GB11207@debian>
Date: Fri, 13 Jul 2012 13:19:07 +0400
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Re: Aleksey's status report #10
On Thu, Jul 12, 2012 at 08:58:28PM +0400, Aleksey Cherepanov wrote:
> On Thu, Jul 12, 2012 at 03:43:29PM +0400, Aleksey Cherepanov wrote:
> > On Thu, Jul 12, 2012 at 01:16:16PM +0200, Frank Dittrich wrote:
> > > On 07/12/2012 12:53 PM, Aleksey Cherepanov wrote:
> > > > 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.
> [...]
> > > But that would possibly require to rewrite attack descriptions in a
> > > similar way, so that they use the checksum instead of the user-supplied
> > > file name.
> > > And when you checkout the files, they could be renamed to the
> > > user-specified file name again.
> >
> > I think renaming is not needed. We could just store two names:
> > original will be used in properties of attack and checksum will be
> > used to refer real file when user runs attack.
>
> Oh, I missed something: if we do not rename files and user wants to
> start/modify not his own attack directly then he should pass real
> filename to the wrapper, i.e. he should refer to file by sha1sum.
>
> I think we need a syntax to refer to files by their virtual names.
> There could be a trick: instead of putting file into attack's subdir
> we put there a file with checksum of real file and handle it in
> wrapper (when user tries to use that file we substitute sha1sum). It
> is like symlinks but more strict and portable (I think git would save
> symlink as a symlink in difference to hardlinks, but I doubt that
> symlinks from windows and unixes would work together).
>
> Though I found other problem: user could use files with the same name
> in one attack. For that files should be in different folders. But when
> I would "copy" them into attack's subdir they would collide. Though it
> does not seem to be very important. As a simple solution we could ask
> user to (interactively) rename file with checksum in store if so. Or
> we could rename it automatically.
>
> Other ways to store and use filenames also need some renaming.
I made sha1sum as names. Though I do not store original name yet.
Wrapper copies john.conf into the store. Though path to config should
be specified always (could be in config). Includes are not handled.
Options expansion was added. For instance -mark:... becomes
--markov=... .
I implemented short run with --max-run-time to verify option but got a
problem (so it does not really work): when john exits by time it
return exit code 1, that is equal to all errors john returns. I think
I could patch john, or I could use john's output to determine type of
error but this needs some (small) investigation into output
redirections (or robust quoting to pass commands to shell).
Also I merged scripts together, made hardcoded default config with
support for external config and overwriting from command-line.
Things above are tested a bit and seems to work. But there are some
things I did not test yet and maybe broke.
So I moved to daemon creation library. Daemons are intended to be
detached now.
And I added much more options and probably did not integrated them
well.
Also I did not test daemons to work with sha1sum.
So work is in progress.
Frank, please, look onto the script.
Thanks!
Regards,
Aleksey Cherepanov
View attachment "u.pl" of type "text/x-perl" (20022 bytes)
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.
