Date: Wed, 13 May 2015 20:37:58 +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 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. END --show=types respects --bare-always-valid=[YN] (and related setting in john.conf), it seems convenient. Though as I wrote before: --bare-always-valid=Y and the setting work only if a hash on the first line is bare. John does not have such thing as original ciphertext. ciphertext variable contains original ciphertext part of the time and not in all file formats: file formats like pwdump have support built into formats' prepare() methods (like nt). NT's prepare() method returns a hash constructed from fields if fields is not a hash and fields is lm (hex x 32). It does not return fields as is, it adds $NT$ tag! So there are two observations: 1) if prepared hash is not equal to contents of ciphertext variable, then printed information is about the input line, not about particular field. A parser may find the input line by number. I hope I print 1 line for each input line (I am not sure though). The field that *ciphertext eq prepared is to simplify possible parser or at least initial implementation: a) initially complex case may produce a load error, b) there are several format that work (login:hash:... and just hash on line, and maybe others). 2) --show=types tries a _line_ against formats, not ciphertext variable. So if a line is in pwdump format, fields is tried as LM, fields is tried as NT and nothing more because all(?) other formats use fields that is uid in pwdump format. Similar problem may exist for l0phtcrack-style files and other formats that keep ciphertext not (only) in fields. It seems to be ok: pwdump is special. Other formats are special too. Maybe --show=types should have a flag about *ciphertext eq fields. Or just fields and not ciphertext variable to make it less confusing with pwdump format. Or maybe it is an over-engineering. I think there are minor problems that does not affect main usage (like field sep char == '\n'). So I'll leave them for future improvements. Showing of salt and costs for each hash may be interesting for johnny and other tools to let user split hashes mindfully. It seems more appropriate to a moment in workflow when we know the format of hashes. I think another option may be introduced. Anyway it would be hard to implement that at the place of --show=types. Maybe it should be a part of --no-tty interface: john loads hashes and outputs what was loaded, what salts ids were used and what costs are, then john proceed to cracking. So --show=types does not show "full meta information about hashes". I am going to prepare pull request. A patch is attached. Thanks! -- Regards, Aleksey Cherepanov View attachment "full.patch" of type "text/x-diff" (12052 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.