Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 8 Jan 2016 07:14:57 +0100
From: Patrick Proniewski <patpro@...pro.net>
To: john-users@...ts.openwall.com
Subject: Re: get more info about what yield to crack a particular pwd

Hi Frank,

On 07 janv. 2016, at 19:37, Frank Dittrich wrote:

> Except when you are using --wordlist without any rules, this is currently not possible.
> May be you could create a new github issue:
> https://github.com/magnumripper/JohnTheRipper/issues
> and we can discuss there how this request could be supported, may be only for debug builds, only with --verbosity=5, only with --mkpc=1 ...
> Such a feature will definitely have a performance impact, so don't expect this information to be easily available in a default build or with a default config.


Thanks, I'll think about it.


>> - what rule applied to this word allowed jtr to crack the password
> 
> Since most formats work on blocks of multiple candidates at the same time, there's always a possibility that candidates in such a block were generated by multiple rules.
> This is especially true for very short word lists or for single mode.
> 
> An additional difficulty in single mode is that even with just a single rule ':' (e.g., with --single=none), john will try combination of words from the GECOS field, user name ...
[..]
> Furthermore, single mode with default config settings will try candidates which successfully cracked one hash on hashes with other salts. This can be changed by Adjusting config variable SingleRetestGuessed.


This is no big deal, and I realize I should have explained my goal, instead of explaining just the way I'm thinking about to achieve that goal.
I'm currently working with various extensive wordlists, and with --rules=ALL on a Jumbo version of JtR. That makes a very huge waste of CPU. My purpose would be to deduce from my current cracking sessions what rules are effective, and what kind of words are effective. It can be fuzzy, no big deal. I just want to get faster by removing rules that crack nothing, and why not chucks of wordlist that are useless.


> So it might be a better idea to convert your .pot file into a dummy hash file.
> E.g., just use --format=dummy or some other fast format.
> The dummy format just uses the prefix $dummy$ followed by the password converted to hex, e.g., password "dummy" would have hash "$dummy$64756d6d79".
> If you use some other format, make sure it supports at least the same password length as the format(s) in your .pot file.
> If your format supports mixed case and non-ascii passwords, the dummy format should also support mixed case passwords and non-ascii characters.
> These format properties are reported in the format details as well.



That would be perfect for me as it would allow me to work on passwords already cracked without restarting from the beginning. 
Thanks a lot for your explanations on the various aspects of this question, and for this suggestion.

regards,
pat

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.