Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 18 May 2015 21:51:27 -0400
From: Mathieu Laprise <mathlaprise@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Johnny: 1.5.2 Hash type suggestion/guessing, using
 --show=types (was: displaying full meta information about hashes with --show=types)

On Mon, May 18, 2015 at 5:06 PM, Shinnok <admin@...nnok.com> wrote:

> Did you participate in the PHD contest, that surely should have had you
> started. If not we'll find another one for you soon.

Yes, I have a lot of hashes now from the contest.


> 1. Turn the  m_showJohnProcess into a  JohnProcess type too.

Done.
2. The --show=types will be very similar to the previous show invocation.

> 3. Output from no.2 needs to be parsed before we pass it back to the UI.
> Write the parser in a separate method(if it suffices) in a util.h. Now this
> leads us back to the threading question. We can't reasonably do this
> parsing as well as the one from no.2 in the UI thread. A "modern" JtR
> invocation easily assumes 100.000 hashes at least. If we keep doing this in
> the UI thread we are doomed to fail, no joking here and no pun intended.
> Keep in mind that if a GUI app doesn't respond to WM events for as low as
> 500ms on modern desktops the WM perceives the application as "Not
> responding" will most likely grey it out and soon after it will offer to
> terminate it. For now we can do baby steps:

I 100% agree about this.

> 4. Subclass JohnProcess class from QRunnable. Implement the run() method
> to call start and do blocking wait. We'll end up with both ways of starting
> a john process(as a qrunnable and directly like we do now, thus we break
> nothing). I can help you with any trouble you will encounter, please reply
> to the other backend separation and threading e-mail on this list. If you
> need some threading and Qt material on the topic ask for it.
> 5. We need a way to keep track of the various john process we keep
> spawning. This gets us back to the backend separation discussion. For now
> we only need a simple class called TaskManager or TaskController. I'll
> write the basic stub for it, then Mathieu you can extend it further. We
> will use  QThreadPool and the start method. This pool automagically resizes
> and scales to available cores and cpus on a system, we don't even have to
> manage it, just queue stuff. This includes parsers like the show types,
> 2john's, the upcoming filtering code, and whatever we might devise along
> the road.
> 6. Any output resulting from any task in the TaskManager, including the
> show types parser should be signaled back to the UI, using
> Qt::QueuedConnection and in a fashion so that it is readily and easily
> consumed by the UI thread. For this show types case we would probably
> signal a vector of QStringList or a QMap<int, QStringList> if the rows will
> ever be the movable type. Only plain datatypes, lists and maps, nothing
> more complicated and nothing raw arrives to the UI. Anything that needs pre
> or post processing is done outside of the UI thread.


Last week, I coded the initial design of the feature. Instead of having
MainWindow deals with process and all events like what is done by johnShow,
I thought last week about a wrapper class HashTypeChecker class which would
abstract that. Even though the feature isn't working perfectly and isn't
tested a lot for now, I opened a pull request for you to see what were my
ideas from last week and today https://github.com/shinnok/johnny/pull/10 .

I thought about sending the list in the signals like you said too to be
more MV, I just want to make sure that we can pass reference in signals so
it isn't "copied". Right now, my plan is pretty similar to the ideas that
you said today. Please take a look at my PR to see if you like or don't
like  my view of the design and I can changes things based on what you said
today.
https://github.com/shinnok/johnny/pull/10

[ CONTENT OF TYPE text/html SKIPPED ]

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ