[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d0ba967ad4c558c64bf568964bd47cf6@smtp.hushmail.com>
Date: Tue, 08 May 2012 17:55:57 +0200
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: automation equipped working place of hash cracker,
proposal
On 05/08/2012 02:14 PM, Rich Rumble wrote:
> John had a "fork" option in the CrackMeIfYouCan contest, derived from
> MPI I believe, perhaps the code that was used to create "fork=n" would
> be useful to distribute the work. I'm not sure how/if/where the code
> is available but it had a few bugs we know of and possibly more we
> didn't discover. The pot files were not updating on the children
> unless the child threads were killed, however that wasn't the case in
> cygwin, killing the children did not update the pot files.
> http://www.openwall.com/lists/john-dev/2012/01/17/9
> Fork would not let you restart a session, .rec files were useless and
> this was to be expected with this patch. I found this mode very
> helpful+powerful during the contest, and despite it's
> shortcomings/bugs I still use it.
I have half-heartedly maintained a private copy of the --fork and --node
code, unified with the MPI code and with current git updates. It's not
100% complete but the idea was that a session started with --fork=4
would produce .rec files that are identical to ones produced with
mpiexec -np 4, so you could start a session using --fork and resume it
under MPI, or vice versa.
I'd like to finish that and release it but I don't have the inspiration:
The problem is not so much writing the final pieces of code, as it is
testing it :-/
For some uses, --fork worked better than MPI. For example, pressing a
key would give you a status output (iirc). MPI would only be needed for
sharing work between different hosts.
magnum
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.
