[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <44541c40703101700n2e30617eo2d43d26748ac3dbd@mail.gmail.com>
Date: Sat, 10 Mar 2007 17:00:30 -0800
From: "Dexter Genius" <dexter@...t3r01.tk>
To: john-users@...ts.openwall.com
Subject: Re: running in the background and on SMP
So .. the answer is kinda "no" to both of them .. john can't auto-put itself
in a background and stay there even if the ssh/terminal session is closed
... and it can't use the full power of a dual dual-core machine .. or HT or
any other type .. hmm .. this would be useful in john ! ( both of the
'features' ) ..
On 3/10/07, Solar Designer <solar@...nwall.com> wrote:
>
> 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.
>
>
--
A dorky kid named dex.
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.
