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.