New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature: next generation of outfile format #1664

Open
roycewilliams opened this Issue Aug 17, 2018 · 0 comments

Comments

Projects
None yet
2 participants
@roycewilliams
Contributor

roycewilliams commented Aug 17, 2018

The outfile format has much potential, but we need a new way to express it.

The current method consists of IDs like the following:

  1 | hash[:salt]
  2 | plain
  3 | hash[:salt]:plain
  4 | hex_plain
  5 | hash[:salt]:hex_plain
  6 | plain:hex_plain
  7 | hash[:salt]:plain:hex_plain
  8 | crackpos
  9 | hash[:salt]:crack_pos
 10 | plain:crack_pos
 11 | hash[:salt]:plain:crack_pos
 12 | hex_plain:crack_pos
 13 | hash[:salt]:hex_plain:crack_pos
 14 | plain:hex_plain:crack_pos
 15 | hash[:salt]:plain:hex_plain:crack_pos

This method has worked well up to this point, but growing beyond it will be increasing difficult. Adding just a single additional field would be very expensive, as it would require many new additional outfile format IDs.

Instead, I propose a new way to express outfile format fields - one that is extensible, using "variables" for the components.

My suggested approach:

  1. Change "--outfile-format" to "--outfile-format-classic", using the original syntax (for backwards compatibility, but making it clear that this is the new way forward, just like '--markov-classic' was the old default, but must now be explicitly requested).

  2. Create a new "--outfile-format" that uses atomic variables, as follows:

field field variable
hash[:salt] h
plain p
hex_plain hp
crackpos cp

(These are just for demonstration purposes - there may be better variables. That being said, I suggest shorter variables for easier typing).

This method will allow new "variables" to be more easily added later, without having to add a large number of additional outfile formats.

All current outfile formats would be expressed in the new syntax as follows:

classic outfile type outfile format new syntax
1 hash[:salt] h
2 plain p
3 hash[:salt]:plain h:p
4 hex_plain hp
5 hash[:salt]:hex_plain h:hp
6 plain:hex_plain p:hp
7 hash[:salt]:plain:hex_plain h:p:hp
8 crackpos cp
9 hash[:salt]:crack_pos h:cp
10 plain:crack_pos p:cp
11 hash[:salt]:plain:crack_pos h:p:cp
12 hex_plain:crack_pos hp:cp
13 hash[:salt]:hex_plain:crack_pos h:hp:cp
14 plain:hex_plain:crack_pos p:hp:cp
15 hash[:salt]:plain:hex_plain:crack_pos h:p:hp:cp

Syntax would now be

hashcat --outfile-format=h:p:hp:cp

For ease of parsing, only formats containing alpha, digits, and colons would be accepted.

  1. I would then also propose - maybe, later - adding new "variables", not currently supported by hashcat, up for discussion. NOTE that these would only need to be the significant fields that directly affected most standard attacks. These new suggested variables would support supplying more information to inform a distributed or decentralized cracking architecture.
  • 1-4 - custom charsets, just like -1 - -4 today [NOTE: how to resolve if colons are used?]
  • a - attack type, just like hashcat -a parameter today (-a 0,1,3,6,7)
  • d - device type (1 = CPU, 2 = GPU, 3 = FPGA, etc.)
  • e - encoding (output in from,to format)
  • ht - hash target (output would be the raw hash on the command line, or filename, or 'stdin' if stdin was detected)
  • i - increment information, output formatted perhaps as [min],[max], so if no min is specified, ,[max], etc. or empty or just , if no min/max were specified
  • l - limit, just like -l today
  • m - attack mode (hash type) - just like -m parameter today (0, 100, 3600, etc.)
  • ma - mask information - masks from command line, or filename of masks
  • mk - markov information. Output would be of the form d (disabled), c (classic), hcstat:[filename] (if hcstat file is specified)
  • r - rules file(s) (filenames, separated by spaces?)
  • s - skip, like -s today
  • t - markov threshold, like -t today
  • w - wordlist(s) from command line. output for these would be separated by spaces. Perhaps no filenames with colons allowed.

These are rough and would need to be improved a bit.

And then perhaps a few more, brainstorming:

  • f - flags - all other unrecognized flags from the command line
  • I - ??

... or similar.

  1. Side note: I would also recommend that we add documentation, or maybe even enforce, that if any custom outfile formats do not end with h (hash[:salt]), then warn the user and advise that they should consider placing the h variable at the end of the outfile format. This would address the classic hash:salt separator issue.

I realize that some of these would be of limited use at first. But I believe that distributed tools like Hashstack, Hashtopolis, etc. could use them, especially for analyzing multiple runs of information later. They would also support loose collaboration in teams, such as during contests.

I think that there is much potential that would be made possible by this change, and projects and teams could be creative with it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment