[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E104DB45-0E52-462C-A998-EABA7C0FB978@shinnok.com>
Date: Tue, 19 May 2015 00:06:07 +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)
I'll bring the excerpts that I think need follow up bellow. I won't have time to assign names to quotes, hope it's clear as is.
> Regarding the parser that I'll have to write in C++, to make things simpler, can I assume that there will be no ':' character inside username, hash etc. I mean assume that when we see a ':', next character will correspond to the next field of the format that you described.
This shouldn't be too hard to do. You have QRegexp and various other Qt text manipulation classes that help a lot. It's good that you have Aleksey's perl script as a reference.
>
> Drawback: having a lot of hashes loaded (even 100, 1k, 10k, 100k?), it
> would be hard to use the drop down lists. When user chooses a format
> for a line, what should it mean?
I don't think we should use a drop down unless we can do something with the selection in regards to JtR. Aleksey, is there anything we can do now or later, say force it to crack using a specific format?
On that same note, what does JtR do when a hash falls under multiple cipher types?
I'm planning on playing with this myself later on in the week to see how well it goes. I want to get rid of the MinGW build issue first(very close).
> BTW did you try some non-trivial cracking with john and with Johnny?
> I don't have a lot of password samples, I found this http://openwall.info/wiki/john/sample-hashes <http://openwall.info/wiki/john/sample-hashes> and a few other examples on internet but If you have interesting samples that you use, please share it. Also, I didn't play a lot with modes wordlist, rules, charset, single crack etc.. I played with them but it's not clear to me yet which options I'd choose in a real attack. Most of the time I use default mode.
Did you participate in the PHD contest, that surely should have had you started. If not we'll find another one for you soon.
> I thought about those two features :
> 1) Add a new column in the password tab called "Type" (at the right of Hash) with a drop down list widget for each password. (a QComboBox)
>
> 2) Later when we add filter(1.6.3), add a filter category Type where we can select with checkbox the types that we want to see/hide in the table view. It will hide corresponding rows.
For now we only need option 1 as part of 1.5.2. Later on we can expand on this as we see fit. Depending on the answers Aleksey gives to the questions above, I guess we'll decide if we use a QComboBox or just a simple text field(comma separated for multiple types). This needs to be a new type in the current Data model.
Regarding the actual implementation, here's what we need to do in order to proceed:
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.
That's all I can think of now.
Wish you good stamina,
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.
