The rule-based attack (-a 0 with one or more -r rules files) 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. (However, note that while the *functions* are compatible, their “arguments” (the character sets that can be passed to them) may differ, which means that one cannot just take a list of complex John the Ripper rulesets and run them with hashcat.)

• * Indicates that N starts at 0. For character positions other than 0-9 use A-Z (A=10)
• + Indicates that this rule is implemented in hashcat-legacy (non-OpenCL CPU) only.
• # Changed in oclHashcat v1.37 → v1.38 and hashcat v0.51 → v0.52

Note: Reject rules only work either with hashcat-legacy, or when using “-j” or “-k” with hashcat. They will not work as regular rules (in a rule file) with hashcat.

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

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

• * Indicates that N starts at 0. For character positions other than 0-9 use A-Z (A=10)
• + Only in JtR?
• # In beta or not yet released

You can use '\xNN' syntax to use hex bytes in rules.

$ echo "Penguin" | hashcat -j '$\x64' --stdout
Penguind

This is useful for non-printable ASCII characters, multibyte work, etc.

You may need to use double quotes for the rule with some shells (Windows Command Prompt, etc.)

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

You can also specify the pool of functions that the rule engine will select from:

--generate-rules-func-sel=[function list]

… such as:

--generate-rules-func-sel=ioTlc

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

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.

At high rates of cracking per second, this may slow down cracking a little bit. At lower rates of cracking per second, the impact is probably negligible.

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 candidate generator. That means that if we have some external program that supports reading from stdin we can feed it with our output.

The 'p' character position code (see Github here) memorizes the position of the Nth instance of a character, and makes that position available for use in rules that work with positions within the string. 'p' becomes available automatically when using '%' (reject plains unless they have at least X occurrences of a specific character) and '/' (reject plains that do not contain a specific character).

If you only want to operate on the first instance of a character, you can use %1s, or simply use '/':

$ echo -n 'Odessa77' | hashcat --stdout -j '%1s Dp ip$'
Ode$sa77
$ echo -n 'Odessa77' | hashcat --stdout -j '/s Dp ip$'
Ode$sa77

If you only want to operate on the second instance:

$ echo -n 'Odessa77' | hashcat --stdout -j '%2s Dp ip$'
Odes$a77

… etc. Unlike the 's' rule, which replaces all instances of a character, this allows selection of which instance of a character to replace.

You can also use this functionality to replace one character with multiple characters:

$ echo -n 'p@ssW0rd' | hashcat --stdout -j '%1W DpM ip/ ip\ ip/ ip\'
p@ss\/\/0rd

Note that rules that use the 'p' character position code only works using the '-j' or '-k' command-line options.

In the examples below, the '%2s' portion of the rule means “reject plains unless they have at least two 's' characters:, and the 'p' then means “operate on the position represented by the second 's' character”.

See rules/ folder in hashcat-legacy or hashcat for examples.

With release of old 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.

$ cat 123.rule
$1
$2
$3

$ cat abc.rule
$a
$b
$c

$ hashcat --stdout -r 123.rule -r abc.rule wordlist
hashcat1a
hashcat2a
hashcat3a
hashcat1b
hashcat2b
hashcat3b
hashcat1c
hashcat2c
hashcat3c

Because the total number of generated rules is the product of all lists, stacking multiple large lists can quickly exceed available memory. But a few well-chosen rules can be stacked to great effect.

This attack is currently supported by:

• hashcat
• hashcat-legacy

With hashcat, the number of functions of a single rule line and the overall number of functions of multi-rules is limited to 31.