Add stuff that you think would enhance JtR to this list. Also consider writing to the mailing list about the details and link to that in here.

If you start working on one of the items, please move if to the Items being worked on section. put a note on it, listing who is doing the work, i.e. (in progress, magnum)

• Speed up init of OpenCL formats, either by pre-compiling (when building John) or caching OpenCL binary (when a format is run first time). The former would be a bad idea for distributions (eg. if Ubuntu had a john-jumbo package). Note: nvidia already has caching in their drivers.
• Unless -platform or -device is given, OpenCL should default to search for a GPU (even if it's on platform other than #0) and only failing that, resorting to CPU on platform 0, device 0.
• Truecrypt, see this and this and OTFBrutusGUI
• M$ Office <=2003 password support
• Make unique able to use >2 GB of RAM
• Mac FileVault
• Django hashes, see this (in progress, Dhiru)
• LUKS cracker, see this
• PGP secret keys (different kinds)
• 7-Zip Archives
• Apache Derby
• Better VNC hash extractor (i.e. vncpcap2john.cpp) based on Ettercap's VNC dissector.
• Keepass Databases
• GNOME Keyring
• KDE KWallet
• other kinds of SSH private keys
• make changes so that md5-mmx.S and sha1-mmx.S 32 bit asm are thread safe. Then we can use OMP on all SSE builds. MD5 should be pretty easy to add thread safety to. SHA1 may be possible, but probably more difficult. Also, change these to have the SAME interface as the intrinsic interface.
• BUG in dynamic. If there are $$Fx which pull data from some of the fields, this $$Fxdata is NOT written to the hash line, written into the john.pot file. Thus, the data to crack is lost!!! Not sure how to work around this. It does appear, if the $$U is used (user name in the format), but the $$U is not in the salt provided (thus the user name is read from array element 0), This DOES get written into the found hash line (as a $$Uuser string in the salt). Thus, this is fine. However, the $$Fx's seem to be broken. These are things 'added' to dynamic, but I am not sure anyone uses them.
• add OMP to 'dynamic' format, if possible.
• If/when implementing fork/node as seen in the experimental “j5c4” contest edition, we should export node_min, node_max and node_count to external modes.
• -verbose=x command line switch, and audit logging and fprintf(stderr…) logic. Mail list: http://www.openwall.com/lists/john-dev/2011/08/31/2
• 'Auto' Optimization of Rules at run-time prior to running rules (at rules init).
• argc/argv for external modes
• support for arbitrary characters in rules pp, eg. \xBF
• john.conf item for default mem-file-size (see comment below)
• john.conf item for default field-separator-char (see comment below)
• new rules: convert (if possible) the whole word from/to UTF-8 to/from the currently selected encoding. This will be slow but in some cases powerful.
• complete Unicode support for the rules engine (some ideas in this post)
• Add additional things into the test suite. Testing of Rules, External, etc, etc. All parts of john 'could' be tested, and reported in pass/fail manner.
• Support for auto-disabling of plugin formats. SybaseASE, hmailserver and SHA224/256/384/512 formats are currently not plugins, because they have #ifdefs relying on OpenSSL version macros. The plugin “system” currently can't handle this. Clever idea is needed here.
• Add functions in unicode.c for conversion between composed (NFC) and decomposed (NFD) versions of characters. Example: Decomposed version of LATIN SMALL LETTER A WITH DIAERESIS (U+00E4) is LATIN SMALL LETTER A (U+0061) COMBINING DIAERESIS (U+0308)
• Once the above is in place, add rules for calling them (for the whole word),
• and possibly add NFC to a couple of Unicode formats (if we confirm this is what happens IRL)
• Lower prio encodings: for Windows “OEM” & Windows “ANSI” (also see this link), Unices (ISO-8859-*) and possibly (older?) Mac. See Procedure to add a new code-page to john for how to add them.
• make 'thin' versions of more formats
• command line option to reduce max_plaintext_length (mostly for testing, does not have to be mentioned in usage blob, just in doc/OPTIONS)
• Evaluate the possibility of implementing (at command line and/or in Rules section of john.conf) “rules x rules” - eg. one ruleset who's resulting candidates go through another ruleset. Two rulesets of 100 rules each will produce up to 10,000 candidates. This is currently possible using “john … -ru:first -stdout | john -pipe -ru:second …”.
• If easily implemented, allow multiple –rules=xx –rules=yy that will be just like using ”.include [yy]” within rule xx in john.conf.
• (ON HOLD, technical issues, and no buy-in from Alex) Add new config directive .remove [section] Useful for rules, if placed at bottom, will remove any rules out of the current rules block, that were found in [section]. Sort of the inverse of .include [section]
• Consider enhancing the self-tests.
• Consider implementing some of the ideas in this thread about emitting a status line whenever a password is cracked

(magnum) A while ago, I did the john.conf changes for “mem-file-size” and “field-separator-char”, but they failed because john.conf was not yet parsed when my code did the calls to options.c functions. This is probably fairly trivial but I just got tired and ditched it for now.

(jimf) I think we will have to attack this, in this manner:

1. Load options from command line. Do NOT perform any work based upon these options, NOR any validation. Simply load them blindly.
2. Load the john.conf file data. The location of john.conf 'may' have been set in loading the options from command line.
3. Update options from john.conf using any 'defaults' in the john.conf file.
4. 'Re' load the options from the command line. This is so we override 'defaults' from the john.conf with command line overrides.
5. Now, perform option validations, and setup, memory allocation, code page setup, etc, based upon the options.

We are sort of catch-22. We need to load options prior to being able to load the john.conf. If we try to load john.conf then process options, then how do we specify a different location for john.conf ?

To avoid duplication, please list WIP items here. When an item is released, please move the line to the Items Done section.

• Integrate SIPcrack into JtR: http://www.backtrack-linux.org/wiki/index.php?title=Pentesting_VOIP&oldid=789#Cracking_SIP_Digest_response_hashes http://packetstormsecurity.org/files/author/2096/ Somehow BackTrack wiki mentions version 0.3, but Packetstorm only has version 0.2. We may integrate the existing code into a JtR format or start from scratch. SIPcrack 0.2 (and I guess 0.3 as well) is under 3-clause BSD license, which is acceptable (although not perfect). Link for SIPcrack 0.4 (internally it says 0.3) http://www.codito.de/prog/SIPcrack-0.4.tar.gz. We need some sample .pcap files to get started. (Done 12th March 2012).
• koi8-r and cp1251 encodings (and full support for iso-8859-1) (Patch v2 released July 27, 2011, JimF)
• updated test suite with CP1251/KOI8-r/CP866 (v1.06, released July 27, 2011, JimF
• cp1252 and iso-8859-15 encodings (Done, JimF)
• top-5 (or so) OEM encodings, at least cp437, cp850, cp866 and cp737. (also did cp858, since it is 850, but has euro sign). (Done, JimF)
• build a wiki tutorial page on the ”Procedure to add a new code-page to john”, to fully document just what is required to properly tie a code page into john.
• DumbForce-UTF8: Produce all allocated UCS-2 characters between U+0001 and U+FFFF, 1-4 characters (default). “Output” them as UTF-8. And another version for full Unicode. There are 54,473 codepoints for UCS-2 or 109,070 for Unicode, and we may actually exhaust 2 characters for very fast formats. Forget about 3 characters though. (Done, magnum)
• New character class y (the letter v is taken), for valid characters. There are some characters in some code pages that are not valid. 0×98 in cp1251 is such. So a rule such as !?Y would drop that word, if running under CP1251. (Done, JimF/magnum)
• Add encoding support for rules 'p' and 's' (punctuation/symbols) - eg. for ISO-8859-1, I presume these are punctuation: ¡ and ¿ - and these are symbols: ¢£¤¥¦§¨©ª«¬­®¯°±²³´µ¶·¸¹º»¼½¾×÷ (Done, JimF/magnum)
• Add some more encoding support for rules 'v' and 'c' (vowels/consonants) - however, the definition of vowels/consonants are more language-specific than encoding-specific. And even when looking at one specific language, a letter can be a vowel or consonant depending on context. (Done, magnum)
• .include “newfile.conf” in john.conf (Done). Added as patch 0001_2 to 1.7.8-jumbo-6rc1
• .include [section] in john.conf (Done). Added as patch 0001_2 to 1.7.8-jumbo-6rc1
• ->N rule-reject if format does not support length N (Done, magnum)
• md5_gen support for –enc=_codepage_ (other than UTF-8 and iso-8859-1) [until then, we should really block/warn if user tries to use it] and when this is in place, move raw-md5-unicode to unused/ (released, magnum)
• Elimination of dupe rules (goes along with .include, but also optimization). (Released, JimF)
• Make BE versions of some UTF-16 conversions (or make it an option using another argument), to avoid double bit-swapping for some format / arch combinations. (Done, magnum. Actually I found out it was already there but it was buggy)
• Add an option that will not remove a hash from the working set when it is found. Also, this switch should probably also not perform the john.pot hash removal at startup time, so any of these 'already found' hashes are not removed. This option will be useful if there are hashes which produce false positives. We do not want to finish if we are not SURE we have the password found (zip AES is one of those types at this time). ACTUALLY, this might be a good flag to add to the format. Then the format informs john that when it finds a 'password' that it may be a false positive, and john should NOT view that hash as cracked, and keep looking. Mail list: http://www.openwall.com/lists/john-users/2011/09/02/4
• Created a new format crc32 which also uses the new flag about a 'false positive' format. Crc32 certainly returns many positive equivalent values.
• md5_gen changed to 'dynamic'. Keep functionality, just change code and documentation to lose the MD5_GEN title from everything.
• command line option to reduce max_keys_per_crypt to 1. This should help when analyzing which rules result in most cracks (this is otherwise very hard to parse from the log when a format processed thousands of keys at a time) This too could be documented in doc/OPTIONS only, reducing size of usage blob. (Done, magnum)
• Mute warnings from generic crypt when loading pot file (Done, magnum)
• prepare (properly) a sse-intrisic.S file (built with ICC), which can be used for non-optimal gcc builds, to get close to equal speed given by ICC. This was done (as a hack), in the contest version of john. Do this properly, and get it into jumbo. (Done, magnum and Jim)
• use SSE2 for things like raw_md4_fmt.c There is SSE in intrisics, and building a .S file should be trivial. md5-mmx.S actually appears to have derived from md4-mmx.S, but we do not have md4-mmx.S in john (NOTE: md4-mmx is here if we want it). (Done, magnum - intrinsics only - should we do more? We better get it in dynamic instead!)
• Rework the salt processing in dynamic. Reduce memory footprint. Reduce load time, possibly increase (a little) runtime speed. The HEX$ code will be added, thus we 'could' get rid of the -field-separator= from john. Also, change dynamic_7 to use HEX$ and not worry about ':' being inside of the salt.
• Add HEX$ to dynamic salt processing. Talked about here http://www.openwall.com/lists/john-dev/2011/12/06/2, and here http://www.openwall.com/lists/john-users/2011/12/04/1. This HEX$ changes, sparked the ideas to 'rework' the salt logic. NOTE, HEX$ would only need to be used if one of these chars is present: NULL \r \n : Pretty much any other char 'should' be able to be stored in the file, and handled with native 'C' string processing functions.
• oracle11 intrinsics (Pushed to git, magnum)
• Add MD4 support to dynamic format. We already have the intrinsics, and there is also an mdfourmmx() published here. Key setup and usage are identical to MD5 so it's “just” a matter of putting it in there… After this, we could ditch two-three old formats in favor of thin ones. (Done, JimF)
• sapG intrinsics (done, magnum)
• sapB intrinsics (done, magnum)
• Time-limited runs, eg. ”–max-time=3600” (done, magnum)
• HDAA intrinsics & OMP (done, magnum)
• Make Wordlist mode handle .pot file specially (done, magnum).
• Fix wordlist truncation when not in buffer mode (done, magnum)
• IPB2 intrinsics & OMP (done, magnum)
• Drupal 7 (done, magnum).
• RAR -p support and OMP (magnum)
• RAR OpenCL support (magnum)
• M$ Office password support (done, Dhiru)
• Mac keychains (done, Dhiru)
• WPA (in progress, Lukas)
• Password Safe, see Password Safe (done, Dhiru)
• Dynamic bash-completion scripts for JtR - for example, bash should suggest/complete when you type the option –rules= and then press TAB twice. This might be tricky as you can give one or two dashes, abbreviate “rules” or say : instead of = etc. but it can be done. It didn't get easier after we got .include though :) (See this thread) (Done, Frank)

• Add support for static extra arguments given to jtrts.pl, that is just passed as-is to john. Eg. –gpu=1 or –max-time=60.
• Add cuda/opencl capability detection (ie. grep for cuda/opencl in JohnUsage.Scr).
• Add support for stopping on error found, and keeping the .pot files. This way you can manually check what was missed. Ideally jtrts should even be able to help with that diagnose (eg. “all misses were of length 28 or above” or at least just list uncracked lines from input).
• Add length test files (eg. just 0..125 dots, 0..125 pound signs in ANSI, 0..125 euro signs in UTF-8 and so on). The result is “format handled up to length nn”)
• Add test files that should be cracked in (say) 5 secs of –incremental. Very slow formats could use almost all candidates while very fast formats could use 1/100,000 or whatever.
• Add test files that needs –rules for being cracked.
• Add test files that can be cracked using an external mode (eg. -ext:subsets).
• Possibly generate some/most/all of these input files on the fly, with a tighter integration of pass_gen.pl. This could also mean jtrts could itself adjust input files according to max plaintext length of a particular format.

• DONE (v1.10) Mute (or overwrite, using \r) most of the output as long as no fault is found. I use to check all builds like this, but it's hard to spot a single failure in all output:

for i in generic linux-x86-64-32-any linux-x86-64-32-mmx linux-x86-64-32-sse2 linux-x86-64-32-sse2i linux-x86-64 linux-x86-64i; do
    (make clean ; make -j2 $i) >/dev/null &&
    make test_full
done

• DONE (v1.10) It would be VERY nice if you could say ”./tstall FORMAT”, which would just test that format, but including all encodings etc. if applicable.

http://openwall.info/wiki/john/patches

http://openwall.info/wiki/john