pcfg-go v0.6.0-dev (upcoming release) https://github.com/cyclone-github/pcfg-go/commit/8fb59c2 While I was testing hashcat's new -a 4 PCFG mode with different hash lists and Rules trained with pcfg-go, @atom mentioned something to me that I couldn't shake: "that needs a fast trainer". But, pcfg-go was already fast, right? How much faster did it need to be? I was determined to find the answer to this question and pored over possible optimizations in pcfg-go, optimizing keyboard walks, buffers, worker scheduling, profiling hot paths and reducing GC pressure, testing / benchmarking / and comparing Rule outputs to make sure the optimized trainer still produced 1:1 byte-level-identical Rules to v0.5.3. The result? Let's first back up a minute to run a few comparisons. The original python3 pcfg_cracker trainer.py by @lakiw took 13m21s to train rockyou on my Debian 13 benchmarks pcfg-go v0.5.3 brought rockyou training down to 2m38s And finally, pcfg-go v0.6.0-dev brings rockyou training down to 14.8s Yes, from 13m21s to 14.8s. Now, that's a fast trainer. [image: 1787772381003-9dc5d6d5-4ed8-4d6b-826f-b095be9997b0-image.jpeg] A big thanks to @atom for his support, suggestions, and kindness, and @lakiw for giving the world pcfg_cracker in the first place.

https://github.com/cyclone-github/hashgen/releases/tag/v1.3.2 v1.3.2; 2026-08-18 add mode: gost-yescrypt add mode: SSHA -m 111 add mode: sha1crypt -m 15100 add mode: sm3crypt -m 35100 add mode: cmiyc (KoreLogic CMIYC 2026 contest algorithm) add modes: Streebog/GOST 2012 -m 11700, 11750, 11760, 11800, 11850, 11860 add modes: SHA-384 UTF-16LE -m 10830, 10840, 10870 add modes: LDAP SHA/SSHA -m 101, 1411, 1711 add modes: -m 3500, 4300, 4400, 4700, 18500, 18501, 20800, 32800, 34400, 34500, 35900 refactor modes: -m 2600 and 4500 add bcrypt prehash modes: -m 25600, 25800, 28400, 30600 add bcrypt aliases: bcryptmd5, bcryptsha1, bcryptsha512, bcryptsha256 add hashcat alias: wpbcrypt -m 35500 v1.3.1; 2026-04-13 add modes: MD6-128, MD6-224, MD6-256, MD6-384, MD6-512

@v1cvap0r Targinator currently calls runtime.NumCPU() for parallel processing which defaults to all available CPU threads. Adding an option to allow user-specified CPU threads is an option, but not currently implemented.

Informative write up which gives a different perspective than "the norm". I've also used Waffle's rling since it was publicly released and it has earned a well deserved place in my favorite tools post.

@v1cvap0r duplicut - dedupes a single wordlist without changing its order: ./duplicut wordlist.txt -o dedup_wordlist.txt rling - similar capability to duplicut: ./rling wordlist.txt dedup_wordlist.txt but also can remove dups from multiple files and save the dedup output to file like the example below from the GitHub page: ./rling big-file.txt new-file.txt /path/to/old-file.txt /path/to/others/*