Modifying hashcats optimized kernel
#12
"...the overall performance increase would take off a minimum of 5% of time taken..."

This is where other optimizations will cause FAR larger increases, and i feel like the penalty of late rejections are actually fairly likely to cause a overall performance decrease. Consider what happens when a word of normal length(6-8) meets a rule(ZY) that couldn't possibly produce a short enough plain to fit into the buffer? Well it doesn't even make sense to process that rule at all if its clearly not going to work, right? So we can throw that rule completely out before we even get to the kernel. What if a rule is very unlikely to create a candidate that fits, unless words are very short? We can also throw that rule completely out, saving you (throw away) * (words in wordlist) candidates immediately, and only costing you the time it takes to parse your rule file and trash obviously useless rules. In fact, this is something that i was looking into recently because the way we are handling these rules now leaves some of them in and seemingly creates duplicate words where unnecessary or does what you are looking to do and generates a candidate that we have to reject in the kernel. Just implementing something like that would likely trash enough rules from the 360,000 list off the bat that it'd save you that 5%+ you are after.
Reply


Messages In This Thread
Modifying hashcats optimized kernel - by Robot - 04-20-2021, 01:21 AM
RE: Modifying hashcats optimized kernel - by Chick3nman - 04-21-2021, 02:36 AM