Add supertask runtime estimation

[SherlockNL]

Show estimated total runtime of a supertask, allowing the user to interactively come to the desired size of a supertask by adding or removing subtasks on the supertask detail page

Features:

• Allow adding and removing subtasks to supertask
• Save line count of dictionary files and rule files in database
• Parse hashcat commands to compute keyspace size. Gratefully uses the code submitted by shivanraptor in New Task: Added Hashcat Command Validation #672
  Thank you, shivanraptor, for sharing your code with the community!
• Compute runtime per pretask of supertask, depending on benchmark values entered by the user
• Currently supports -a0 and -a3 hashcat attacks. Adds 'Unknown' to total runtime estimate when not every subtask runtime could be estimated
• Supports custom charsets for masks in -a3 attacks

Future work and additional remarks:

• To do: add support for other hashcat attack modes
• To do: make the hashcat command parser more robust towards syntax differences in hashcat commands. Note however, that some of these are already taken into account in this commit, such as the difference between "-a0" and "-a 0" for example, or when the command includes consecutive spaces
• Note: the runtime estimate entirely depends on parsing hashcat commands. A pretask meant to be run by another cracker will result in an unknown runtime estimate.

[s3inlc]

Thanks a lot for the PR. I have some minor things which we hopefully can resolve before merging. It gives some nice insights for users for given tasks, additionally the line count is useful even outside of the estimation calculation.

• I'm not completely sure if the benchmark I enter is for one agent (and then gets multiplied by the number of agents in Hashtopolis), or if it's just the total speed I expect my cluster to be able to run. I would prefer that a user has to enter the full speed he thinks the number of agents he would like to run on the task is able of (e.g. maybe he does not want to use all his agents on this task, so he just takes a part of the whole cluster) and also if the cluster is heterogeneous, multiplying by the number of agents may give wrong results. No matter which of the two variants it currently is, it also definitely should be clarified on the form where the benchmark numbers are entered, e.g. stating something like Expected total speed for -a0 attacks.
• The lineCount attribute for the Files also needs to be in the initial sql file (src/install/hashtopolis.sql) which is executed on a new Hashtopolis setup. For the updates it is already implemented correctly in the update script, this is fine.
• In order to get an overview which limitations the parser currently have, is it possible to list where it currently is not as robust as it should (e.g. in contrast to what you mentioned that it is able to get both -a0 and -a 0 already)?
• What does currently happend when it's not able to parse an attack command (e.g. because it's from a non-hashcat cracker)? As long as this just results just in ignoring this task (or e.g. warn the user that it cannot estimate on all tasks as it's currently doing with the unknown runtime) that is fine. As far as I know there are rarely other crackers used and they would be custom so it would be too much work to have something which could parse everything.
• A small note in general for PRs, ideally you already add a changelog entry describing what the PR adds in terms of feature/bugfix/enhancement, so I don't need to do this after the merge where it's not connected to the PR.

I hope it is understandable what I mean, it would be great if you could adjust these small things and then I will gladly merge the PR. Thanks :)

[SherlockNL]

Good points! Thank you for the review. I'll comment on the bullet points one by one.

• The current benchmark to enter is the total speed the user expects this task to be run at. The estimated runtime is simply a summation of the keyspace of all tasks, divided by the benchmark entered by the user.
  I've added clarification to the user in the code

• lineCount has been added to initial sql file.

• Runtime estimation is implemented for -a0 and -a3 attacks.
  For -a0 attacks, the number of lines in the wordlists and rule files attached to the attack are counted and multiplied to get the keyspace size.
  For -a3 attacks, the hashcat built-in charsets (?l?u?d?h?H?s?a?b) are all supported, including custom charsets consisting of these built-in charsets such as "-1 ?u?l?d". Custom hashcat charset files (file extension: .hcchr) and hashcat mask files (file extension: .hcmask) are not supported, and might result in a wrong estimate due to the line count of such a file being taken into account anyway.
  I will add this as an issue on the hashtopolis github.
  Other hashcat attack modes are not yet supported, although it is relatively straightforward to add them given the current code. I will add this as a feature request issue on the hashtopolis github.
  About what I mentioned before, "make the hashcat command parser more robust towards syntax differences in hashcat commands":
  My proposal is to change optparse.hashtopolis.1.1.1.js so that it will deal with the difference between "-a0" and "-a 0" for example. Currently, the attack command is being homogenized in hashtopolis code so that optparse.hashtopolis.1.1.1.js will process it properly. This is done from line 206 in src/templates/supertasks/detail.template.html.
  It is unknown which attack commands would be accepted by hashcat itself, yet not processed properly in the current code.

• Good thing you mentioned this. In general, a failure to parse an attack command (such as for generic crackers) will result in the runtime estimate of that task to be listed as "Unknown". I noticed that this was not always the case yet, and fixed this in the latest commit.

• Of course. I've updated the changelog.

Thanks again!

[zyronix]

Talked with @s3inlc and this still is a very usefull pull request. The following should be implemented:

One of the tables contained a vertical scroll bar, remove that

• One of the tables contained a vertical scroll bar, remove that. The table is the pretast not part of the supertask
• Add horizontal seperator, have it between the tables / headers (two seperators total)
• Change color of the add button and make it green
• Add some more spacing to the calculation button, between the button (my-1)
• Add it to:
  https://github.com/hashtopolis/server/blob/master/src/dba/models/generator.php (lineCount)
• Add more explanation to make it more user friendly -> do some explantation with a modal and maybe point to the wiki. Remove the (i).

[zyronix]

Continued work in #750