This is strange, is there a bug or am I missing something here:
Let's say password is WORD123. I have following files:
test.hash containing single hash (16800) of the password
test.rule containing single line: $1$2$3
word.dict containing single line: WORD
word123.dict containing single line: WORD123
This is odd:
hashcat -a 0 -m 16800 test.hash word123.dict
works as expected and cracks the password almost immediately. However
hashcat -a 0 -m 16800 test.hash word.dict -r test.rule
gives me "Exhausted".
Single line rule works, because
hashcat -a 0 word.dict -r test.rule --stdout
gives me WORD123 as expected.
Also, same password in SHA-1 and Office 2013 hashes works as expected. I'm using Hashcat 5.1.0 in Windows and 1080 GPU.
I expect your password is not actually WORD123 but something different. Because WORD123 is only seven characters and thus not a valid WPA2 password.
WPA2 has a minimum password length of eight characters and unfortunately hashcat early-rejects words from your wordlist below that threshold before applying rules. You can verify this by checking the "rejected" metric of your hashcat output.
instead of using:
Code:
hashcat -a 0 -m 16800 test.hash word.dict -r test.rule
you can also use:
Code:
hashcat -a 0 -m 16800 test.hash word.dict -r test.rule -S
(06-30-2020, 10:07 AM)undeath Wrote: [ -> ]I expect your password is not actually WORD123 but something different. Because WORD123 is only seven characters and thus not a valid WPA2 password.
WPA2 has a minimum password length of eight characters and unfortunately hashcat early-rejects words from your wordlist below that threshold before applying rules. You can verify this by checking the "rejected" metric of your hashcat output.
Yep, WORD was just an example, the actual password is 5 chars + 123, total 8 chars.
(06-30-2020, 10:16 AM)atom Wrote: [ -> ]instead of using:
Code:
hashcat -a 0 -m 16800 test.hash word.dict -r test.rule
you can also use:
Code:
hashcat -a 0 -m 16800 test.hash word.dict -r test.rule -S
WOW - it works, thanks!
-S means "enable slower (but advanced) candidate generators" ?? No idea, what it means (because the rule couldn't be any simpler), but it works. Without your help I would have never found this.
it's exactly like undeath explained above.
Without the -S slow mode the passwords that are too short (from the dict) are rejected immediately, while the -S mode is slow because it mangles the words with rules already on the host (CPU). This is just a speed tradeoff, a design decision. A known limitation
(06-30-2020, 11:10 AM)philsmd Wrote: [ -> ]it's exactly like undeath explained above.
Without the -S slow mode the passwords that are too short (from the dict) are rejected immediately, while the -S mode is slow because it mangles the words with rules already on the host (CPU). This is just a speed tradeoff, a design decision. A known limitation
Do I understand this correctly: you need to use -S only if dictionary contains words which are shorter than 8 characters before any rules are applied?
Then it makes sense.
If dictionary has both short (<8) and long (8 or more chars) words, are rules applied correctly to longer words even without -S?
Yes, without using -S words from your wordlist shorter than eight bytes will be rejected.
(06-30-2020, 11:10 AM)philsmd Wrote: [ -> ]it's exactly like undeath explained above.
Without the -S slow mode the passwords that are too short (from the dict) are rejected immediately, while the -S mode is slow because it mangles the words with rules already on the host (CPU). This is just a speed tradeoff, a design decision. A known limitation
Wow; I really should have known that given how long I have been messing around with hashcat, and I did not.
I do now - thank you very much!