Brain as a centralized potfile?

[mtnsec]

I'm still trying to understand the brain, so hopefully this question makes sense:

Looking at the features:

- [ Brain Client Features ] -

 # | Features
===+========
 1 | Send hashed passwords
 2 | Send attack positions
 3 | Send hashed passwords and attack positions


1.  For sending hashed passwords, does this mean every possible candidate that hashcat is checking?

2.  For sending attack positions - is there an example of what this means anywhere?

3.  Can the brain be used as a centralized potfile to track successfully cracked hashes?

[royce]

1. Yes. All candidates are centrally reported and indexed. For slow hashes, this is effective, because it allows all clients to skip those candidates. For fast hashes, this will quickly bottleneck the cracking process, so this brain mode shouldn't be used all by itself for fast hashes.

2. An attack position would be if an entire mask or dict or dict+rules is run. For example, if I exhaust ?a?a?a?a?a?a, the fact that I exhausted that mask is reported to brain (and maybe in chunks, instead of only at the end? I'm not sure about this). But note that this is dependent on multiple other variables being identical. For example, if a rules file or dict/wordlist file is different by even one byte, it's considered to be different for the purpose of reporting that that attack was exhausted. What this means is that if a team or fleet of systems is regularly using brain, it is important to normalize and standardize the lists of words, rules, etc. that are shared across the systems.

3. Not yet, but IIRC this is an eventual goal. The raw brain files might be parseable to do this as a side effect, but I've never tried this.

[atom]

Just a small addition to (2). If the fast hash is a salted hash (like vbull or so) and you have sufficient number of salts, the bottleneck effect is mitigated by the salts if you have enough of them (300000 or more).

[mtnsec]

Thanks!