This is an old revision of the document!
Wish-list for JtR
-
Support for kerberos etype 1 (des-cbc-crc) and etype 3 (des-cbc-md5) (
ref)
-
Java KeyStore cracker (partially done, patches welcome!)
-
GNOME Keyring OpenCL format
KeePass OpenCL format
The Bat! cracker
Intuit Quicken
RAR5 support (partially done, patches welcome!)
SIMD support in scrypt format
RipeMD-320(HMAC), used by Lenel OnGuard, PasswordPro supports this already NOTE, ripemd320 is now supported in JtR.
7-Zip Archives (partially done, patches welcome!)
Apache Derby
Features/enhancements
Add Unicode support for is_mixedcase() in inc.c (not performance critical).
Add generic tag-alias handling to dynamic, so eg. a thin format or a user defined or preloaded one could specify its format_tag. It would enable a format to recognize both “$dynamic_nn$” and “$postgre$” in input files as well as pot files but always output the latter.
Re-write wordlist.c, possibly using
fgets-sse2 while at it.
Try to interleave the BLAKE2 code, just like done with MD4/MD5/SHA1 in sse-intrinsics.c.
Re-work and enhance the Unicode/codepage stuff:
Instead of options.ascii, options.utf8, options.iso-8859-1 and so on, use a bit-field or an array. This is a need for #3.
Instead of static arrays, allocate and initialize dynamic arrays as needed (when possible). Especially for #3:
In addition to just enc_to_utf8() and utf8_to_enc(), implement enc1_to_enc2().
Implement a –hashed-encoding option, using #3. The current –encoding option basically specifies the encoding of the wordlist. This new option would specify what encoding was used when the passwords were hashed. This would make it possible to, for example, use an ISO-8859-1 wordlist as input for an 8-bit format that needs cp850.
-
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.
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.
-
'Auto' Optimization of Rules at run-time prior to running rules (at rules init).
argc/argv for external modes
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 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)
-
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]” as last line of rule xx in john.conf.
-
-
Add a rule that performs “stripping” of codepage characters like é → e and č → c. This is easy using Unicode decomposition and just using the base character.
-
(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:
Load options from command line. Do NOT perform any work based upon these options, NOR any validation. Simply load them blindly.
Load the john.conf file data. The location of john.conf 'may' have been set in loading the options from command line.
Update options from john.conf using any 'defaults' in the john.conf file.
'Re' load the options from the command line. This is so we override 'defaults' from the john.conf with command line overrides.
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 ?
Issues/bugs needing a look
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.
BUG in MANY formats. valid / prepare / split are way too promiscuous for many formats. This allows mis dectections, and worse allows garbage to pass as valid, to cause all sorts of problems, like memory overwrites, crashes, etc, when the data is later loaded. There is a wiki page added with many examples:
Formats with problems
Wish-list for JtR Test Suite
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).
Back to: