DEBUGGING RULES
FOR EFFICIENCY

Once sorting is complete you will be dropped into a submenu where you can find the Pareto curve analysis along with milestone breakpoints showing exactly how many rules are needed to cover a given percentage of the entire initial dataset.

Pareto milestones from concentrator — rules needed to reach each coverage percentage of the full 887K-rule corpus (21.4M total occurrences).

This makes it straightforward to cut the ruleset down to a practical size — for most cracking jobs the top 1–5% of rules by frequency covers the vast majority of real-world hits.

Using the Pareto milestones as cut points, four rule files were produced — one for each practical use case, from a large comprehensive set down to a tiny high-precision set:

$ wc -l *.rule
 500001 rulest_large.rule
 150001 rulest_medium.rule
  25001 rulest_small.rule
    251 rulest_tiny.rule
 675254 total

Results from the rules comparison spreadsheet. Each of the four output files is compared against the best-in-class rule set in its weight category, and against other existing rulest_* variants.

The existing rulest_* family in the benchmark includes rulest_rules_strip_1p7m (44.65%, 1.7M rules), rulest_rules_strip_1p1m (43.98%, 1.1M rules), rulest_rules_strip (38.10%, 332k rules), rulest_rules_ga (31.76%, 643k rules), and rulest_rules_no_ga (31.35%, 329k rules). The new rulest_large at 500k sits right in the middle of that family — better recovery than the strip and GA variants while being a fraction of the size of the 1M+ strip files. A good trade-off for most use cases.

The benchmark leaderboard has expanded significantly. New top entries include Fordyv4a (56.94%, 4M rules), Fordyv4b (56.28%, 6.9M rules), A11313M (53.97%, 3.2M rules), sapphire_v1 (52.06%, 1.27M rules), and CakeV1 (52.04%, 1M rules). These large rule sets push the ceiling considerably above the previous 48–49% range. The rulest_* output files remain competitive within their respective size categories, but the top of the overall leaderboard is now materially higher.

One thing worth highlighting: rulest runs comfortably on cards with less than 4 GB of VRAM. The entire ruleflow — rule generation, debug pass, concentrator analysis — can be run on modest hardware most people already own. You don't need a flagship GPU to produce a competitive rule set. The debug pass itself is the most time-consuming part, but even that is a one-time cost. The resulting files can then be reused across any number of jobs at no additional overhead.

Combined with the Pareto insight that a few thousand high-frequency rules cover a disproportionate share of real-world hashes, this means the barrier to having solid, personalized rule sets is much lower than it appears.

After a short break — and fixing a few bugs in rulest related to generation and validation — I decided to run a quick second round (tagged r1) using the rules already acquired, this time debugging against the hashmob.tiny.found dictionary (~2 MB) rather than a full-size corpus. The rule pool itself was also refined and capped at depth 1–8 instead of the previous 1–10.

Trimming the maximum chain length is a deliberate compromise, not a step back. Longer rules are disproportionately expensive to debug and score worse against a large hash database once the operator count climbs, so they yield fewer matches per unit of debug time. Capping at 8 keeps the rule space dense where it's actually worthwhile — this was somewhat confirmed by getting 6.75M rules out of seven rulest runs using comparatively small input files. That first approach was roughly hashmob.mini vs. rockyou in scale. For comparison, rulest on hashmob.micro vs. hashmob.small alone extracts 3.2M+ deduplicated rules in balanced RCR mode at the default depth of 6 — plenty to justify a debug pass as a first filtering step.

$ wc -l rulest2debug_r1.rule
6748072 rulest2debug_r1.rule

$ ls -lh hashmob.tiny.found
-rw-r--r-- 1 user user 2.0M hashmob.tiny.found

Output of the concentrator Pareto pass on the r1 debug run — 1,256,836 unique rules with 35,020,748 total occurrences. Unsurprisingly, the top ten are all classic insecure number-append patterns.

Same shape as before, just a bigger pool underneath: 579 rules already reach 10% of total occurrences, and half the value sits in under 46k rules out of 1.26M total — even denser at the head than the previous r0 pass.

The four r1 rule files are cut straight off the milestone breakpoints above — large ≈ 95%, medium ≈ 80%, small ≈ 40%, tiny ≈ 10% of cumulative coverage.

$ wc -l *_r1.rule
 513641 rulest_large_r1.rule
 179166 rulest_medium_r1.rule
  25730 rulest_small_r1.rule
    585 rulest_tiny_r1.rule
 719122 total

Real numbers from the rules comparison spreadsheet, run against all four r1 rule files.

A short clip from the debug session, left here as a curiosity — just a few seconds of the hashcat debug pass itself.