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

[A1131]

In my benchmarks, greedy-selection throughput increased from so far so fast 65.23 rules/s to 244.4 rules/s — approximately 3.75x faster, representing a 274.7% increase in throughput after last update.

Latest benchmark

• Hash table build: 96.07s (vectorized, one-time)
• Upper-bound pass: 977 batches in 1:57 (8.3 batch/s)
• Greedy selection: 250,000 rules in 17:03
• Average: 244.4 rules/s
• 37,447,343 / 57,238,127 cracked entries covered — 65.42%

Key changes

• Upgraded the GPU kernels and cracked-target hash table from 32-bit to 64-bit FNV-1a fingerprints, reducing collision risk at tens-of-millions scale. The unique target fingerprint count increased from 56,857,388 to 57,238,127 (+380,739, or ~0.67%). This also suggests the earlier 98.7% coverage figure was likely inflated by 32-bit fingerprint collisions rather than reflecting actual password coverage, which may also have distorted scoring and contributed to the observed throughput difference.

• Improved hash-table slot distribution. The previous 32-bit slot hash (key * 2654435761) was replaced by a SplitMix64-based mixing function (mix64(key)) before masking the result to the table size. This is designed to improve slot distribution and reduce clustering and linear-probing overhead.

• Retained GPU-resident open addressing with a separate occupancy bitset. The table uses a maximum 50% load factor, and the matching slot directly identifies the bit used to track whether a cracked target is still uncovered. The earlier implementation already used open addressing; the update improved the fingerprint width and slot-hashing method rather than introducing the table from scratch.

• In addition, the benchmarked coverage of recovered entries improved by approximately 0.5-2 percentage points in the comparable test.

• Minor UI cleanups, such as normalizing progress bars, were also included.