[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100222191514.GA24084@openwall.com>
Date: Mon, 22 Feb 2010 22:15:14 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Feature Requests for JtR
On Wed, Feb 03, 2010 at 12:29:16PM -0600, Minga Minga wrote:
> Ive had a few ideas I'd like to toss around about some ideas of
> new features I'd like to see in JtR.
Thanks. I've saved your message in my "JtR requests" folder such that I
re-read it on a suitable occasion.
> 1) --nolog (do not create .log file). I find myself filling up partitions
> with .log files for some complex rules. Sometimes I don't need a .log
> file - and have to program in 'rm session123.log' into my automation
> scripts.
>
> It would be nice to only create .rec (session) files - but no .log files.
> Im aware - some people WANT .log files - so a command line option makes
> sense (or maybe an entry in john.conf ? ). Do you all USE .log files for
> something? Is there something I SHOULD be doing with my .log files?
> Because I just deleted a 400 MEG .log file without looking at it ;)
The .log files are sometimes useful, and sometimes not. I understand
your desire to be able to disable them. Yes, we may introduce an option
to do that.
Meanwhile, instead of "rm session123.log" after the JtR run, you can use
"ln -s /dev/null session123.log" before starting JtR. This will be
faster (the log records will not be written out to disk).
Your log file size suggests that you have another "problem", though -
too many wordlist rules after preprocessing. Currently, JtR will
preprocess and validate the syntax of all rules at startup. With this
many rules, this is probably taking a while. Perhaps I need to
introduce a way to disable or limit this checking at startup (say, have
it check no more than the first 1 million of preprocessed rules).
> 2) Random Session/.rec file names. If a JtR instance is started and the
> default .rec session filename is already created - it would be nice
> in some cases if a "random" session (file)name was created automatically
> for the user. (I tried to change the source to do this - and failed. But
> it looks 'easy' to do - if you aren't out of practice):
>
> Some ideas I've had on this:
> a) session file name could be [passwd_filename]-[ruleset_specified]-date.rec
> such as pwdump-wordlist-02022010.rec or
> shadow-nt-02022010.rec or
> ciscohashes-KoreRulesAppendJustNumbers-02022010.rec
>
> b) Just "random" filenames. Maybe based on md5 of filename or something?
> Maybe a command line option to automatically create a random session
> filename instead of just using the default. This might not be ideal
> for all users - but some of us would love it ;)
>
> john --random-session pwdump.txt (for example).
This makes sense. I might consider implementing something like it at a
later point (I think there are higher priority JtR development tasks).
> 3) Command line option to specify which john.conf to use.
Yes, this should be implemented.
> ESPECIALLY useful with --external:parallel
Huh? I disagree. I don't see how having separate john.conf-like files
would be any easier than having multiple Parallel-like sections in a
shared john.conf file (which is possible with the current JtR code).
> Currently, I have to use 'sed' to manipulate values in the
> --external:parallel when I want to automate the process. I then overwrite
> john.conf - launch the process - then RE-generate another john.conf and
> this process repeats over and over again. It gets a bit annoying with
> 100 cores across multiple systems - because I have to 'scp' john.conf s
> everytime I want to start a new process.
It sounds like you're doing it wrongly, then. Please see above.
Also, the "--external=parallel" approach does not scale well enough for
fast hashes and this many CPU cores. You can reasonably use it with
slow and/or salted hashes (with many different salts) or with a few CPU
cores, but when your hashes are fast (like raw MD5) then using this with
100 CPU cores becomes unreasonable.
> It would be nice if there was --conf=NAME option that would allow me
> to specify which john.conf file to use. And I could distribute
> the john.conf's ahead of time to all the systems. Imagine a system
> with 16 cores? and they all have to use the same john.conf FILENAME.
> What if I want to CNTL-C and the '--restore' at a later time?
You seem to be referring to some usability problem that I don't
understand. Sorry. Maybe you could describe it better. ;-) You do
realize that the session names (and filenames) are completely
independent from the configuration file name, and that they're already
being specified on the command-line, right?
Thanks again,
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.
