[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F69AEEE.7000205@online.de>
Date: Wed, 21 Mar 2012 11:35:26 +0100
From: Dominique Heer <dominique.heer@...ine.de>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoc] JtR GUI
Hi Alexander,
Thanks for you reply. Is this: https://github.com/shinnok/johnny the
current development status? I will refer to it in this mail.
In my opinion, the current GUI lacks a little bit clearness: there's the
main menu bar with File - > Open Passwd File etc., and beneath, there's
a second menu bar containing quite the same. I don't see why we should
have two panels offering the same actions. The options tab is okay,
however the user may be confused because we have an Options tab, a
Settings tab and in the menu bar again Options -> Preferences. What's
the difference between the Settings tab and Options -> Preferences in
the menu bar?
Furthermore, there are two tabs called Output and Log, but for me, this
is quite the same. Not sure which messages refer to output and which to
log. Also, I mentioned some points like the possibility to export
cracked hashes or save the logfile, a status bar which notifies the user
when a hash was cracked and a third table row named Plaintexts, but I
cannot see them in the current GUI. Shouldn't be that hard to implement
this, I guess.
You're right, we should discuss performance issues laters, optimization
is usually done when the project is nearly finished and not when it's in
the fledgling stages :-)
One last question: you're planning to pipe JtR's output to the GUI by
using popen, right? But how can you actually calculate the current
progress? Does JtR output this? Or does the progress bar show the
percentage of cracked hashes? I was just curious because I've never seen
JtR printing some kind of progress ...
Dominique
On 20.03.2012 23:43, Solar Designer wrote:
> Hi Dominique,
>
> Thank you for bringing this to the list.
>
> On Tue, Mar 20, 2012 at 04:33:50PM +0100, Dominique Heer wrote:
>> It seems like several incomplete approaches for a GUI are existing, for
>> example Aleksey's or Shinnok's, and I'm a little bit confused which of
>> them is the one we want to continue working on. I took a look at
>> Shinnoks GUI called 'johnny' and found it quite promising (and I
>> referred to it in my last mail, sorry if you were talking about
>> something different),
> There's just one current version: the one started by Shinnok and
> continued by Aleksey. Yes, it is called Johnny.
>
>> although it is somehow 'too much'.
> What do you mean by that?
>
>> However, I now understand the performance issue, and it is also an issue
>> of clearness: in my opinion, when the user loads one million hashes or
>> even more, it doesn't make very much sense to show them all in a single
>> table. Maybe we can use some kind of sorting or a hierachical tree view
>> (as shown here:
>> http://qt-project.org/doc/qt-4.8/images/windowsxp-treeview.png) that
>> allows the user to expand and collapse certain rows. Don't know if Qt
>> supports this and if its easy to implement ...
> I did not mean to emphasize this performance and scalability issue - I
> merely answered your question (off-list) on what it was about. That
> said, speaking of a possible hierachical tree view, a difficulty is in
> deciding how to reasonably turn the list of password file entries into a
> tree. We could simply use a two-level hierarchy, with the top level
> having collapsible entries, say, for each 1000 of the original list's
> entries (so they'd be called e.g. 1-1000, 1001-2000, and so on). Or we
> could group/split them e.g. by the first character of the username (then
> we'd have the original problem back e.g. if an artificial sample file
> has all entries with the same username). Or we could have separate
> sub-trees for fully-cracked/partially-cracked/not-cracked passwords
> (just 3 or 2 of them, depending on hash type). Or we could have
> separate sub-trees by hash type (if multiple hash types are present at
> once). Or we could combine several of these approaches (then we'd have
> more than two hierarchy levels). Maybe these should be optional
> alternatives to the obvious flat list approach, which I think we should
> support either way.
>
> 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.
