[john-dev] Re: hash type identification (from john-users)

[magnum]

We have built-in hash type autodetection in JtR: when invoked without a
--format option, yet given file(s) with at least one valid-looking hash
encoding, JtR will print the detected hash types and their corresponding
--format options.
In jumbo, I think there are additional ways to query this information,
for scripting around JtR, but I am not familiar with this. Frank,
Alexander Cherepanov - maybe you'd comment on this? And maybe we need
to make this easier to find and use?

"Git blame" says it was Aleksey. I'm not familiar with that either but
this reminds me: I'd appreciate if this "--show=types" stuff that's now
wedged into ldr_split_line(), could be moved to a separate
function/functions. The function(s) can still be called from
ldr_split_line - I just want the code separated for readability and
mergability. As written now, it will be a royal pain to merge and it has
already given me headache when debugging unrelated problems.

magnum

[Aleksey Cherepanov]

We have built-in hash type autodetection in JtR: when invoked without a
--format option, yet given file(s) with at least one valid-looking hash
encoding, JtR will print the detected hash types and their corresponding
--format options.
In jumbo, I think there are additional ways to query this information,
for scripting around JtR, but I am not familiar with this. Frank,
Alexander Cherepanov - maybe you'd comment on this? And maybe we need
to make this easier to find and use?

"Git blame" says it was Aleksey. I'm not familiar with that either but this
reminds me: I'd appreciate if this "--show=types" stuff that's now wedged
into ldr_split_line(), could be moved to a separate function/functions. The
function(s) can still be called from ldr_split_line - I just want the code
separated for readability and mergability. As written now, it will be a
royal pain to merge and it has already given me headache when debugging
unrelated problems.

Ouch. I'll look into that. Thanks!