Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 11 Mar 2007 03:38:50 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: running in the background and on SMP

On Sat, Mar 10, 2007 at 09:18:17AM -0800, Dexter Genius wrote:
> My question is .. how can I get john to start in the background and stay
> there

This question is not really about John, but rather about your OS and
command-line shell.  On Unix-like systems, you may invoke a command with
"&" (ampersand) at the end of the command line - then the command will
execute in the background.  You may also want to redirect the output to
a file or to /dev/null if you don't need it.  For example, you may run:

	./john passwd > /dev/null 2>&1 &

As it relates to John specifics, you may close the terminal emulator
window or close the connection to a remote system where John is running
and not have John killed.  John will intercept the HUP (hangup) signal.
This works irrespective of whether or not you have started John in the
background (as shown above).

Another feature is the ability to check the status of a running John by:

	killall -HUP john
	./john --status

(If your system does not offer a "killall" command, you need to use
plain "kill" and supply the PID of the running John.)

The HUP signal tells the running John to update its status file.

Alternatively, you may find it convenient to run John under GNU screen.

With these long John runs, you should really want to set "Idle = Y" in
john.conf.

> 'till it'll find the passwords ..

John might not find all of your passwords in a reasonable time.  That's
why it makes sense to use it for the purpose of detecting and eliminating
weak passwords.

However, yes, in the event that it does find all of the passwords, it
will terminate.  Also, it will terminate if forced to use only a
cracking mode other than "incremental" and it runs out of candidate
passwords for that mode.

> also .. I have a dual-quad ( 8 procs
> ) and another dual - dual core ( 2 procs with 2 cores each ) how can I make
> it use the full power of the machine ?

This is on FAQ:

Q: Does John support multi-processing or distributed processing?
A: There's no real MP or distributed processing support in John right
now, but you can distribute the work between a few nodes manually.  One
approach would be to have your nodes (CPUs, machines) each try different
password lengths.  This is easily accomplished with "incremental" mode's
"MinLen" and "MaxLen" settings (see CONFIG).  Typically, you would not
really need to split the work for "single crack" and wordlist modes
since these are relatively quick, although you may dedicate one node to
those initially.  You may safely run multiple instances of John in the
same working directory, all writing to the same "pot file" (this is a
feature).  You do, however, need to assign each of them a unique session
name, with "--session".  Other approaches, such as splitting password
files naively (without regard to salts), are typically less efficient
(in some cases to the extent where there's no speedup from using
multiple processors at all).

The use of "MinLen" and "MaxLen" is demonstrated in this posting:

	http://www.openwall.com/lists/john-users/2005/08/24/4

It will work well for 4 CPU cores, but not for your 12 cores, though.
So you might need to use other approaches as well.  What hash type are
you going to be cracking?  How many different salts?

Also, this search query is relevant:

	http://search.gmane.org/?query=parallel&group=gmane.comp.security.openwall.john.user

-- 
Alexander Peslyak <solar at openwall.com>
GPG key ID: 5B341F15  fp: B3FB 63F4 D7A3 BCCC 6F6E  FC55 A2FC 027C 5B34 1F15
http://www.openwall.com - bringing security into open computing environments

Was I helpful?  Please give your feedback here: http://rate.affero.net/solar

-- 
To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply
to the automated confirmation request that will be sent to you.

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ