[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 9 Nov 2016 17:57:11 +0100
From: p+password@...atpro.net
To: john-users@...ts.openwall.com
Subject: Re: alter default rules or filter, best way to focus on proper candidates?
> No, if you put the rejects first, then the rules engine first does the rejection logic on the original word. If that word fails, then the rules engine does no more work at all, it simply discards that word. THAT is why you should put rejection items as early as possible. NOTE, there can be times when you want to do rejections later (and sometimes you HAVE to reject later, such as the Q rule).
Ok, so that's miles away from what I'm looking for. I don't mean to discard words from my wordlist that include an upper case char. I want to exclude candidates that include an ?u.
>> # Weird order, eh? Can't do anything about it, the order is based on the
>> # number of successful cracks...
> This comment is not about the rejection rule 'primitive' commands in the rules, BUT in what the rules do.
I've pasted this comment to give some context to the 2 random rules I've picked as an example ;)
> The rule engine rules all words against rule #1 in the list before moving on to running all words against rule #2, then #3, ... until all rules have been completed. This is what I would call a 'depth-first'. I would like to add a mode to john jumbo that would do a 'breadth-first' rules mode (where each word would be run through the entire set of rules, then the next word would run through the full set of rules, etc). There are benefits to both methods, but john only does the first mode.
I'm aware of that.
> As for the other items you are trying to do, simply write rules, and use --stdin and --stdout (with echo "test word" | ./john ..... to test that the rule does what you expect) to build and improve your rules. The more you work with them, the better you will be with writing them better. Note, there are often multiple ways to write the same rule, and often times you can use fewer rule primitives to do the same thing (optimizations). That along with order (especially when rejecting), can make rules run with less overhead (i.e. faster). For slow formats this is not that big of a deal. The % of runtime in the rules engine is negligible, but for fast formats, it can make significant improvements in overall throughput. Sometimes you will find that cutting a wordlist up with grep into multiple input files also improves overall throughput (but at the expense of more files and more disk space used, and at the time taken to create these sub-wordlist files). But if you are already at the level of writing your own rules, then you are certainly moving up into more of the advanced usage status of john users.
Having to (re-)write every rules is what I'm trying to avoid, unless it's the only solution. I would have to rewrite them all for each variation, not so pleasant I would say :/
But with fast hashes, it's probably safer to waste CPU cycles on bad candidates than to lose days and nights tweaking rules.
thanks,
patpro
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
