[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 Mar 2012 19:36:42 +0400
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoc] JtR GUI
Dominique,
On Wed, Mar 21, 2012 at 11:35:26AM +0100, Dominique Heer wrote:
> Thanks for you reply. Is this: https://github.com/shinnok/johnny the
> current development status? I will refer to it in this mail.
As magnum already said the current repo is:
https://github.com/AlekseyCherepanov/johnny
> 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?
You are right. Not everything is on its places. But settings and
options logical base to exist: "settings" are option of the gui while
"options" are options of current john run/session (sessions are
currently not implemented). I think tips like in VirtualBox could
clarify things a bit in a nice way that is not horrible (like current
one used on options page).
> 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.
Output is what john prints to its output channel. Log is the content
of the log file (john.log, that is written by john). Gui itself does
not have log.
> 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 :-)
I recall that it was considered that reasonable performance should
make johnny not slowing john down. It should be at least so that john
would work about as without gui.
> 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 :-)
I think export is much likely to be done by john itself to provide
console users with the same abilities. Though drug'n'drop could be
nice (for instance Johnny -> LibreOffice Calc). Progress bar could
help user note that password was cracked. Also it is shown in log but
with some lag by design (it is not yet implemented) at this moment:
john writes to log file not as soon as password cracked but as soon as
its internal buffer is filled and every some seconds, on the other
hand to small update time could slow down john so small lag could be
reasonable because it is not common after some time to see password
cracked while john should not be slowed down by gui.
> 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 ...
Johnny already captures john's output through pipe (using QProcess
class, that has functionality similar to popen). Currently progress
shows relation of amount of cracked passwords to amount of all
passwords: cracked / all. It is not really meaningful (john will never
crack 100% at some circumstances, for instance there could be two
types of hashes and john will crack only one while gui shows total
progress) though it shows how much passwords we have and how much are
cracked.
> On 20.03.2012 23:43, Solar Designer wrote:
> >On Tue, Mar 20, 2012 at 04:33:50PM +0100, Dominique Heer wrote:
> >>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 do not think that treeview could speed up presentation because qt
separates table's model and view: it means that it calculates about
only part that you need to see, currently model filling is the time
consuming procedure but treeview will have that too (as I guess) and
maybe it will even slower because it has more complication procedure
to understand what should showed. But treeview could be nice
additional presentation of data.
(Though I could be wrong at any point.)
Thanks for your input! What do you think?
Regards,
Aleksey Cherepanov
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.
