[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86fwq8qc1u.fsf@gmail.com>
Date: Mon, 28 Mar 2011 05:16:45 +0400
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Interface for John
I did not mentioned that i am also a student and i am looking for
GSoC. I am sorry for that.
I wrote a simple interface for John. It is not complete and is more an
example of code rather than a real interface. It is available at
http://code.google.com/p/aleksey/downloads/detail?name=john_simple_gui.001.py&can=2
. It does not support multiple John or even stopping one that runs but
it written in wxPython. I make a gui from the code but with WxWidgets it
is also possible to use xml to define gui and there are tools to do it
easily. For instance, wxGlade seems to be for WxWidgets like Glade for
GTK providing a featurefull gui designer.
During this small development i studied that there are wxCheckListBox
that is a listbox which each element has checkbox in. Also i found that
wxGrid has a way that is suggested for big amounts of data by
documentation (wx2.8-doc/wx-manual.html/wx_wxgrid.html): "For
applications with more complex data types or relationships, or for
dealing with very large datasets, you should derive your own grid table
class and pass a table object to the grid with wxGrid::SetTable." It
should drows first time faster but for instance scrolling may be
slow. But with so big table scrolling seems to me as about useless
thing. To manage such tables it could more useful to have flexible
filtering system.
On other hand i faced a problem with parsing of John's output. I think
about password as about untrusted data that is unpredictable (at least
if a user is not restricted to brute only alphanumeric, for instance
with its own algorithm that includes fancy charachters). Both filtering
system and unpredictable input make me think about some sort of database
to interchange with John. Also it may improve John's scalability. But
changes in John and writing gui for that changes will make gui not
compatible with any old versions of John that someone could value. Even
with the right data exchange between John and gui there is a problem
about how to show strange data in the ui. I could imagine problems with
charachter encodings, exactly with bad utf-8 sequences.
Also as i understood gui should bring new users to JtR but it is also
needed to support all advanced features like very big hash files. Hence
there should be a lot of settings. But they could afraid new users. So
who is gui for firstly? If gui is for new users then it may be important
to concentrate on a usability and work "out of the box" with many hints
for new users rather than on advanced features.
I am looking forward for some critic.
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.
