hashcat-request

Feature request:

The ability to 'minus' previously eliminated keyspace when using a brute-force/mask attack. For a simple example: a password known to be 6 characters long stored in md5 has the following mask attack run:

hashcat -a 3 -<hash> ?l?l?l?l?l?l                        #  all lowercase letters

This attack does not result in recovery of the password.  Next, we want to run the following mask:

hashcat -a 3  <hash> ?1?1?1?1?1?1 -1 ?l?u      # uppercase or lowercase letters

Since the first run mask is completely contained in the second (e.g. is a subset of), hashcat will currently perform this work twice.  The addition of the ability to specify previously eliminated keyspace with a flag or command line argument, would prevent this double work.  In our example (using --elim for the flag):

hashcat -a 3 <hash> ?1?1?1?1?1?1 -1 ?l?u --elim ?l?l?l?l?l?l
  # uppercase or lowercase minus all lowercase

The proposed command above would presumably complete faster, as it now has to perform less work.  If you could then stack additional masks into this 'elim' argument using a delimiter (suggestion ",") as additional keyspace is eliminated, it could have the effect of possibly significantly cut down the work/time needed for a full "?a" mask after all lower keyspace attacks do not bear results.  For our example, if "all lowercase" and "all digits" had been previously eliminated, the following command should complete quicker than just  a straight full "?a" mask attack:

hashcat -a 3 <hash> ?a?a?a?a?a?a -elim ?l?l?l?l?l?l,?d?d?d?d?d?d
 # uppercase, lowercase, or digits minus all lowercase and all digits

Continuing examples assume the following notation:
hashcat -a 3 <hash> <A> -elim <B>

In order for this to work (actually eliminate work/time), the masks specified in '-elim'  (B) would need to be able to be quickly checked to be a subset of the mask specified primarily (A). For the first examples above, it would of course be easy to just put in logic defining ?l (B) as a subset of ?a. (A)  More complicated masks involving custom defined characters (eg. "1") might become more complicated to compare, especially when eliminating multiple masks. The simplest thing  to handle custom characters may be to force them to remain consistent between the primary mask (A) and the -elim masks (B).  The character length would also need to be consistent between A and B during comparison, and I am uncertain how this would work with the -i flag (although it could work similarly to how "increment" currently works with masks, comparing only 'n' characters, and then n++).  A simple set of logic rules defining [?l?u?d] and [?h?H] both as a subset of [?a], and [?a] as a subset of [?b] might be enough to quickly compare each mask character and proceed.


The real value in adding this feature, is when hashcat is combined with a distributed solution (an example of which would be 'hashtopolis' - https://github.com/s3inlc/hashtopolis) that already includes full jobs management features including storing history of previously run jobs.  This would allow the distributed solution to 'keep track' of work previously performed, and automatically eliminate it in future attacks.