'Fossies' - the Fresh Open Source Software Archive
Source code changes of the file 'doc/FAQ' between
john-1.7.9-jumbo-7.tar.gz and john-1.8.0-jumbo-1.tar.gz
About:$ john-the-ripper MD5.hash -format=Raw-SHA1-ng Using default input encoding: UTF-8 No password hashes loaded (see FAQ) $ john-the-ripper MD5.hash -format=Raw-SHA1-Axcrypt Using default input encoding: UTF-8 Loaded 1 password hash (Raw-SHA1-AxCrypt SHA1 128/128 SSE2 4x) Press 'q' or Ctrl-C to abort, almost any other key for status 0g 0:00:00. Type rtgen sha1 ascii-32-95 1 20 0 1000 1000 0 and press Enter (creates a sha1 rainbow crack table) 4. Press Enter (sort Rainbow) 5.l /root/capturedhashes.txt and press Enter to crack the password in hash file.h hashvalue and press Enter to crack the password in hash 7. Answer Questions. C/s = crypts (password hashes) computed per second; C/s = crypts tested per second (in versions below 1.8.0 this was 'c/s') The current word it's trying. John has three modes to attempt to crack hashes. If you do not indicate the mode, all 3 will be used and you will see x/3 in your status output indicating which mode it's on. Type rtgen sha1 ascii-32-95 1 20 0 1000 1000 0 and press Enter (creates a sha1 rainbow crack table) 4. Press Enter (sort Rainbow) 5.l /root/capturedhashes.txt and press Enter to crack the password in hash file.h hashvalue and press Enter to crack the password in hash 7. Answer Questions. Cisco password hashes: John the Ripper and hash-cat. Discuss password hashes and salting, and discuss cracking tools or websites that can be used to crack password hashes. Some of the most popular Linux tools are John the Ripper and hashcat, which are both already included with the Kali Linux distribution.
John - a password cracker (community-enhanced version with more features bu tlower overall quality).| FAQ (john-1.7.9-jumbo-7) | : | FAQ (john-1.8.0-jumbo-1) |
|---|---|---|
| John the Ripper FAQ. | John the Ripper FAQ. | |
| The latest version of this FAQ may be viewed online at: | The latest version of this FAQ may be viewed online at: | |
| http://www.openwall.com/john/doc/FAQ.shtml | http://www.openwall.com/john/doc/FAQ.shtml | |
| Help! I can't run John. | Help! I can't run John. | |
| If you're not familiar with your OS, you should probably not be using | If you're not familiar with your OS, you should probably not be using | |
| John in the first place since John is a tool for system administrators. | John in the first place since John is primarily a tool for system | |
| However, here are the answers to a few (not very) common questions to | administrators. This is starting to change with the 'community | |
| avoid having them asked over and over and for amusement. | enhanced' -jumbo versions' support for things such as password-protected | |
| archives, though. | ||
| Here are the answers to a few (not very) common questions to avoid | ||
| having them asked over and over and for amusement. For more serious | ||
| matters, please skip over to the next section. | ||
| Q: When I type 'john' (or 'john passwd', etc.), it says 'command not | Q: When I type 'john' (or 'john passwd', etc.), it says 'command not | |
| found' (or equivalent)?! | found' (or equivalent)?! | |
| A: The examples given in John the Ripper documentation assume that you | A: The examples given in John the Ripper documentation assume that you | |
| know how to invoke newly-built programs from your shell. On Unix-like | know how to invoke newly-built programs from your shell. On Unix-like | |
| systems, it is typical to not have '.' (the current directory) in your | systems, it is typical to not have '.' (the current directory) in your | |
| $PATH (the list of directories to search for programs). In that case, | $PATH (the list of directories to search for programs). In that case, | |
| you need to type './john' (dot, slash, and 'john', without the quotes) | you need to type './john' (dot, slash, and 'john', without the quotes) | |
| to invoke the John binary executable located in the current directory. | to invoke the John binary executable located in the current directory. | |
| Q: ...but I am on a Unix-like system and I don't seem to readily have a | Q: ...but I am on a Unix-like system and I don't seem to readily have a | |
| John binary executable. | John binary executable. | |
| A: Please follow the instructions in INSTALL. | A: Please follow the instructions in INSTALL. | |
| Q: When I double-click on 'john.exe', a window flashes and disappears?! | Q: When I double-click on 'john.exe', a window flashes and disappears?! | |
| A: You're not supposed to click. You're supposed to run John from a | A: You're not supposed to click. You're supposed to run John from a | |
| command-line shell. On Windows, some of those shells would be cmd.exe, | command-line shell. On Windows, some of those shells would be cmd.exe, | |
| command.com, or bash (the latter is available with Cygwin). | command.com, or bash (the latter is available with Cygwin). | |
| Other trivial matters. | Other typical new user questions. | |
| Q: How do I start John on my password file, use a specific cracking | Q: How do I start John on my password file, use a specific cracking | |
| mode, see the passwords it cracked, etc? | mode, see the passwords it cracked, etc? | |
| A: See README and EXAMPLES. :-) | A: See README and EXAMPLES. :-) | |
| Q: How do I 'unshadow'? | ||
| A: See EXAMPLES on how to combine your passwd and shadow files, provided | ||
| that you have root access to the target system. | ||
| Q: Why doesn't John load my password file? It says 'No password hashes | Q: Why doesn't John load my password file? It says 'No password hashes | |
| loaded', 'No password hashes loaded (see FAQ)', or 'No password hashes | loaded', 'No password hashes loaded (see FAQ)', or 'No password hashes | |
| left to crack (see FAQ)'. | left to crack (see FAQ)'. | |
| A: Your password file might be shadowed. You need to get both | A: Your password file taken from a Unix-like system might be shadowed. | |
| /etc/passwd and the shadow file (typically /etc/shadow), and combine | You need to get both /etc/passwd and the shadow file (typically | |
| them into one file for use with John. Please refer to EXAMPLES. | /etc/shadow or /etc/master.passwd), and combine them into one file using | |
| 'unshadow' (which is supplied with John). Please refer to EXAMPLES. | ||
| A: All of the password hashes found in the file (that are of the same | A: All of the password hashes found in the file (that are of the same | |
| type as the very first recognized hash in the file unless you're using | type as the very first recognized hash in the file unless you're using | |
| the '--format=...' option) might be already cracked by previous | the '--format=...' option) might be already cracked by previous | |
| invocations of John. (The message printed in that case has been changed | invocations of John. (The message printed in that case has been changed | |
| to 'No password hashes left to crack (see FAQ)' starting with version | to 'No password hashes left to crack (see FAQ)' starting with version | |
| 1.7.7.) To display cracked passwords, use 'john --show' on your | 1.7.7.) To display cracked passwords, use 'john --show' on your | |
| password hash file(s). To force John to crack those same hashes again, | password hash file(s). To force John to crack those same hashes again, | |
| remove the john.pot file. | remove the john.pot file. | |
| A: With PWDUMP-format files, John focuses on LM rather than NTLM hashes | A: With PWDUMP-format files, John focuses on LM rather than NTLM hashes | |
| by default, and it might not load any hashes at all if there are no LM | by default, and it might not load any hashes at all if there are no LM | |
| hashes to crack. To have JtR Pro or a build of JtR with the jumbo patch | hashes to crack. To have JtR Pro or a -jumbo version focus on NTLM | |
| focus on NTLM hashes instead, you need to pass the '--format=nt' option. | hashes instead, you need to pass the '--format=nt' option. | |
| A: If you're using the '--format' option, try dropping it. Except for | ||
| the special case mentioned in the answer above, '--format' is normally a | ||
| way to choose one of multiple hash/cipher types found in the same file | ||
| or to clarify the hash/cipher type if it would otherwise be ambiguous | ||
| (e.g., a 32 hexadecimal character string may correspond to one of many | ||
| distinct hash types). That is, you normally only need to use '--format' | ||
| when John would otherwise misdetect your hash/cipher type (e.g., when it | ||
| says LM and you know that your hashes are in fact raw MD5, you'd use | ||
| '--format=raw-md5' with -jumbo) or if it would load undesired entries | ||
| from the file. If John does not load anything, then your use of | ||
| '--format' is probably unreasonable (or you should be using a different | ||
| version/build of John - see the answer below). | ||
| A: Your password hash or cipher type(s) might not be supported by John, | ||
| or at least by the version and build of John that you're using. If | ||
| you're using a non-jumbo version, you will likely want to try -jumbo | ||
| instead, which supports a lot of additional hash and cipher types (e.g., | ||
| you currently need -jumbo for raw MD5). If unsuccessful with that and | ||
| if other answers (above and below this one) don't apply, please post a | ||
| note to the mailing list (see CONTACT) including a sample password file | ||
| line that John does not load (please make sure that the password is | ||
| already changed by the time you post). | ||
| A: John only loads properly formatted text files directly. It can load | ||
| /etc/passwd and PWDUMP format files. Starting with version 1.7.6, it | ||
| can also load text files containing one password hash per line (and | ||
| nothing else on that line). Some other file formats are supported via | ||
| extra tools (supplied with John): unafs (Kerberos AFS database files), | ||
| undrop (Eggdrop IRC bot userfiles), ssh2john (OpenSSH private keys), | ||
| pdf2john (some password-protected PDF files), rar2john (some | ||
| password-protected RAR archives), zip2john (some password-protected | ||
| PKZIP and WinZip archives). You need -jumbo for most of these. To use | ||
| the proper one of these (for your file format), run it on your file(s) | ||
| and redirect the output to a new file (using your shell's output | ||
| redirection feature - e.g., './ssh2john ~/.ssh/id_rsa > sshpasswd'). | ||
| Then run John on the resulting file (e.g., './john sshpasswd'). | ||
| A: The file you're trying to run John on might in fact not be a password | A: The file you're trying to run John on might in fact not be a password | |
| file at all. | file at all. | |
| A: Your command line syntax might be wrong, resulting in John trying to | A: Your command line syntax might be wrong, resulting in John trying to | |
| load a wrong file. | load a wrong file. | |
| A: Your password file format or hash type(s) might not be supported by | ||
| John, or at least by the version and build of John that you're using. | Q: John appears to misdetect my hash type. I have raw MD5 hashes from a | |
| If you're positive that this is the case, you may want to check the | web application, but John wrongly says they're LM hashes. How do I get | |
| contributed resources list on John the Ripper homepage for a suitable | them detected correctly? | |
| patch and, if unsuccessful with that, post a note to the mailing list | A: Some hash and cipher types use ambiguous encodings - e.g., a 32 | |
| (see CONTACT) including a sample password file line that John does not | hexadecimal character string may correspond to one of many hash types, | |
| load (please make sure that the password is already changed by the time | including raw MD5, LM, NTLM, and many others supported in -jumbo. First | |
| you post). | of all, you need a version and build of John that supports your hash and | |
| cipher type. Starting with version 1.7.7 (and 1.7.7-jumbo*) John will | ||
| Q: I am getting the error 'fopen: ./all.chr: No such file or directory' | suggest alternate hash and cipher types for encodings that it finds | |
| (or 'fopen: ./lanman.chr: No such file or directory'). | ambiguous (that is, those corresponding to more than one of its | |
| Q: Where are the charset files? | supported hash and cipher types). When doing so, it will suggest | |
| A: Development versions of John the Ripper might not include the charset | specific '--format=...' options to use. For example, when you run a | |
| files. You're supposed to take them out of the latest official release. | recent enough -jumbo version on raw MD5 hashes, it loads those as LM | |
| (because they could in fact be LM, as well as for compatibility with | ||
| non-jumbo), but it suggests that you use '--format=raw-md5', which is | ||
| what you should in fact use in this case. It makes other suggestions as | ||
| well because it does not know whether your hashes are raw MD5 or | ||
| something else. You're supposed to know this and choose the right one | ||
| of the suggested '--format=...' options. If you're not getting a | ||
| suggestion like this from John 1.7.7 or newer even though you're not yet | ||
| using the '--format' option, this means that your version and build of | ||
| John does not recognize the encodings as ambiguous, which may mean that | ||
| it does not support the actual hash or cipher type that you have in | ||
| mind. If you're already using the '--format' option, try dropping the | ||
| option to receive the suggestions. If you're using a non-jumbo version | ||
| of John, the first step is for you to try -jumbo instead. As of this | ||
| writing, you do need -jumbo for some popular hash types such as raw MD5 | ||
| and NTLM. | ||
| Q: What do the various numbers printed on the status line mean? | ||
| A: As of version 1.8.0, the status line may include: successful guess | ||
| count ('g'), session duration (in the D:HH:MM:SS format for days, hours, | ||
| minutes, and seconds), progress indicator (percent done and optionally | ||
| pass number out of the total number of passes), up to four speed metrics | ||
| ('g/s', 'p/s', 'c/s', and 'C/s'), and the current (range of) candidate | ||
| password(s) being tested (John is often able to test multiple candidate | ||
| passwords in parallel for better performance, hence a range). The four | ||
| speed metrics are as follows: g/s is successful guesses per second (so | ||
| it'll stay at 0 until at least one password is cracked), p/s is | ||
| candidate passwords tested per second, c/s is 'crypts' (password hash or | ||
| cipher computations) per second, and C/s is combinations of candidate | ||
| password and target hash per second. Versions of John prior to 1.8.0 | ||
| displayed only the C/s rate (calling it c/s). When you restore a | ||
| pre-1.8.0 session with version 1.8.0 or newer, only the g/s and C/s | ||
| rates will be displayed, because the older .rec file format lacked | ||
| information needed to compute p/s and c/s. | ||
| Q: I am running John for 10 days and it is still not finished?! | ||
| Q: How long should I expect John to run? | ||
| A: It primarily depends on the cracking mode(s) and on your password | ||
| files (in particular, the type of hashes and the number of different | ||
| salts, if applicable). Most importantly, you should note that the | ||
| 'incremental' mode, which a default John run (with no command line | ||
| options) proceeds with after being done with the quicker checks, is not | ||
| supposed to terminate in a reasonable time. It is up to you to decide | ||
| how long you're going to let it run, then consider any uncracked | ||
| passwords strong enough. 'Single crack' mode runs typically take from | ||
| under a second to one day (depending on the type and number of password | ||
| hashes). Wordlist mode runs may also be quick (under a second) for | ||
| tiny wordlists and fast hashes or they may take multiple days with large | ||
| wordlists, with word mangling rules, and with slow hash types and | ||
| substantial numbers of different salts. The status line John reports | ||
| whenever you hit a key includes a progress indicator (percent complete) | ||
| for 'single crack' and wordlist modes. With no cracking mode requested | ||
| explicitly, John will start with 'single crack' mode (pass 1), then | ||
| proceed with wordlist mode (pass 2), and finally with 'incremental' mode | ||
| (pass 3). The pass numbers are reported on the status line, too. It is | ||
| reasonable to let John reach 'incremental' mode (pass 3) and run that | ||
| for a while (some days). You will notice that John's success rate (the | ||
| number of passwords cracked per hour or per day) will be dropping | ||
| rapidly. When you determine that the success rate is low enough, you | ||
| interrupt John. | ||
| Q: Does John support multi-processing or distributed processing? | ||
| A: Yes, but you need to explicitly enable this if desired. Starting | ||
| with version 1.8.0, there's the '--fork' option on Unix-like systems (to | ||
| make use of multiple CPUs and/or CPU cores in a single system) and the | ||
| '--node' option on all systems (this one allows for a trivial form of | ||
| distributed processing). The '--fork' and '--node' options may also be | ||
| used together. Please refer to OPTIONS for a description of these | ||
| options. Additionally, there's built-in parallel processing support | ||
| using OpenMP for all crypt(3) hash flavors (DES-, MD5-, and | ||
| Blowfish-based) supported by John natively, and when running on Linux or | ||
| Solaris also for the underlying system's thread-safe password hashing | ||
| function. The latter is only reasonable to use for crypt(3) hash types | ||
| not yet supported by John natively (such as for glibc 2.7+ SHA-crypt | ||
| hashes as used by recent versions of Fedora and Ubuntu, and for SunMD5 | ||
| hashes, which may optionally be enabled on Solaris). In 'community | ||
| enhanced' -jumbo versions, parallelization with OpenMP is also supported | ||
| for many (but not all) of the hash and cipher types added in those | ||
| versions (including for their built-in implementation of SHA-crypt). | ||
| To use John's OpenMP support, you need to either use an existing | ||
| OpenMP-enabled build (e.g., 'john-omp.exe' on Windows) or make an | ||
| OpenMP-enabled build by uncommenting one of the OMPFLAGS lines near the | ||
| beginning of Makefile. This requires GCC 4.2 or newer, or another | ||
| OpenMP-capable C compiler. For other hash or cipher types and/or to | ||
| distribute the workload between multiple machines, other approaches need | ||
| to be used. One of those approaches is to use the '--fork' and '--node' | ||
| options. For a very small number of nodes (CPUs, CPU cores, and/or | ||
| machines), it is also reasonable to use a manual approach, such as to | ||
| have your nodes try different password lengths. This is easily | ||
| accomplished with 'incremental' mode's 'MinLen' and 'MaxLen' settings | ||
| (see CONFIG). You might not need to split the workload for 'single | ||
| crack' and wordlist modes since these are typically relatively quick, | ||
| although '--fork' and '--node' are supported for these modes too. 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' (please note that doing so does not eliminate the need to | ||
| also distribute the workload with '--node' or otherwise, as discussed | ||
| above). 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 nodes at | ||
| all). Some other approaches, such as using MPI, are listed on the wiki | ||
| at: http://openwall.info/wiki/john/parallelization | ||
| Q: Where do I get wordlists for use with John? | Q: Where do I get wordlists for use with John? | |
| A: http://www.openwall.com/wordlists/ | A: http://www.openwall.com/wordlists/ | |
| Q: Where do I get new versions of John the Ripper? | Q: Where do I get new versions of John the Ripper? | |
| Q: Where do I get the source code for John? | Q: Where do I get the source code for John? | |
| Q: I only have the source code for John the Ripper, where do I get it | Q: I only have the source code for John the Ripper, where do I get it | |
| pre-compiled for my OS (if supported)? | pre-compiled for my OS (if supported)? | |
| Q: What is the primary website for John the Ripper? | Q: What is the primary website for John the Ripper? | |
| A: http://www.openwall.com/john/ | A: http://www.openwall.com/john/ | |
| Q: How can I contact you (the author)? | Q: How can I contact you (the author)? | |
| A: See CONTACT. | A: See CONTACT. | |
| (Semi-)advanced topics. | Questions sometimes asked by existing users. | |
| Q: I've recently switched my system to MD5-based (or Blowfish-based) | Q: I've recently switched my system to Blowfish-based password hashes, | |
| password hashes, but there are still some DES-based hashes in the | but there are still some DES-based and MD5-based hashes in the password | |
| password file. How do I handle multiple hash types in one file? | file. How do I handle multiple hash types in one file? | |
| A: Use the '--format=...' option to tell John which hashes you would | A: Use the '--format=...' option to tell John which hashes you would | |
| like it to load. Unfortunately, you will have to run John for each hash | like it to load. Unfortunately, you will have to run John for each hash | |
| type separately. This requirement may sometimes be avoided with the use | type separately. This requirement may sometimes be avoided with the use | |
| of '--format=crypt', but this is not recommended. Please see the | of '--format=crypt', but this is not recommended. Please see the | |
| description of the '--format' option in OPTIONS for more detail. | description of the '--format' option in OPTIONS for more detail. | |
| Q: I have 10 users, but John said it loaded 15 password hashes. What's | Q: I have 10 users, but John said it loaded 15 password hashes. What's | |
| going on? | going on? | |
| A: Some extremely poorly designed hash types (Windows LM hashes and | A: Some extremely poorly designed hash types (Windows LM hashes and | |
| DES-based crypt(3) hashes known as 'bigcrypt') have a property that | DES-based crypt(3) hashes known as 'bigcrypt') have a property that | |
| skipping to change at line 126 | skipping to change atline 264 | |
| certainly look like they are almost random. | certainly look like they are almost random. | |
| A: No, they are not. No single candidate password will be tried for a | A: No, they are not. No single candidate password will be tried for a | |
| second time and the order in which they are tried is in fact very smart: | second time and the order in which they are tried is in fact very smart: | |
| it is based on frequencies of different trigraphs, stored and processed | it is based on frequencies of different trigraphs, stored and processed | |
| separately for each character position and for each password length. | separately for each character position and for each password length. | |
| Q: Why doesn't John display a progress indicator for the 'incremental' | Q: Why doesn't John display a progress indicator for the 'incremental' | |
| mode? | mode? | |
| A: Do you really want to see a 0% all the time? As explained in MODES, | A: Do you really want to see a 0% all the time? As explained in MODES, | |
| 'incremental' mode is not supposed to terminate in a reasonable time. | 'incremental' mode is not supposed to terminate in a reasonable time. | |
| (There are a few exceptions to this, so a progress indicator might be | (There are a few exceptions to this, so a progress indicator has been | |
| added at some point.) | added in -jumbo and it might be added in official versions later.) | |
| Q: I am running John for 10 days and it is still not finished?! | Q: I just noticed that the p/s, c/s, and C/s rates reported while using | |
| Q: How long should I expect John to run? | 'incremental' mode are a lot lower than they are with other cracking | |
| A: It primarily depends on the cracking mode(s) and on your password | modes. Why is that? | |
| files (in particular, the type of hashes and the number of different | ||
| salts, if applicable). Most importantly, you should note that the | ||
| 'incremental' mode, which a default John run (with no command line | ||
| options) proceeds with after being done with the quicker checks, is not | ||
| supposed to terminate in a reasonable time. It is up to you to decide | ||
| how long you're going to let it run, then consider any uncracked | ||
| passwords strong enough. 'Single crack' mode runs typically take from | ||
| under a second to one day (depending on the type and number of password | ||
| hashes). Wordlist mode runs may also be quick (under a second) for | ||
| tiny wordlists and fast hashes or they may take multiple days with large | ||
| wordlists, with word mangling rules, and with slow hash types and | ||
| substantial numbers of different salts. The status line John reports | ||
| whenever you hit a key includes a progress indicator (percent complete) | ||
| for 'single crack' and wordlist modes. With no cracking mode requested | ||
| explicitly, John will start with 'single crack' mode (pass 1), then | ||
| proceed with wordlist mode (pass 2), and finally with 'incremental' mode | ||
| (pass 3). The pass numbers are reported on the status line, too. It is | ||
| reasonable to let John reach 'incremental' mode (pass 3) and run that | ||
| for a while (some days). You will notice that John's success rate (the | ||
| number of passwords cracked per hour or per day) will be dropping | ||
| rapidly. When you determine that the success rate is low enough, you | ||
| interrupt John. | ||
| Q: Why does John display meaningless c/s values while cracking, instead | ||
| of real 'crypts per second' rate? | ||
| A: The values displayed by John mean combinations (of username and | ||
| password) per second, not crypts per second. This is the effective | ||
| cracking speed that you get on a particular set of password hashes, and | ||
| it may be useful, for example, to tune the '--salts=...' threshold and | ||
| other settings. If you want a benchmark of the low-level password | ||
| hashing routines only, use '--test'. (Future versions of John the | ||
| Ripper might report effective and raw c/s rates for different time | ||
| intervals. These won't fit on the current status line, though.) | ||
| Q: I just noticed that the c/s rate reported while using 'incremental' | ||
| mode is a lot lower than it is with other cracking modes. Why? | ||
| A: You're probably running John for a few seconds only. The current | A: You're probably running John for a few seconds only. The current | |
| 'incremental' mode implementation uses large character sets which need | 'incremental' mode implementation uses large character sets, which need | |
| to be expanded into even larger data structures in memory each time John | to be expanded into even larger data structures in memory each time John | |
| switches to a different password length. Fortunately, this is only | switches to a different password length. Fortunately, this is only | |
| noticeable when John has just started since the length switches become | noticeable when John has just started since the length switches become | |
| rare after a few minutes. For long-living sessions, which is where we | rare after a few minutes. For long-living sessions, which is where we | |
| care about performance the most, this overhead is negligible. This is a | care about performance the most, this overhead is negligible. This is a | |
| very low price for the better order of candidate passwords tried. | very low price for the better order of candidate passwords tried. | |
| Q: What are the 'real' and 'virtual' c/s rates as reported by '--test' | Q: What are the 'real' and 'virtual' c/s rates as reported by '--test' | |
| (on Unix-like operating systems)? | (on Unix-like operating systems)? | |
| A: These correspond to real and virtual (processor) time, respectively. | A: These correspond to real and virtual (processor) time, respectively. | |
| The two results would differ when the system is under other load, with | The two results would differ when the system is under other load, with | |
| the 'virtual' c/s rate indicating roughly what you could expect to get | the 'virtual' c/s rate indicating roughly what you could expect to get | |
| from the same machine if it were not loaded. | from the same machine if it were not loaded. | |
| Q: How can I test John's password hashing routines for proper operation? | Q: How can I test John's password hashing routines for proper operation? | |
| A: John always performs a self-test when you run it on a password file | A: John always performs a self-test when you run it on a password file | |
| and refuses to work if an error occurs. If you need to test all of the | and refuses to work if an error occurs. If you need to test all of the | |
| low-level routines at once, use '--test'. | low-level routines at once, use '--test'. | |
| Q: Does John support multi-processing or distributed processing? | ||
| A: There's currently built-in parallel processing support using OpenMP | ||
| (to make use of multiple CPUs and/or CPU cores in a single system) for | ||
| all crypt(3) hash flavors (DES-, MD5-, and Blowfish-based) supported by | ||
| John natively, as well as for LM hashes and, when running on Linux or | ||
| Solaris, also for the underlying system's thread-safe password hashing | ||
| function. The latter is only reasonable to use for crypt(3) hash types | ||
| not yet supported by John natively (that is, for glibc 2.7+ SHA-crypt | ||
| hashes as used by recent versions of Fedora and Ubuntu, and for SunMD5 | ||
| hashes, which may optionally be enabled on Solaris). In 'community | ||
| enhanced' -jumbo versions, parallelization with OpenMP is also supported | ||
| for many (but not all) of the hash types added in those versions. To | ||
| use John's OpenMP support, you need to make an OpenMP-enabled build by | ||
| uncommenting one of the OMPFLAGS lines near the beginning of the | ||
| Makefile. This requires GCC 4.2 or newer, or another OpenMP-capable C | ||
| compiler. For other hash types and/or to distribute the workload | ||
| between multiple machines, other approaches need to be used. For a | ||
| small number of nodes (CPUs, CPU cores, and/or machines), it is | ||
| reasonable to use a manual approach. One of those approaches is to have | ||
| your nodes 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 workload 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 nodes at all). Some advanced and automated | ||
| approaches are listed on the wiki at: | ||
| http://openwall.info/wiki/john/parallelization | ||
| Q: What is the format of the crash recovery files ('john.rec', other | Q: What is the format of the crash recovery files ('john.rec', other | |
| .rec's)? What do the numbers mean? | .rec's)? What do the numbers mean? | |
| A: The format of these files is deliberately undocumented and is subject | A: The format of these files is deliberately undocumented and is subject | |
| to change without notice. (However, each release of John the Ripper is | to change without notice. (However, each release of John the Ripper is | |
| likely to be able to read .rec files produced by at least the | likely to be able to read .rec files produced by at least the | |
| immediately preceding release. Whenever compatibility is broken, John | immediately preceding release. Whenever compatibility is broken, John | |
| will refuse to recover the session, leaving the .rec file intact.) | will refuse to recover the session, leaving the .rec file intact.) | |
| Although the meaning of some of the numbers that get into .rec files is | Although the meaning of some of the numbers that get into .rec files is | |
| trivial to explain, it is not possible to reasonably describe some | trivial to explain, it is not possible to reasonably describe some | |
| others without going into great detail on John internals. If you really | others without going into great detail on John internals. If you really | |
| need to know, read the source code. | need to know, read the source code. | |
| $Owl: Owl/packages/john/john/doc/FAQ,v 1.27 2011/11/21 02:36:55 solar Exp $ | $Owl: Owl/packages/john/john/doc/FAQ,v 1.34 2013/05/29 22:44:35 solar Exp $ | |
| End of changes. 13 change blocks. | ||
| 106 lines changed or deleted | 175 lines changed or added |
To the Information Files section of the John source changes report or the top of this page
Home | About | All | Newest | Fossies Dox | Screenshots | Comments | Imprint | Privacy | HTTPS
TrueCrypt is a now discontinued encryption tool. A littlewhile ago I stumbled upon an old TrueCrypt volume, unfortunately I couldn'tremember the exact passphrase! Thankfully I was able to use John theRipper to find the password and recover my old data. This post isgoing to go through the steps required to do this.
Installing John the Ripper
There are a few different versions of John the Ripper, unfortunately theofficial release doesn't support TrueCrypt volumes, therefore the example inthis post is going to use the community-enhanced Jumbo version of John theRipper. On CentOS it can be downloadedand compiled with the following steps:
Install packages for building John the Ripper:
Clone the source code from GitHub:
Configure and compile the code:
If everything goes well you should now be able to run john from the run/directory:
Note: for additional instructions refer todocs/INSTALL.
Extracting hashes
The jumbo version of John the Ripper comes with a Python script calledtruecrypt2john.py. This can be used to extracthashes from a TrueCrypt volume with a command similar to the following:
The resulting file will look something like the following:
John The Ripper Pkzip2
The jumbo version of John the Ripper comes with a Python script calledtruecrypt2john.py. This can be used to extracthashes from a TrueCrypt volume with a command similar to the following:
The resulting file will look something like the following:
John The Ripper Pkzip2
There are multiple hashes for a single volume because it's not possible totell which hashing algorithm was used. If you do remember which algorithm wasused it's worth deleting the unused hashes as this will make running johnquicker.
Generating a wordlist
Once you've run truecrypt2john, the hard part is coming up with a wordlist.In my case I knew the passphrase was a combination of a few passwords joinedtogether. I used the following script to generate a wordlist with everypossible two or three word combination:
Running the script generated a wordlist with 810 possible passphrases:
John The Ripper Nt Hash
Note: if you just want a list of dictionary words you can use/usr/share/dict/words, assuming you've got the words package installed. Youcould also look at using a wordlist generation tool like crunch.
Running john
Once you've got a wordlist, john can be used to try to brute force thepassword:
If everything goes well the --show option will print any matches:
John The Ripper Crack Hashes
Note: for obvious reasons this post doesn't use real passwords!
