[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP45350640AD9FDE04794B590FDCF0@phx.gbl>
Date: Mon, 6 Aug 2012 11:20:44 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Aleksey's status report #14
On 08/05/2012 09:22 PM, Aleksey Cherepanov wrote:
> - settings work now, i.e. they are loaded on start-up
>
> You could find settings in
> ~/.config/Openwall/Johnny, the GUI for John the Ripper.conf
> So to remove them use
> $ rm ~/.config/Openwall/Johnny,\ the\ GUI\ for\ John\ the\ Ripper.conf
>
> - john auto search
>
> If user did not specify path to john then at start up johnny searches
> for it in PATH then checks predefined places (currently only
> /usr/sbin/john like on Debian). The same check is done when user asks
> johnny for default settings.
You should also use this logic if the user cleared that input and saved
the settings. i.e., if the config file contains this line
PathToJohn=
or no PathToJohn= line at all.
> In PATH johnny searches for 'john' (i.e.
> not for 'john-gpu' or whatever). Johnny splits PATH in platform
> dependent way: by colon while on windows systems separator for PATH is
> semicolon. Johnny checks possible place to be a readable and
> executable file.
If it is a symlink, I think you should follow that symlink. (I didn't
check whether you do right now.) It might point to a john-omp binary.
If it does, use the symlink as PathToJohn.
> - clean gui up
>
> I disabled all buttons intended for jumbo.
OK
> Priorities
>
> - finish team write-up
Yes.
> - sessions
>
> - hardcode formats list for core john
Can't you use john's usage output instead?
This should work for core and jumbo.
The only difference is that you need to split at '/' vs. ' ', depending
on the version.
I think you have done this before. The bash completion script does the same.
Just run john without parameters just once, parsing the output to
collect format names (and in a later revision after GSoC, may be other
information as well, to see which options are supported, allow optional
parameters, ...).
> I think I could postpone real way of doing things because it is harder
> and it is not very important.
Yes, as Solar mentioned, don't put too much effort into this right now.
So a list of formats obtained from usage output (plus the auto-detect
option) ought to be good enough.
For later:
May be for a GUI version, we only need to let the user choose the format
if there are ambiguous hashes in the input file.
For the core version, there shouldn't be such cases, unless the user
mixed input of various sources into a single file.
Checking which of the formats supported by the current john version
really appear in the input file is more complicated and should be
postponed after the end of GSoC.
> - my brother pointed me out that john understands different file
> format, i.e. not only user:hash:others is right. It affects my file
> loading and it also affects parsing of `john --show` because it shows
> info in the same format. I did not yet investigate this question. Is
> it important problem now? Any hints?
Solar already answered this one.
Frank
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.
