[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F1F41AE.8050205@hushmail.com>
Date: Wed, 25 Jan 2012 00:41:34 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: --max-run-time option
I just committed a trivial patch to github, adding a new option:
$ ./john test/unbreakable.sam -inc -fo:nt -max-run-time=5
Loaded 1 password hash (NT MD4 [128/128 X2 SSE2-16])
guesses: 0/79434016 time: 0:00:00:04 0.00% c/s: 15950K trying:
bh30093 - bh30015
Session stopped (max run-time reached)
Very trivial, I think (hope) it doesn't have any ill effects. Apart from
testing purposes, it has some real-life uses (note that this is a
graceful stop even for MPI jobs).
Some caveats:
* The option is saved in the session file so if you run a one hour
session to "max run-time reached" and then resume it, it will run for
another hour and stop again - unless you hack the session file. I'm
considering changing this but we may need to discuss options parsing
details.
* If you start with -max=60 and stop (using ctrl-c) after 15 seconds and
then resume, it will run 60 more seconds, for a total of 75.
* The start-up time (eg. hash loading, wordlist buffering, rules
expansion) is counted. I'm considering changing this but it will be a
little more intrusive - each cracking mode would have to reset the
counter, but then again not always if in batch mode, etcetera...
However, for testing purposes it would be nice to have eg. 30 seconds of
actual cracking.
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.
