hashcat Forum

I have added the request here.

We'll just have to see if he accepts it.

Atom has already given his reasons why he won't be making the hashcats able to combine dictionaries with rules, and I realize that it would be a major code revision.
The point I keep bringing up is that most of the archive/document cracking programs do give some way to combine words from different dictionaries.
And that real-life passwords are likely to be based on more than just one word.

(02-08-2012, 01:12 AM)Hash-IT Wrote: [ -> ]I have added the request here.

We'll just have to see if he accepts it.

thanks for the update, looks nice

An example of that type of password is seen in the suspense novel I'm currently reading where an employee named Clayton Johnson in a Seattle company has the password of "JohnsonCLsonicsrule".

A combination of a KoreLogic style CAPCAP rule appended to a last name combined with a sports team with suffixes rule would get this password.

People having to get past corporate complexity rules are likely to just tack on more words to their password rather than harder to remember strings like H2jj&.

An update on RAR: I just finished the ATI RAR kernels yesterday. This is the most difficult algo I've done on GPU until now. It is not hard to code the RAR algo with OpencL, but having a good performing code is very tough job. Until the very end, the scalar version was the fastest one, until I found out a trick to prepare the hash blocks faster. It's all about keeping a balance - you shift data to __local memory, you get lower GPR utilization and then also lower ALUBusy. You vectorize more, you get higher ALUPacking and higher GPR utilization. Also, I had to write 16 separate kernels per each password length 1..16, because there are tweaks that depend on password length. So right now, it does about 9000 c/s on 6870, but due to the slow-performing CPU OpenSSL AES routines, speed gets capped to about 7500 c/s. With RAR archives without header encryption, AES is definitely the bottleneck and the highest speed I get is 1300 c/s.

Probably the solution is two-fold: write a fast GPU kernel and write a fast AES-CBC routine, if possible use SSE2, AES-NI and stuff. For archives with header encryption it's possible to have a second kernel that handles AES decryption in GPUs, unfortunately this is not applicable without header encryption where data to decrypt may be megabytes long.

Also researched 7Zip format. Guess what - the number of block operations is twice as much as RAR and the hash function used is sha256, not sha1. It would be about 4 times slower. Nice. I guess GPUs still don't change much as far as archive passwords are concerned (excluding ZIP where they do help).

gat3way_ that is pretty cool. Will it be available in a tool any time soon? There is certainly demand (I get private requests related to malware analysis).

In several months. I need to add 7z and dmg support as well to cover most used archive formats. BTW rar speed is not something I'm proud of yet, igrargpu is still about 10% faster.

(02-17-2012, 11:53 AM)gat3way_ Wrote: [ -> ]In several months. I need to add 7z and dmg support as well to cover most used archive formats. BTW rar speed is not something I'm proud of yet, igrargpu is still about 10% faster.

you just need to change some -'s to +'s and get like 20%