In order to work with pass phrases, and since oclhc+ has a 15 character limit, having the ability to work with multiple dictionaries, with a rule per dictionary, would be a useful change to the regular hashcat. Maybe even three dictionaries.
E.g., suppose the password is "Use#longer*passwords!", if we could have three dictionaries, with an append special rule per each one, then that type of attack could be made easily.
A password pattern I'm trying to go after is prefix+word+suffix, and I don't see an easy rule-based method with any of the hashcats.
you can do both already with a bit of creativity. 1. rule per dictionary can be done with CPU hashcat and --stdout switch just redirect stdout to a new file, which you then use as a dictionary. 2. for tripple combinations you can exploit the salted hashes like joomla. just add the most left side word as salt. you can have the same hash multiple times if the salt changes.
The idea is to avoid making new files as dictionaries as they could be quite large, exceeding my disk space.
If the combinator attack would let us have rules per word, that would be a step in the direction I'm after.
For #2, I'm talking about CPU hashcat, with no left and right sides.
Any version that has a left and right dictionary has a 15 char limit, which is too short. When the 15 char limit is increased to 63, then it woiuld be useful for longer passwords/phrases.
you can try it with hashcat cpu. i already worked on this in the past and instantly lost interesst in this as soon as i was working on it. its just to slow.
Anything the program could do programmatically would be faster than our writing combined word lists out to a disk file them reading them back in as dictionaries. And then disk space wouldn't be a limit.
I'm sure many doing this work would appreciate it even being possible, and be aware that by its nature is "slow."
But mangling multiple dictionaries with results longer than 15 characters is what is needed in this day and age.
no you did not understand me. i already tried tripple wordlist attacks in the past, even on GPU. it was so slow that i lost interest.
But even something "slow" may still find a password, if left running long enough.
Could the left and right dictionaries with rules per each side, but with bigger sizes, be put into the CPU hashcat, with the proviso that it will be slower than the GPU hashcats, be done?
Even if the dictionary word had a limit of 15 chars, with a limit of 31 chars per side, totalling 60 something total combined, it would open whole new worlds of passwords to be tried.
there are two problems involved. first one is that it would require an expansion to support plaintexts longer than 15 chars which would results in massive code change and performance drop and an combinator engine which supports rules. taking this together would make me busy for months to have an attack that is not very efficient. does not sound very ... economic
I'm just a home hobbyist who dabbles with this, but I look at all the various cracking software out there, to collect ideas, from their web sites and manuals, to see how to do the same with the hashcats, and it seems like "everybody" has ways to combine attacks and target lengths beyond 15 characters, because end users are making longer passwords these days.
Since you aren't a business that can charge $1,000 per copy, and have a staff of programmers at your disposal, I realize that there are limitations to what you can do with your time.