Salt brute-force feature:  --regen-lost-salts

This option will allow hashes to be cracked even where the salt, normally
stored together with the hash, was somehow lost.  Normally a cracker would not
be able to attack such hashes.  Using this feature, only supported for dynamic
formats (including "dynamic compiler" ones), JtR will load the hashes and
brute-force all possible salts for each.

Obviously this comes at a price - but not always:  If you attack a single hash
with 1000 possible salts, it will end up with same same p/s as an attack on
1000 uniquly salted hashes.  If on the other hand the number of hashes is
larger than 1000, you'll end up with no penalty (well, until you've cracked so
many that there are less than 1000 left to crack) and for very short salt
sizes and/or large number of hashes, normal "same-salt boosts" may even apply.

The feature should only be used with bare hashes input, meaning the ciphertext
should be, for example, raw hex such as d3d9446802a44259755d38e6d163e820 without
any tag such as the "$dynamic_xx$" prefix and obviously without the "$babe" salt
suffix.  Other fields such as login/gecos are optionally supported though, just
like they always are:

	user:d3d9446802a44259755d38e6d163e820:101:100:Joe Random Luser

All salts should be missing in the input file; Mixing missing-salt hashes with
correctly salted ones in one same session is not supported.

Usage:
--regen-lost-salts=<type>:<hash_sz>:<mask>

Showing cracked hashes:
Use --show as usual, but also include the full --regen-lost-salts parameters
used while cracking them.  This is required in order to match the pot file
entries (which have a format tag and the correct salt appended) to the bare
hashes input.


Detailed example:
--regen-lost-salts=dynamic_9:32:?d?d?d-
or, using dynamic compiler mode:
--regen-lost-salts='@dynamic=md5($s.md5($p))@:32:?d?d?d-'

The above command will run on a set of 32 byte 'raw' hashes, but which are known
to contain media-wiki hashes.  Media-wiki is of the format md5(salt.-.md5(pass))
the salt is a decimal number (it actually was the user id of the wiki user). There
is a dash separating the salt and the md5(pass) part.  What this regen-lost-salts
line does, is checks all 3 digit salts (appending the '-' char also), and uses
the dynamic format 9 (which is md5($s.md5($p)) that is 'almost' correct.  By our
adding the '-' character to the salt as a constant, dynamic_9 works just fine.

So that 'parts' of the --regen-lost-salts are:
  type    - this will be some dynamic type. dynamic_4, dynamic_9, dynamic_1234 are
            all the valid types.  Also @dynamic=expression@ syntax works as expected.
  hash_sz - this is the hex length of the data.  It MUST match the proper input
            size for the format AND must match the data being processed (hashes
            where the salts were lost).  If the data is only 32 bytes long, but
            the hashes were from sha256($s.$p), then a proper dynamic script would
            have to be created, that only used 32 bytes of input. There are examples
            of this in dynamic.conf at the present time.
  mask    - this is a mask of the salt.  The user will have to know how the salts
            were laid out for this format. The user will need to know if there are
            any 'constant' values, know the range of possible bytes in other positions
            and other things.  NOTE, only shorter hashes will be able to be found,
            and ones where smaller ranges of values.  JtR, when run in this mode,
            will load all hashes, and create ALL possible salts and link up every
            single input candidate to ALL possible hashes. So if there are 6 byte
            salts, and these are all decimal digits, then there will be 10^6 salt
            records created (1 million, each taking 12+ bytes of memory, plus other
            memory overhead).  If this was a 6 digit salt, that used 95 possible
            characters each, then it would require 95^6 salt records, which is
            735 BILLION salts, or almost 9 TRILLION bytes of memory.  The regen
            salt code will NOT work for salts this large.

Here are more details about the mask value:
- Note that these mask placeholders often differ from what is used by mask mode
  and other parts of John.  For backward compatibility reasons, we are reluctant
  to change this.
- mask can contain static bytes. These will simply always be output. The example
  above did this with the '-' character in the last spot.
- the mask can use different 'character class' bytes.  These are similar to the
  character types within JtR rules.  To set a 'class' for a specific byte location,
  simply use 2 characters, a question mark, and the class character.
  Here are the classes.
    ??  - becomes a single ? char (2 question marks mean a literal question mark)
    ?d  - decimal digits [0-9]  ** very common salt **
    ?l  - lower case letters [a-z]  (only ANSI lower case, does not take encodings
          into account)
    ?u  - upper case letters [A-Z]
    ?a  - upper / lower case letters [a-zA-Z]
    ?h  - hex lower case [0-9a-f]  ** common salt **
    ?H  - hex upper case [0-9A-F]
    ?x  - hex upper and lower case [0-9a-fA-F]
    ?b  - binary 0 or 1  (text 0x30 or 0x31)
    ?o  - octal [0-7]
    ?n  - upper / lower case letters and numbers [a-zA-Z0-9]
    ?y  - 95 byte ASCII  [ -~]  (from space to ~ chars). ** very common salt **
    ?#  - # is a digit, from 0 to 9  This will load a 'user defined' character class
          from the john.conf file.  so ?0 will load the this user class:
          [Regen_Salts_UserClasses] / 0=    class

With this information in hand, we can look back at that original example given:

--regen-lost-salts=dynamic_9:32:?d?d?d-   --format=dynamic_9

We can optimize this, with a little insite (speeding things up 10% in the process).
Knowing that mediawiki assigns the user account number as the salt, we know that we
will never have these salts 000- to 099-   So we can redo this regen in this manner.

in john.conf, add a 1= line to Regen_Salts_UserClasses like this:

[Regen_Salts_UserClasses]
1 = [1-9]

now, use this command line for john:

--regen-lost-salts=dynamic_9:32:?1?d?d-   --format=dynamic_9

This will use the user class-1 for the first byte, then digits for the other 2.


An ancient version of the code used a single 'type' digit to specify what format
to attack.  This still works but is deprecated:

There are only a few types supported.  To properly run, you MUST use one of the
proper types in the -format=type command, AND use the -regen-lost-salts=N with
N being set properly.  The valid N's are:
  --regen-lost-salts=1 --format=PHPS         (form md5($p.$s) s is 3 bytes)
  --regen-lost-salts=2 --format=OSC          (form md5($s.$p) s is 2 bytes)
  --regen-lost-salts=3 --format=mediawiki    (user id's from 0 to 999)
  --regen-lost-salts=4 --format=mediawiki    (user id's from 1000 to 9999)
  --regen-lost-salts=5 --format=mediawiki    (user id's from 10000 to 99999)
For types 3, 4, 5, we only look for numeric user id's, of the type:
md5($u.'-'.md5($p)) Mediawiki made some changes to use longer 8 byte hex strings
as salts.  This salt is too long to try to find, so JtR only focuses on the older
type $B$ with the shorter numeric user id's.   The found lines in john.pot will
be output as type $dynamic_2$ for the found PHPS (with the salts filled in). It
will be $dynamic_4$ for the OSC (with salt), and $dynamic_9$ (with user id as
salt), for the mediawiki items.

NOTE, normally the salt is preserved with the hash, and thus JtR can properly
find them using 'normal' methods.  This new functionality was added to handle
leaked hashes where the original salt has been lost.  It is VERY slow to run
in this manner, due to JtR having to check every possible salt, but it does
allow these hashes to be cracked 'properly'.
