[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFMma9P5FPBxJBQaOT_nrjZBqcM=DZhJ_--Y5SGz49Mb_343Nw@mail.gmail.com>
Date: Wed, 3 Oct 2012 20:38:12 -0500
From: Richard Miles <richard.k.miles@...glemail.com>
To: john-users@...ts.openwall.com
Cc: john.magnum@...hmail.com
Subject: Re: Two questions (or feature suggestion) about JTR usage.
Hi magnum,
Thanks for answer, it was very helpful.
a) It's not working for me, my john is version 1.7.9-jumbo-6+unstable, I
sent the SIGHUP as demonstrated below:
kill -1 <PID>
kill -HUP <PID>
However, the progress is not displayed on my script that is calling john.
Am I doing something wrong?
I took a look at doc/EXTERNAL and I really don't know how to use it for
example to display progress every 30 minutes. Do you have any example or
link that may help me?
I would love if you could re-implement or commit the --status-every=SECONDS
feature.
b) It worked very well, great!
Thanks
On Tue, Oct 2, 2012 at 2:16 PM, magnum <john.magnum@...hmail.com> wrote:
> On 2 Oct, 2012, at 16:16 , Richard Miles <richard.k.miles@...glemail.com>
> wrote:
> > a) I have a script (shell script) calling JTR, consequently I can't get
> > progress updates pressing "enter" - the "enter" is sent to shell script
> and
> > not to JTR. What can be done? There is a way or can you consider to add a
> > option to automatic display progress on the screen between X minutes
> > (defined by user)?
>
> First, you can send a SIGHUP to the john process. This will make it flush
> and file buffers and emit a status line. Easily usable in scripts.
>
> Second, doc/EXTERNAL describes a way to achieve what you want, but it will
> be a bit of a hack:
>
> "John the Ripper 1.7.9 and newer pre-defines two additional variables:
> "abort" and "status", both of type "int". When set to 1 by an external
> mode, these cause the current cracking session to be aborted or the status
> line to be displayed (just like on a keypress), respectively. These
> actions are taken after having tested at least all of the candidate
> passwords that were in external mode's "word" so far. In other words, the
> actions may be delayed in order to process any buffered candidate
> passwords."
>
> If you create an external filter that use this, it might affect
> performance for fast hashes though.
>
> Finally, adding a command-line option along the lines of
> --status-every=SECONDS is trivial. In fact I wrote such a patch a while ago
> but never committed it. I could re-implement it if you want to.
>
>
> > b) I would like to execute my incremental tests always during 8 hours,
> > nothing more and nothing less. There is a workaround to do it?
>
> This is supported by Jumbo, since 1.7.9-jumbo-6. Use --max-run-time=28800
> and it will exit cleanly after 8 hours. You can resume it again if you want
> to, but it will remember that option and only run 8 hours at a time.
>
> 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.
