I think I found a small bug

[Tyson0317]

Hi all. Awesome program and awesome support forum!! Been reading many posts here via search, but created an account to report this one:

I am using a wordlist and rules file to crack WPA passwords, many of which tend to be phone numbers. To save space, instead of generating a giant list of phone numbers, I simply made a wordlist of area code + suffix. I then made a rule list to append the last 4 digits. This way, what would otherwise be a 4GB list of phone numbers, is instead a 180kb wordlist + 117kb rules file. The bug and problem is that hashcat is rejecting 100% of these passwords.

Why? Because WPA requires a password length of 8 - 63 characters. And as far as I can see, hashcat is looking at the password before it applies the rule!! It should apply the rule FIRST and then see if the resulting word meets the 8 - 63 limitation.

Example:

The password for a given -m2500 hash is, 208555121

My wordlist (-a 0) contains 208555 and has a rule of $?d$?d$?d$?d (adding the last 4 digits)

Yet if ran like this, the password 208555 is rejected, before the last 4 digits within the rule are applied.

I think that this bug is causing a significant number passwords to slip through this crack whenever the root password is less than 8 chars long.

It would be nice if hashcat applied the rule, thus getting the full 10 digits, then performed the compliance check to accept/reject a given password.

Am I doing something wrong?

[Chick3nman]

This is a known behavior and I'm not sure if it was decided if it was a bug or not. The reason is because the rule engine that runs on the GPU (-r) takes place AFTER the candidates are loaded. But the automatic rejection for the candidates happens host side BEFORE they make it to the GPU. This is the optimal order for performance but leads to some specific issues like the one you are having. The solution to this in your specific case would probably be to change to a full mask or mask file instead of using rules/wordlists. This would solve the issue as well as being faster overall than rules/wordlists would have been regardless. I will need to do some digging and reevaluate whether there is a fast way to fix this without a complete restructure of how the candidates are loaded and without doing the rejections on the GPU.

[vicious1]

Actually I would use a combination attack here ((-a6)) and do a word list + mask instead of with rul append...

[Tyson0317]

I see the technical problem now... it is an interesting one.

The work-around with the -a 6 works for the phone number example. But what if I have a rule file configured to try common things like street address, zip, last 4 of phone number vs root words that happen to be under 8 chars long?

Running the rule and dictionary though hashcat --stdout to dump to a file, takes a shockingly long amount of time. (not sure why this is). I've found a program called Mentalist that does it quicker, but it is still wasteful. In some examples, what would be about 3MB of dictionary + rule file, turns into 44GB when rendered to a full mask. Hardly efficient!

Example: WPA password is pass123!

Within my dictionary, mixed with a million other words, is the word 'pass'. A rule adds digits and another rule adds symbols. This setup would be rejected by hashcat and never tried against the hash, despite the fact that it is the valid password. Rendering the whole thing into a mask attack would yield a 30GB file and would in itself take a few hours to my SSDs. Whereas the root dictionary file and the rules take up maybe 100MB.

Is there a way to force hashcat to ignore the rejection, apply the password and run the password anyway? That could be a workaround. I tried it with a --force, but that didn't work. It seems like a noteworthy problem that ought to have a solution better than 'create a full mask'.

[philsmd]

you can use this command line option

Code:

-S

to workaround the rejection (will of course be "a little bit" slower because workarounds always have some drawbacks)

[Tyson0317]

Philsmd - that worked like Magic!! Reported hashing speed doesn't seem to me noticeably impacted on my 2x 1080 cracking machine. I guess I should have played with the options some more, but I was stuck on thinking that --force would be the appropriate flag, if any.

-S, --slow-candidates | | Enable slower (but advanced) candidate generators

didn't speak to me, "pre-generate candicate with rule"

Awesome!! Thank you again for this awesome product and for all of your help!!