[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150514120046.GA29232@openwall.com>
Date: Thu, 14 May 2015 15:00:46 +0300
From: Aleksey Cherepanov <lyosha@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Johnny: 1.5.2 Hash type suggestion/guessing, using --show=types
(was: displaying full meta information about hashes with --show=types)
Mathieu,
On Thu, May 14, 2015 at 12:26:55AM +0300, Aleksey Cherepanov wrote:
> On Wed, May 13, 2015 at 08:37:58PM +0300, Aleksey Cherepanov wrote:
> > On Sun, May 10, 2015 at 09:43:45PM +0300, Aleksey Cherepanov wrote:
> > > I implemented --show=types option that prints all meta information
> > > about hashes from file. It tries all formats against all hashes and
> > > prints result in machine parseable format. It applies even formats
> > > that are disabled. It tries generic crypt always. It respects
> > > --format= option. It does not bypass john's heuristics for generic
> > > crypt.
> >
> > I am almost done with it for now.
> >
> > From comments:
> >
> > The format:
> > Once for each hash even if it can't be loaded (7 fields):
> > login,
> > ciphertext,
> > uid,
> > gid,
> > gecos,
> > home,
> > shell.
> > For each valid format (may be nothing):
> > label,
> > is format disabled? (1/0),
> > is format dynamic? (1/0),
> > does format use the ciphertext field as is? (1/0),
> > canonical hash or hashes (if there are several parts).
> >
> > All fields above are separated by field_sep_char.
> > Formats are separated by empty field.
> >
> > Additionally on the end:
> > separator,
> > line consistency mark (0/1/2/3):
> > 0 - the line is consistent and can be parsed easily,
> > 1 - field separator char occurs in fields, line can't
> > be parsed easily,
> > 2 - the line was skipped as bad NIS stuff, only login
> > and ciphertext are shown,
> > 3 - the line was skipped parsing descrypt with
> > invalid salt, only ciphertext is shown (together
> > with empty login); empty lines fall here,
> > separator.
> >
> > The additional field_sep_char at the end of line does not
> > break numeration of fields but allows parser to get
> > field_sep_char from the line.
> >
> > A parser have to check the last 3 chars.
> >
> > If the format does not use the ciphertext field as is,
> > then a parser have to match input line with output line
> > by number of line.
>
> I fixed the mistake and the output is as described. The patch is in
> attach. Also I made easy parser that reformats the output.
The patch was pulled into bleeding-jumbo branch (default). So pull the
new version and try to run it against some files. You'll see the
output, the format is described above. Skeleton of parser in Perl is
in attach.
Run: john --show=types <m_hashesFileName>
I guess you may collect the following useful data from the output:
- per line lists of valid formats,
- global list of valid formats.
Possible features:
- global list may be used to limit list of available formats on
options tab,
- per line lists may be used to show possible formats in the table
view.
I am not sure about the features. I hope Shinnok has some ideas about
1.5.2.
Files in PWDUMP format need special handling: per line list show only
lm and nt, lm for 3rd field and nt for 4th field. IIRC Johnny shows lm
and nt on separate lines. When you read the file with hashes, you may
need to remember if line is in PWDUMP format. I am sure you'll find a
way to connect everything correctly.
I am more concerned about visual part. Please participate in this
discussion too and propose your view 1.5.2. (Similarly comment on
1.5.1 in the dedicated thread.)
BTW did you try some non-trivial cracking with john and with Johnny?
Thanks!
--
Regards,
Aleksey Cherepanov
View attachment "parser.pl" of type "text/x-perl" (1796 bytes)
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.
