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
Powered by Openwall GNU/*/Linux - Powered by OpenVZ