[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1CB5A995-C8A7-47E5-9D5F-CA8DE94D1DF0@shinnok.com>
Date: Tue, 19 May 2015 17:24:06 +0300
From: Shinnok <admin@...nnok.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 May 19, 2015, at 12:06 AM, Shinnok <admin@...nnok.com> wrote:
>
> 1. Turn the m_showJohnProcess into a JohnProcess type too.
> 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:
> 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.
7. Let's add some simple john version detection(core vs. jumbo) early on so that we don't tie things out of commodity. Just grep from john --version output for "jumbo" string. Store the result in a QSettings value. Use it to enable and disable functionality and UI respectively. For now just the show=types.
Shinnok
Content of type "text/html" skipped
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.
