05-15-2021, 09:42 AM
We can only give good advice when you also mention the hash type that you are trying to crack.
There are basically worlds between cracking a fast hash and a very slow hash.
My guess is that you would better be off using a normal mask attack (maybe even use a hcmask file if you need to "filter" or run several more specific masks at once etc) instead of using a dictionary as you write above.
I/O (input / output, i.e. disk access) is always slow and therefore a dictionary attack for such a specific case wouldn't make much sense.
If you really need to generate the password candidates outside, you would be better off using a stdin/pipe attack (but again this will be normally slower than a mask/hcmask attack in most of the cases, depending on the hash type):
in this case your own password generator that is already able to generate and filter wrong/invalid/non-sense mac addresses is named my_fast_mac_generator_code and this must be really, really fast.... furthermore you probably still need some amplification for hashcat with a rule file (I've called it "my_rules.rule" here) which does some swap rules or similar, just to give hashcat much more to do (multiplier/amplificator).
Again, this is something that depends on your situation and mostly on the hash type/algorithm... it could also be that it's not worth it to filter the few candidates that could be wrong (i.e. if just 1 in 100,000 candidates are an "invalid" mac address but the hash type is already a very fast one like MD5 or similar... in this case we could really argue that it's negligible to do any slow/strange filtering of invalid mac addresses, because the speed cost is greater than the benefit from reducing the keyspace/password candidates).
I guess you already got the idea: avoid I/O and try to understand which attacks is faster and depending on the points mentioned above see if filtering even makes sense or if you would be better off not doing any strange check of valid or useless mac addresses.
There are basically worlds between cracking a fast hash and a very slow hash.
My guess is that you would better be off using a normal mask attack (maybe even use a hcmask file if you need to "filter" or run several more specific masks at once etc) instead of using a dictionary as you write above.
I/O (input / output, i.e. disk access) is always slow and therefore a dictionary attack for such a specific case wouldn't make much sense.
If you really need to generate the password candidates outside, you would be better off using a stdin/pipe attack (but again this will be normally slower than a mask/hcmask attack in most of the cases, depending on the hash type):
Code:
./my_fast_mac_generator_code | ./hashcat -m 0 -w 3 hash.txt -r my_rules.rulein this case your own password generator that is already able to generate and filter wrong/invalid/non-sense mac addresses is named my_fast_mac_generator_code and this must be really, really fast.... furthermore you probably still need some amplification for hashcat with a rule file (I've called it "my_rules.rule" here) which does some swap rules or similar, just to give hashcat much more to do (multiplier/amplificator).
Again, this is something that depends on your situation and mostly on the hash type/algorithm... it could also be that it's not worth it to filter the few candidates that could be wrong (i.e. if just 1 in 100,000 candidates are an "invalid" mac address but the hash type is already a very fast one like MD5 or similar... in this case we could really argue that it's negligible to do any slow/strange filtering of invalid mac addresses, because the speed cost is greater than the benefit from reducing the keyspace/password candidates).
I guess you already got the idea: avoid I/O and try to understand which attacks is faster and depending on the points mentioned above see if filtering even makes sense or if you would be better off not doing any strange check of valid or useless mac addresses.