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.