[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120806023532.GE16159@openwall.com>
Date: Mon, 6 Aug 2012 06:35:32 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Aleksey's status report #14
Aleksey -
I think you include too much technical detail right into your reports.
It'd help if you post multiple messages instead: separately the reports
and the individual sub-topics you bring up that should result in
discussions. Note that lengthy messages tend to discourage responses
except perhaps from Frank.
On Sun, Aug 05, 2012 at 11:22:41PM +0400, Aleksey Cherepanov wrote:
> I'll do day reports. I think I'll answer to weekly reports. Ok?
I don't understand what you mean by "I think I'll answer to weekly
reports", so I can't tell you if it's OK or not.
> I started new branch in my repo - dev1.1 (because next release will be
> 1.1 as of there was already release numbered 1):
> $ git clone http://github.com/AlekseyCherepanov/johnny.git -b dev1.1
Looks good. I did not recall that we already used the 1.0 number.
> - progressbar fixed
>
> Currently it works well. Though it shows overall progress on file, it
> is a progress in cracks, i.e. 1 cracked, 9 left = 10%. Probably it would
> be better for users to see percentage of their attack, i.e. 1 day
> spent and 50% means that we should wait 1 day more. But it has its own
> drawback and it seems to be harder to implement. Although we could
> have 2 progressbar: for attack and for overall progress.
This makes sense.
How do you determine the guess count? Please note that the guess count
on the "guesses: ..." line printed while cracking may exceed the total
number of hashes loaded in some obscure cases (e.g., with FMT_NOT_EXACT
in jumbo, as well as if the pot file is removed and then the session is
restored). Do you use --show instead? If so, you should be safe from this.
> - 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
Confirmed. The file syntax looks john.conf'ish - so let's just call it
~/.john/johnny.conf or ~/.john/gui.conf then.
> - 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. 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. First found one is our john. After that johnny shows
> a message box with text about path to john.
This has worked fine with Ubuntu's package of john (found).
As to the colon vs. semicolon issue, maybe Cygwin translates the PATH
value to make programs ported from Unix happy? Are we going to use
Cygwin to build Johnny for Windows? Anyway, your initial target
platform is Linux, so please don't spend too much time thinking of other
platforms just yet.
> - clean gui up
>
> I disabled all buttons intended for jumbo.
>
> - other small clean-ups and fixes
>
> - improved speed for password pulling after `john -show`
>
> Now hash table is used so it works seamlessly. No lags for 10k file
> with 5k cracked passwords. There are some things to improve more here
> but other problems are in the way.
OK.
> Priorities
>
> - finish team write-up
>
> - sessions
Sounds right.
> - hardcode formats list for core john
Would there be a way to specify an unlisted format name, by typing it
into an edit box?
> I think I could postpone real way of doing things because it is harder
> and it is not very important.
>
> - add --users, --groups, --shells, --salts to options page
OK.
> - add --save-memory ?
>
> I doubt it is useful because johnny eats memory itself. Though I do
> not know enough about this options to predict all uses.
You're right, --save-memory is not needed yet - I guess the GUI would
currently start having problems with a smaller hash count than one where
--save-memory would be reasonable to use.
> Problems
>
> Working with code I found some old problems and understood some more.
> They are quite important.
>
> - I could not connect cracked password with original hash
>
> I call `john -show` and read user and password then put password to
> all rows where user is the same. It is wrong and only works when we do
> not have two rows with the same user name.
>
> I could not look into .pot because hashes there could be in other
> form. Though for core john they could be the same, aren't they?
Not necessarily. There's LM with its split into halves and case
unification. There's bigcrypt with its split into halves as well.
> (Mangling hash's form right in johnny does not seem good.)
>
> I could craft new input file where hash is in gecos field also (not
> name). Then `john --show` give me original hash. But it needs
> crafting, i.e. temporary file for new .pot. It seems long way. (Though
> I do not see shorter way now.) Should I do it as a basic
> functionality?
Another approach would be to have a --show sub-mode in JtR where exactly
one line would be printed per input file line, including for non-cracked
hashes (those lines would state that the password was not cracked).
Then you could match by line number.
However, patching JtR itself was not meant to be under scope for your
work in August, and it would slow down adoption of the GUI - or the GUI
would need to include some fallback for working with non-patched JtR.
So I'm afraid the temporary file approach that you describe may be the
way to go for now. Eventually JtR will get a proper feature to support
the GUI better, and this temporary file code will become the fallback.
Yes, I'm afraid that this is part of the basic functionality of the GUI.
On Unix systems, maybe you can use a named pipe instead of the temporary
file. (And maybe a future version of JtR will need to support reading
of password file lines from stdin.)
> - 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?
Yes, this is fairly important. Please focus on pwdump style files for now:
u0:0:aebd4de384c7ec43aad3b435b51404ee:7a21990fcd3d759941e45c490f143d5f:12345::
u1:1:78bccaee08c90e29aad3b435b51404ee:f9e37e83b83c47a93c2f09f66408631b:abc123::
u2:2:e52cac67419a9a224a3b108f3fa6cb6d:8846f7eaee8fb117ad06bdd830b7586c:password::
u3:3:ae6e1b1fccb24d5b944e2df489a880e4:2b2ac2d1c7c8fda6cea80b5fad7563aa:computer::
u4:4:44efce164ab921caaad3b435b51404ee:32ed87bdb5fdc5e9cba88547376818d4:123456::
Currently, core supports only LM hashes in these files, jumbo also
supports NT. As you can see, when you invoke jumbo with --format=nt,
the GUI will also need to know to use the NT hash fields.
Thanks,
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.
