Using hashcat Brain with slow hash and specific password length

[Toetje]

I am trying to attack a slow hash which I know has a length of 12 or more characters.

Since I want to use a rule based attack I am wondering how I can easily limit the amount of password candidates for cracking combined with the hashcat brain.

If I use the example wordlist:

Code:

123456789abcd
123456789abc
12345678
1234

combined with the example ruleset:

Code:

:
$1 $2 $3 $4
]

My desired output would be:

Code:

123456789abcd
123456789abcd1234
123456789abc
123456789abc
123456789abc1234
123456781234

Thereby skipping:

Code:

123456789ab
12345678
1234567
1234
12341234
123

When using an inline filter, it seems to only look at the length of the word before rules are applied:

Code:

hashcat64.bin -a 0 example.dic -r example.rule -j '>C' --stdout
123456789abcd
123456789abcd1234
123456789abc
123456789abc
123456789abc1234
123456789ab

This way I will miss the password 123456781234 while it will try the 11 character password 123456789ab.

I can pipe the output from hashcat to hashcat to remedy this:

Code:

hashcat64.bin -a 0 example.dic -r example.rule —session output --stdout | hashcat64.bin -j '>C' --stdout
123456789abcd
123456789abcd1234
123456789abc
123456789abc
123456789abc1234
123456781234

This works fine (especially because it is a slow hash), however I want to use the hashcat brain which does not accept stdin mode.

So this leaves me with 4 undesirable options:

-Don’t use hashcat brain
-Accept a large set of password candidates are just a waste of computational power since they will never find the correct password
-Create a (insanely large) dictionary file from all password candidates generated by the wordlist and rule that are 12 characters or longer and then start the attack.
-Create a (insanely large) dictionary file from all password candidates generated by the wordlist and rule that are 11 characters or shorter and feed this file to the hashcat brain with a faster hash, afterwards running the normal attack with brain active.

Am I skipping a nice feature of hashcat that I am unaware of and would solve my problem, or is there no better solution than already mentioned above?

[philsmd]

if you have a minimum required length of 12 and rules that add up to 4 characters, you could just pre-process your dict such that it has at least 12-4 = 8 characters. That's already a huge filter and probably already good enough (to still have maximum speed etc).

of course it depends a lot on the hash type and cost factor (you didn't mention it), but since you are using brain I assume something like bcrypt/scrypt with a high cost factor:

Code:

awk 'length > 7' example.dic > example_filtered.dic

the truncate rule of course might produce some "wrong" results, but depending on how many rules you have etc it might be negligible... sometimes users over-think and over-estimated the filters and at the end only much less than e.g. 1% of the password candidates are filtered out etc and that would be negligible

[Toetje]

Thanks for the suggestions.
I didn't mention my hashtype because I didn't think it would be relevant, but just for completeness, it is indeed bcrypt.

My problem is that my custom rules are aimed at increasing the length of the original passwords in different ways so I can use a simple wordlist like the rockyou set and still get interesting passwords.
With this combination I can't filter out too many original passwords and the amount of incorrect passwords is a lot higher than 1%:
Initial password length 1 = 61% incorrect passwords generated with ruleset.
Initial password length 2 = 51% incorrect passwords generated with ruleset.
Initial password length 3 = 42% incorrect passwords generated with ruleset.
Initial password length 4 = 34% incorrect passwords generated with ruleset.
Initial password length 5 = 27% incorrect passwords generated with ruleset.
Initial password length 6 = 20% incorrect passwords generated with ruleset.
Initial password length 7 = 14% incorrect passwords generated with ruleset.
Initial password length 8 = 10% incorrect passwords generated with ruleset.
Initial password length 9 = 6% incorrect passwords generated with ruleset.
Initial password length 10 = 2% incorrect passwords generated with ruleset.
Initial password length 11 = 0,5% incorrect passwords generated with ruleset.
Initial password length 12 = 0% incorrect passwords generated with ruleset.

Granted, my ruleset is tailored for fast hashes, so I am going to rebuild and optimise it for bcrypt, but my problem stays the same.
I could choose to use initial passwords of a length of 9 or larger since the incorrect password loss would be less than 7% which is acceptable for me.

Your advise suggests there is no option inside hashcat to solve this problem, so I think I'll stick with my workarounds or try a password length of 9 and higher.
Thanks again for the suggestion.

[philsmd]

in theory we could enable the rule engine used by -j and -k also for --slow-candidates (-S) which is enabled by default in case brain is used.
This would also allow reject rules etc (everything that is supported by -j/-k) but allow multiple rules (like with -r).

This feature of course is currently not implemented, but might be doable... I think if it is not too confusing for the user we could just make -r act differently and allow "more-rules" (like in -j/-k) with -S, but also several rules (like normally used with -r).

You could probably try to request it here: https://github.com/hashcat/hashcat/issues , not gonna lie, this might also be interesting for other users (I just hope it's not too confusing that -r acts differently with brain or -S, but that little inconsistency might be acceptable for the nice feature).

[Toetje]

Thanks for your response.
I opened an Issue at github, but am a total git noob so I hope I did it correct:
https://github.com/hashcat/hashcat/issues/2284