Hashcat Rule Ranker – GPU-accelerated ranking of Hashcat rules

[A1131]

A tool that evaluates and ranks Hashcat rules against a wordlist + a list of known cracked passwords.

• GPU (OpenCL – NVIDIA/AMD/Intel)

• Multi-Armed Bandit (Thompson Sampling) with early elimination of weak rules → much faster on large rulesets or legacy exhaustive run

• Optional CELF post-processing (max-coverage) – selects the smallest, most efficient set of rules instead of a plain top-K

• Three strategy's: bitmap, recompute-gpu, sparse

• Handler for quick analysis and merging results from multiple runs
Output: ranked CSV + ready-to-use optimized .rule file.

GitHub: https://github.com/A113L/ranker

Credits:
@Vavaldi for coverage optimization inspiration

[A1131]

On the results of ranker x1.greedy vs a1131.greedy rulesets

# head x1.greedy_top50000.rule
: 
T0 T2 T4 T6 T8 TA TC $1 $2
l
x12
c'1$s18
“A$p t
T0 T6 TA $3
T0 T5 TA 1 $2 $3
R2
-9x35 ^f

# head a1131.greedy.25000.rule
: 
l
T0
$1
K
]
$1 $2 $3
$4
$2
+2

# head a1131.greedy_top50000.r1.rule
: 
] $a
[$1
[$9
[$8
[$7
[$4
[$3
[ [ $6
[ [ $5

As can be seen above, the rules obtained using the ranker (with CELF) are not only diverse, but also deliver very similar results at the identical cut-offs of 10k / 25k / 50k.

Rule	Hit rate	Size	AVG Time	Eff.
a1131.greedy.10000.rule	22.75%	10 000	25 352	2.275
x1.greedy_top10000.rule	22.56%	10 001	501.44	2.2558
a1131.greedy.25000.rule	28.60%	25 000	31 879	1.144
x1.greedy_top25000.rule	28.46%	25 001	25 832.06	1.1384
a1131.greedy_top50000.r1.rule	33.60%	50 001	16 987.14	0.672
x1.greedy_top50000.rule	33.05%	50 001	21 051.92	0.661

Ranker + CELF generates rulesets with very similar effectiveness (differences of only 0.14–0.55 pp), while being more diverse and less redundant. At the 10k/25k/50k cut-offs the results are practically equivalent.

Full Benchmark

[A1131]

CELF + heap: ~4-9 rules/s -> ~50-80 rules/s on RTX 3060 Ti

After switching to a lazy heap (instead of a list scanned linearly against fixed upper bounds), average selection speed jumped from 4-9 rules/s to 50-80 rules/s (~6-20x, roughly 10x sustained over a full run at 65 rules/s avg).

Reason for the speedup: the old approach had to rescore more and more candidates on GPU each round, because their upper bounds went stale as the active set shrank. The heap always keeps the tightest known bound on top and lets a round end as soon as the popped candidate's exact gain beats the next-best bound — most rounds now finish with 0-1 extra GPU dispatch instead of a full scan over all candidates.

Tip: the upper-bound pass (stage 1, where the heap is built) scales with wordlist size, since every candidate is scored against the full resident wordlist. Running stage 1 against a smaller/more targeted wordlist speeds up the heap build and greedy selection noticeably — worth doing if you don't need the full wordlist's coverage resolution for the initial bound estimate.

Run stats: (1M candidate rules — top-scored candidates taken from a prior rank run's output, fed into postprocess/CELF; 56.8M-entry cracked universe (hashmob.large.found),for heap build hashmob.mini.found was used, RTX 3060 Ti):

• Hash table build: 72.5s (vectorized, one-time)
• Upper-bound pass: 977 batches in 1:55 (8.49 batch/s)
• Greedy select: 150,000 rules in 38:19 → 65.23 rules/s avg
• Covered 56,111,301 / 56,857,388 cracked entries (98.7%) with those 150k rules
• No coverage matrix allocated at any point (RAM or disk) — memory stayed O(n_rules) + O(universe bits)

Note: the 1M candidates aren't a random/full rule space — rank already individually scores and ranks rules first (by Combined_Score), and CELF then picks a redundancy-free subset from that pre-filtered top-N pool. So the heap/recompute speedup here is specifically for the second-stage max-coverage selection, on top of whatever rank already narrowed down.

See heaped*.rule's in benchmark. heaped_top150000.rule is available here