[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 4 Jun 2015 21:56:14 +0300
From: Shinnok <admin@...nnok.com>
To: john-dev@...ts.openwall.com
Subject: Re: [Johnny] Task 1.6.1 Multiple cracking session management
Mathieu,
My original task was for supporting multiple cracking sessions via a tabbed interface. Previous discussions concluded that this could be useful in certain scenarios. What you're doing now is cracking session history. This is admittedly still useful and I'll create a separate task for this as a first step towards a greater goal. I'll leave further feedback on the Github issue.
Now regarding concurrent cracking sessions, replies embedded bellow:
> On Jun 3, 2015, at 9:58 PM, Rich Rumble <richrumble@...il.com> wrote:
>
> On Wed, Jun 3, 2015 at 2:06 PM, Aleksey Cherepanov <lyosha@...nwall.com> wrote:
>> Mathieu,
>>
>> On Tue, Jun 02, 2015 at 02:14:09PM -0400, Mathieu Laprise wrote:
>>> Also, I understand why we need to keep track of the input password files
>>> and .rec files to achieve this but why do we need to keep track of the .pot
>>> files as Shinnok said ?
>>
>> Shinnok - did you mean something specific?
> It would be nice if Johnny could read the .rec files that may exist
> already and perhaps prepopulate the dropdowns or options. If I
> specified a custom pat file, and wanted to resume cracking, the .rec
> should have that data in it and JtR should reuse that. It would be
> nice to have some "common" features of JtR in Johnny, I can see --pot
> as being one of those. You also don't want to confuse users too much
> so maybe those can be "advanced" features that come out if you choose
> "advanced"?
This is very much desired for multiple concurrent sessions as well as for the time being too. Currently, when we restore a session we don't have a means for repopulating the options, so we trust JtR to do the right thing on resume or define a new attack and start a new attack session.
However, reading the .rec might get messy and with little benefit(we can't change a single parameter without starting a cracking session from scratch). Maybe just keep the settings stored per session via QSettings and repopulate the UI based on that on session restore and leave everything else as it is.
>>> Last but not least, will the "Open session" button becomes a file browser
>>> for any .rec files or will we manually keep track of the 5-10 or 20 last
>>> sessions and show them in a UI friendly drop down list.
>>
>> Johnny has additional .johnny files (only 1 so far) to store its own
>> session description.
> Again if it read all .rec files in the current $john directory, you
> could have a drop down list of sessions, sorted if possible from
> latest to earliest.
>> It is not possible to support .rec files from command line invocations
>> of john in general way: .rec stores paths as provided, so there may be
>> relative paths. To restore such session pwd should be known, it is not
>> trivial to guess it (at least with default .rec file).
> I wouldn't know :) But if your just passing --restore=session_here
> then JtR itself is the limitation. But if Johnny is reading .rec's
> then it should read it how they are in the .rec files already, which I
> believe is how JtR was invoked is how it's stored. I don't see this as
> an issue I guess...I think I'm not understanding this one.
>> AFAIK .pot files are not specified from johnny. Default .pot is used.
>> So it is not needed to track it. User can change .pot file through
>> john.conf but it is not something to handle in Johnny. To specify .pot
>> file is a separate task and I am not sure that it is needed. There are
>> scenarios to use it: user may want to crack from the very beginning to
>> collect statistics by attacks in form of .pot files (one attack - one
>> .pot, `wc -l *.pot` shows stats).
> I do this all of the times, I specify a pot so I can see statistically
> which list, mode or other attack is faster on the same hashes. Again
> maybe an "advanced" button could be used to open up more options.
> I hope I understood what the questions are/were, and I'll be more
> vocal going forward as I want to use a GUI for JtR and I want to help
> others use JtR effectively on windows. I'm not sure I can help past
> testing and suggesting, but I might be able to do tool-tips or
> man/help files, documentation and that sort of thing.
I'm not sure I understand why Johnny should care about the .pots? Keep in mind that we should leave to JtR CLI what's he's and not try to take every attribute from it nor meddle into its bowels. :-)
Shinnok
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.
