Posts: 247
Threads: 59
Joined: Mar 2011
This wasn't a question I anticipated, and since have always run the GPU rules before the CPU rules, don't have any real measurements.
The bigger question of whether we can do without certain rules isn't something I recall reading any research about. Since you (epixoip) and atom represent the practical opinion side, for the academic side I've posed the question to Matt Weir (@lakiw), of
http://reusablesec.blogspot.com. (He may be too busy preparing for his next talk to answer.)
It is likely that with all those leaked lists, enough GPU rules may eventually create candidates that would've been created with CPU rules, but I'll leave that research to the researchers.
Posts: 85
Threads: 15
Joined: Jun 2010
You can also pipe the output from old hashcat or other rule processor out to HC3.
Posts: 18
Threads: 3
Joined: Mar 2012
(07-21-2016, 12:53 AM)Kgx Pnqvhm Wrote: The bigger question of whether we can do without certain rules isn't something I recall reading any research about. Since you (epixoip) and atom represent the practical opinion side, for the academic side I've posed the question to Matt Weir (@lakiw), of http://reusablesec.blogspot.com. (He may be too busy preparing for his next talk to answer.)
It is likely that with all those leaked lists, enough GPU rules may eventually create candidates that would've been created with CPU rules, but I'll leave that research to the researchers.
That's certainly something that I can look into. My gut feeling is that most of the missing rules will not have a big impact on cracking sessions. I just don't see too many people creating passwords by removing character classes. Aka while rare, deleting individual characters does happen, (password -> pssword). Deleting classes of characters though ... (password -> paword), I'm skeptical that happens in more than in a few cases.
Once again, this is my pure gut feeling with no tests behind it, but I expect you'll still get cracks with rules like that but they will mostly be due to it stretching your input dictionary. Aka 'paword' might be a new Pokemon type vs a user deleting the s's. If that's the case, a better way for cracking those passwords might be using Mask/Markov hybrid rules.
To help me out, do you have the full list of mangling rules that are no longer supported? Thanks!
Posts: 247
Threads: 59
Joined: Mar 2011
As far as I can tell, it is just the purge '@' rule, which only the CPU hashcat (now called legacy) has ever been able to run.
I don't know how many people have used my method of running all the GPU rules on a CPU hashcat, but then also running the CPU-only rules on the CPU hashcat.
On the first page, atom said that to get the purge rule would take some more effort, so may eventually be in hashcat v3, but what is puzzling is where he said it is unclear which rules might also not work. (My inner programmer is cringing with the concern that some rules may fail without being rejected, the "silent failure" type problem.)
If there are other rules that can't be programmed to work, the question may have to be posed "can we live without that rule?"
If the starting point was pure English words, and one had to arrive at passwords by rule alone, then not having the purge rule would be bad. But, since there are so many leaked lists now, there are likely enough resultant words from whatever mental transforms that the purge rule was meant to do, that the consequence in 2016 isn't that much.
For now, of course, the old CPU hashcat-legacy can be used for the rules v3 doesn't run, but I thought it would be an interesting research question for those who like to do research.
(I'm big on logging my runs, so want to be able to record that, e.g., the d3ad0ne.rule was run in its entirety against word list XYZ.txt.)
Posts: 247
Threads: 59
Joined: Mar 2011
08-15-2016, 01:54 PM
(This post was last modified: 08-15-2016, 08:33 PM by Kgx Pnqvhm.)
Update: Matt has a Sunday, August 14, 2016 blog post titled "Evaluating the Value of the (@)Purge Rule" at
http://reusablesec.blogspot.com/2016/08/...-rule.html.
He states that "Since then, At0m added support for the rule back in the newest build of Hashcat" and gives a GitHub link.
My next question is do we want to run it on a CPU device or GPU device?
In other words, would it slow down the GPU processing, or is there no speed penalty?
Should we still reserve running the purge rules on CPU, as a separate rule set, just like the CPU hashcat vs. GPU cudahashcat division?
Posts: 18
Threads: 3
Joined: Mar 2012
(08-15-2016, 01:54 PM)Kgx Pnqvhm Wrote: Update: Matt has a Sunday, August 14, 2016 blog post titled "Evaluating the Value of the (@)Purge Rule" at http://reusablesec.blogspot.com/2016/08/...-rule.html.
You beat me to to that
Long story short, the newest version of Hashcat supports purge rules now so this problem has pretty much been solved. Even if that hadn't happened, it appears that purge rules have only a minimal impact on the success of a cracking session.
As a side note, John the Ripper supports:
@?C purge all characters of class C from the word
I didn't run any tests on that, but my gut feeling is that it wouldn't be that useful except as part of a --loopback style attack or cleaning up an input dictionary. For example, let's say you have a cracking session and crack "password123". You might want to strip off all digits and special characters and then retry the base word with other mangling rules applied to it. A purge all character class rule might help with that. Aka it's a rule that helps simplify your workflow, (don't need to run your crack list through another program to clean it up), vs a rule to mimic user behavior to crack their passwords.
Posts: 247
Threads: 59
Joined: Mar 2011
My original consternation was that I downloaded and installed the CPU OpenCL driver only because I thought the hashcat v3 would be like the legacy CPU hashcat, and only run the purge rule there.
