hashcat Forum

Full Version: Optimized dictionary for WPA
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hello to all. I apologize for my poor english.

I would like to create a dictionary optimized for wpa.

I know the password is 10 characters long from UPPER HEX (0123456789ABCDEF). The key space is 16^10, but I know some rules and I'd like to use them with maskprocessor or crunch.

Rules:

1) 10 chars long
2) no more than 5 alpha chars in the password (yes ABCDE01234 no ABCDEF0123)
3) no more than 2 consecutive chars (yes AABCDEF012 no AAABCDEF01)
3) no more than 2 equal numbers in the password (yes A1A123456 no A1A123451)
4) no more than 3 equal alpha chars in the password (yes 8017C24CCF, no C017C24CCF)

May someone help me? Thanks.
As far as I know, only the -q switch could help you. You would need your own word generator to apply all these rules.
try crunch as a word generator, can be piped or used to create a file
(12-11-2013, 11:13 PM)JulioQc Wrote: [ -> ]try crunch as a word generator, can be piped or used to create a file

wrong hint, maskprocessor can do the same but faster.

you won't neccessarily need an own written word generator, but you will propably need to write a tool to apply a filters on maskprocessor output.

what's the reason for those limitations? vendor specific? how did you find out?
(12-12-2013, 04:39 PM)atom Wrote: [ -> ]
(12-11-2013, 11:13 PM)JulioQc Wrote: [ -> ]try crunch as a word generator, can be piped or used to create a file

wrong hint, maskprocessor can do the same but faster.

you won't neccessarily need an own written word generator, but you will propably need to write a tool to apply a filters on maskprocessor output.

what's the reason for those limitations? vendor specific? how did you find out?

Yes, specific limitations of vendor. It's a 10 hex password, but with some specific rules.
I were highly motivated by goat's old post.

I figure out that a 16^10 hex password dictionary must be very, very big.

How big? Well, to compare I recently download a not so good password dictionary that weight 178Mb and contains 16,982,780 ten hex strings.

For the other hand, my iMac can manage only 4,300 keys/s with aircrack-ng, so it takes about an HOUR to check all these passwords.

So, a complete 16^10 = 1,099,511,627,776 dictionary must take for me about 8 YEARS for my machine and it could weight approximately 11 Tb.

It make sense to have some heuristic to crunch that enormous dictionary and I like goat's rules.

So I generate a PHP class that follows goat's rules. At first, I've believed that that monster dictionary could be chunk to weight very little, maybe just 10% of the original file. But I was wrong.

According to my big random sample of 10 million string passwords, the real ratio of optimised/total is 0.6655 and it converge very soon from the beginning.

What does it means?

It means that the wanted file is still very big:

- weight: (0.6655) 11Tb = 7.32 Tb
- crackTime: (0.6655) 8 years = 5.32 years

The numbers speak for themselves. So, maybe we will have to wait the first generations of quantum computers, hehe.

The php classes are attached to this post.

Greetings,
A small GPU cluster, which has the speed of 1M p/s for WPA2, could check entire 16^10 keyspace in around 13 days.
No quantum computers needed.