Date: Wed, 14 Nov 2012 08:17:29 +0400 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: How does incremental mode works? On Tue, Nov 13, 2012 at 07:44:33AM -0600, Richard Miles wrote: > These links helped me a lot. It's very interesting, suppose that I have a > custom list of words already with some manipulation for a custom target, is > there anything that I may do to use it with jTr that will give me better > results in comparison with default incremental mode? Examples are welcome. Yes, although the standard way of doing it is through cracked passwords (real john.pot) rather than a customized wordlist (fake john.pot). One of the examples in doc/EXAMPLES is on how to reuse statistics from cracked passwords for a new .chr file. You may try the same with a fake john.pot produced from a wordlist, too. Unless you have many cracked passwords from your target already (at least thousands), you'll probably want to use the standard .chr files as well, though - and yes, this means overlap. > I was reading this thread and I found this link ( > https://twitter.com/hashcat/status/239636316499869696/photo/1/large), do > you know where is jTr in comparison in this chart? Like I said in the other reply, no. I'd expect JtR's incremental and Markov mode lines to be somewhere near the BF++ line, but we have not performed such a comparison. > Also, I found this nice project (http://thepasswordproject.com/passpal), is > there a way to "integrate" passpal to create more robust rules based on my > targeted wordlist already manipulated to generate more strong candidates > for jTr in incremental mode or similar? Again like I said in the other reply, optimizing wordlist rulesets is also a topic that we'll soon release more info on. The rulesfinder tool is already public: https://github.com/bartavelle/rulesfinder This is not easy to use. > My main concern is not run two different instances of jTr to test basically > the same thing, so I would like to try avoid as much as possible repeat > candidate passwords, however, since the output wordlist may be huge the > cost to do sort and uniq may be too unacceptable. You have to strike a balance between the cost of avoiding duplicates and the cost of testing them. For slow hashes, you'll want to avoid duplicates. For fast hashes, you'll have to let some duplicates be tested along with the unique candidate passwords. When you're attacking slow and salted hashes, and the number of different salts is large, you won't test all that many candidate passwords - so you'll have to limit the number of candidate passwords generated by each of your incremental and wordlist with rules runs, and you may in fact pass their combined output through "unique -mem=25". Yes, you'll generally prefer to use JtR's "unique" program rather than "sort -u". You don't want to sort the candidate passwords alphabetically, because they had already been ordered for decreasing estimated probability of each being one of the actual passwords. You merely want to eliminate duplicates. > This guy called atomu looks very brilliant, but he also looks very > arrogant. Anyway, I impressed by what he claimed and the results. One thing > that called my attention is that appear to be agreed between this guy and > solar d. that their mask filters are more efficient in comparison with > current jTr incremental mode. Is it correct? No, this is not correct. This is apples and oranges. > Is there a workaround or > something similar to archive similar results with jTr? It depends. Mask mode is quicker to use when you know a pattern and need to have the program test that specific pattern. In JtR, this is currently more cumbersome to do and it runs slower - e.g., with KnownForce external mode. When you don't know a specific pattern (or when there are too many such patterns to be worth enumerating, or when they'd overlap), you'd use other cracking modes anyway. Alexander
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.