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
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.