[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F6A0638.1020805@online.de>
Date: Wed, 21 Mar 2012 17:47:52 +0100
From: Dominique Heer <dominique.heer@...ine.de>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoc] JtR GUI
Hi Aleksey,
> As magnum already said the current repo is:
> https://github.com/AlekseyCherepanov/johnny
Good, I'm up to date now. However, it seems like the last commit is 6
months ago. Is this project still alive, does someone actively work on it?
> 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).
Indeed the "options" page looks a bit unclear because of the huge amount
of text. I took a look at how VirtualBox solved this problem and found
it quite praticable, maybe we should do something similiar (that means,
adding some kind of frame at the bottom which shows information when the
user selects a specific option).
> 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.
Okay, I understand. I think the user should be able to clear the messages.
> 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.
You're right, when JtR runs in a separate thread, there shouldn't be any
noticeable slowdowns. I've done something similiar in former times and
didn't recognize any performance problems.
> 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.
Correct me if I'm wrong, but it doesn't seem that Johnny already works
(or am I doing something wrong?). I can neither load a hashlist nor
start an attack, for instance.
> 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.
You may be right, and I guess that treeview is difficult to implement
(anyway in GTK+ it is). Maybe we should put this issue aside and
concentrate on other things.
What do you think about a third column named "Plaintexts" (or something
like that) in which, corresponding to their hashes, the found passwords
are inserted? Is this generally possible? I just found it a nice idea.
Regards,
Dominique
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.
