[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150520162309.GB16921@openwall.com>
Date: Wed, 20 May 2015 19:23:09 +0300
From: Aleksey Cherepanov <lyosha@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Johnny: 1.5.2 Hash type suggestion/guessing, using
--show=types
On Tue, May 19, 2015 at 12:06:07AM +0300, Shinnok wrote:
> 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.
QRegexp should not be really needed because the string is split by
strings, not by regexps (regexps are used in Perl because Perl uses
regexps for everything): split by ":" and by "::", that's all (though
: may be other char, the last in line).
> >
> > 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?
Yes, format to use may be specified with --format= option (on options
tab already). We may reduce list of available choices in --format=
option to those found in the file (not even showing them in table
view).
john can load only 1 format at a time. So to attack file with hashes
of 2 types, user needs 2 john invocations per attack. If user
specifies format then john don't load hashes that can't be loaded as
this format.
pwdump is special: only LM and NT formats can handle it. Other formats
don't get hashes from fields #2 and #3. l0phtcrack-style file formats
may be special too.
Example: we have raw-md5 and NT (in the first field, not in pwdump
format). All of them are just 32 hex digits. By default they are
loaded as LM. With --format=raw-md5, both are loaded as raw-md5. With
--format=NT, both are loaded as NT.
> On that same note, what does JtR do when a hash falls under multiple cipher types?
john uses the default one. I guess it is first in the list of valid
formats. Jumbo also shows warnings that the first line is valid as
other formats.
A hash may be valid for different formats in various cases: 2+
implementations of format (some implementations have different max
lengths of possible passwords, so some implementations can't crack
long passwords but are faster for other passwords), hash looks
ambiguous (bare 32 hex may be both LM and NT and a plenty of other
formats; some hashes may be even crackable as two formats: md5 and
md5u as I wrote).
> 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).
(I did not really read below, sorry.)
Thanks!
--
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.
