john-users - Re: automation equipped working place of hash cracker, proposal

Openwall wordlists collection for password cracking (20+ languages)

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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