Date: Thu, 14 May 2015 00:26:55 +0300 From: Aleksey Cherepanov <lyosha@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: displaying full meta information about hashes with --show=types 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. An example output from parser: valid format LM (disabled 0, dynamic 0) orig: cccccccccccccccccccccccccccccccc 2 parts: $LM$cccccccccccccccc $LM$cccccccccccccccc valid format HAVAL-128-4 (disabled 0, dynamic 0) orig: cccccccccccccccccccccccccccccccc 1 parts: $haval$cccccccccccccccccccccccccccccccc valid format lotus5 (disabled 0, dynamic 0) orig: cccccccccccccccccccccccccccccccc 1 parts: cccccccccccccccccccccccccccccccc this parser does not support not orig hash, see line 3 of input file (format MD2) valid format mdc2 (disabled 0, dynamic 0) orig: cccccccccccccccccccccccccccccccc 1 parts: cccccccccccccccccccccccccccccccc Hm, mdc2 and lotus5 have identical canonical forms, not good. md2 format adds its tag in prepare() thus the warning "this parser does not support not orig hash". I'll clean the todos and prepare pull requst. Thanks! -- Regards, Aleksey Cherepanov View attachment "parser.pl" of type "text/x-perl" (1795 bytes) View attachment "full.patch" of type "text/x-diff" (11995 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.