The rule-based attack is one of the most complicated of all the attack modes. The reason for this is very simple. The rule-based attack is like a programming language designed for password candidate generation. It has functions to modify, cut or extend words and has conditional operators to skip some, etc. That makes it the most flexible, accurate and efficient attack.

Why re-invent the wheel? Simple answer: regular expressions are too slow. Typically we have to generate 1.000.000.000 (or more) fresh password candidates in less than 10 ms before hashing algorithms start to become idle, and then again and again, second after second. Just take a look at your GPU speed display to get an idea of it.

The rule-engine in Hashcat was written so that all functions that share the same letter-name are 100% compatible to John the Ripper and PasswordsPro rules and vice versa. Later we started to introduce some of our own functions that are not compatible. But these functions got their own letter-names to avoid conflicts.

The following functions are 100% compatible to John the Ripper and PasswordsPro:

• * Indicates that N starts at 0. For character positions other than 0-9 use A-Z (A=11)
• + Indicates that this rule is implemented in hashcat only.

The following functions are not available in John the Ripper and PasswordsPro:

• * Indicates that N starts at 0. For character positions other than 0-9 use A-Z (A=11)

The most important thing in writing rules is knowing what you want to write. That typically means you have to analyze dozens of plaintext passwords, maybe from a customer, to see a pattern. For example, a common pattern is that people append a digit to their passwords to improve its strength. So we have two “parameters”:

• We want to append something.
• The value we want to append is a digit.

If we take a look at the function overview we see that we can append something using the '$' function. So, for example, if we want to add a “1” to our password, we write a rule that looks like this.

$1

Simple enough. But what if we want to do all numbers 1 - 9? Well thats what we call a Hybrid attack, just take a look at this page.

Also note:

• White spaces are ignored as long as they are not used as a parameter. That enables formating of our “source code” a bit.
• To comment out some text, it has to start with a ”#” char.

There are two ways to automatically “generate” rules.

• Using the maskprocessor, we have a dedicated article on this topic here: Using maskprocessor to create rules.
• Using random rules, see below.

This is a very unique hashcat feature. With hashcat you can generate random rules on the fly to be used for that session. This is a good thing if you are out of ideas on what to do next when you have already tried all your rules on all your dictionaries. There are three configuration parameters:

Tells hashcat to generate NUM rules to be applied to each attempt:

--generate-rules=NUM

Specifies the number of functions that should be used (minimum to maximum range):

--generate-rules-func-min=NUM 
--generate-rules-func-max=NUM

This number can be unlimited but large numbers are not recommended. When used in conjunction with –g, any rule outside of this setting will be ignored.

For example, it could randomly generate the rules “l r”, “l ^f”, and “sa@”, these are all valid rules to be used. However, “l ^f sa@ r $3” would be ignored as it contains 5 functions. Default: min=1 max=4

You can mix your rules from a rules-file with randomly generated rules. For example, if your rules-file contains 200 rules and you use -g 500, it will generate 300 additional rules.

This becomes handy especially in combination with the rules generator but also for statistical analysis of your rule sets.

To save any rule that generated a matched password use these switches:

--debug-mode=1 --debug-file=matched.rule

This will save the matched rule on every match, so the resulting rule file might contain many duplicate rules.

With hashcat we can debug our rules easily. That means we can verify that the rule we wrote actually does what we want it to do. All you need to use is the --stdout switch and omit the hashlist.

Here is an example:

Create simple dictionary:

$ echo WORd > word

Generate a simple rule. The “c” rule capitalizes the first letter and lower-cases the rest.

$ echo c > rule

And thats how we see the generated debug output:

$ ./hashcat-cli64.bin -r rule --stdout word
Word

This “feature” is also a very fast password candiate generator. That means that if we have some external program that supports reading from stdin we can feed it with our output.

See rules/ folder in hashcat or oclHashcat-plus for examples.

With release of oclHashcat-plus v0.07 a complete new feature in the rule-based cracking world was added.

Instead of just giving one -r parameter and a file, you can now add as many -r's as you want.

They are not executed in a sequence!

Each rule of each rule-file is combined with each rule of each rule-file. This way you can easily cook your own attack mode.

This attack is currently supported by:

• hashcat
• oclHashcat-plus