Brain

The brain remembers the candidate work already done against a hash list, so an attack does not repeat it. That holds whether you are cracking alone over several sessions or a team is sharing the work over a network. No machine learning is involved, despite the name.

It keeps two in-memory databases, short-term and long-term. A candidate is hashed with paw64 and lands in short-term memory first. When the batch it belongs to finishes, the client commits and the server moves those candidates into long-term memory.

It is a client and server, and even for one machine you run both:

$ hashcat --brain-server
$ hashcat -z --brain-host 127.0.0.1 --brain-password secret -m 22000 hashes.hc22000 wordlist.txt

The port defaults to 6863. Attack modes 0, 1, 3, 4, 5, 6, 7, 8 and 12 are supported. The association attack, -a 9, is not.

--brain-client-features picks what a client tracks, and the choice decides whether the brain is worth using:

• 3, the default, checks individual candidates. That needs the candidates on the host, so it switches on -S and suits a slow hash.
• 2 reserves whole keyspace ranges instead. It needs no candidates on the host and leaves generation on the device, so it adds little overhead to a fast attack.

So the brain is a poor fit for a fast hash at the default setting, where the bookkeeping outweighs the duplicate work it saves.

The protocol moved to version 2 in hashcat 8.0.0. Clients and the server have to be upgraded together, and a mismatch reports both versions. Session identities changed with it, so an existing database stays on disk but is not loaded and a reused --brain-session starts with empty deduplication data.

A build can leave the networking code out entirely with ENABLE_BRAIN=0.

• docs/hashcat-brain.md, which includes worked examples of what gets skipped within and across attacks