Cracked Passwords when using Brain

[slawson]

When using brain with multiple clients, what happens when a password is cracked by one of the stations?

1.  Where does it store the cracked password?  

2.  Does it send a signal to all of the stations to stop attacking the cracked hash?

[undeath]

1. only the instance that cracked the hash knows about it
2. brain only synchronises attacks, not hashes

[slawson]

Thx for answering that question. Of course, I have another (Give a mouse a cookie).

I'll try to explain.

(While using the brain feature)
If I run an attack on a file that has already been processed, the attacks quits within seconds, which is good.
If I make a copy of that file and run the attack on the file, again it quits within seconds.
If I take just a single hash from the file and copy to a new file and run the attack, it takes the full time to process.

Does it not look at each hash and know if an attack has been run on it before? Or is that what client feature 3 does?

Thank You for your time and knowledge.

[undeath]

no, brain only stores a checksum for the whole hash file. If the hash file is different in any way it's considered a different one with independent attack tracking.

[slawson]

That makes sense. Thanks. Although, I am still missing something. I am trying to unveil the potential in using brain.

My goal is to avoid duplicate candidates when running a rule against a hash file. If I run best64.rule, it takes about 22 hours the first time (16800 hash). The second time it only runs a few seconds. I now realize I can't change the hash file, but I took some of the rules from best64 and placed them in another file. When I run the rule with my new rule, it now takes the full time to process.

Apparently my thinking is wrong, but I thought that it would avoid duplicate candidates.

With that in mind, it looks like the only benefit I am getting out of brain is that it memorizes the attack position, which I could do with --restore, right?

I know there has to be a lot more here that I am not seeing.

Thanks again for your response.

[philsmd]

which --brain-client-features are you using ?

you must be more precise when you make such statements

[philsmd]

furthermore, if you are looking for distributed cracking, you better consider using hashtopolis or similars (hashtopolis also has support for brain features as far as I know).

brain is not meant to distribute work across different systems/rigs, it's just a nice feature to avoid redundant work without any further complications (like checking and syncing dicts etc... which wrappers like hashtopolis are able to do). That's very, very different approaches and features, but sadly a lot of users seem to not understand the differences and mix them up.

For instance, hashcat has a built-in feature called outfile, which is able to remove hashes while cracking, which can be used by wrappers, but also directly together with the brain feature.... but brain is not meant to do ALL things in one... it is specialized at doing one specific thing very fast, i.e. avoid doing the same attack/password check for (very) slow hashes.

[slawson]

Just the default which I understand to be -2.

To accomplish my goal, would I have to use -3. If so, I could see how that could take tons of storage.

Is -2 essentially a glorified --restore function?

[philsmd]

no, this has nothing to do with --restore and -2 and -3 are also very different things (--custom-charset1 ... --custom-charset4).

you need to specify --brain-client-features 1 or --brain-client-features 3

[slawson]

Sorry when I said -2 and -3 I meant brain client features 2 and 3. Not custom character sets.

So what I meant is that if I just use the default --brain-client-features 2, is that essentially just the same as --restore?