Attack Editor Pain Points#

OK, the next set of pain points involve Attack editing.

• In the previous version the attack editor takes over the entire session and is just a single form that is hard to navigate with every hashcat attack option in there, even though my users never use several of them.
• One issue that applies to all attacks is that there should be an indicator in the attack editor that tells you same keyspace number and complexity value as would be shown in the campaign view, but it updates dynamically as you modify the attack settings. So the backing endpoint needs to handle attacks that are not persisted.
• Another issue is that if you modify an attack that has been exhausted or is already running, it should warn you and demand confirmation. If you click yes, it should kick the attack back to pending and it should start over on the agent.
• A few issues that are specific to different attacks. I'll break these up by attack type:
  • Dictionary:
    • The user should be able specify how many characters they think it might be with the defaults in the minumum and maximum fields being the defaults for the hash_type (or just 1 to 32 since they're usually keep the optimize kernel feature on).
    • The word list selection should be done with a searchable drop down that should show the number of entries in the word list and maybe be sorted by last modified so the most recent ones show up first
    • They should be able to add some very simple rules by clicking some "Modifiers" buttons such as "+ Change case", "+ Change Character Order", and "+ Substitute Characters". They shouldn't have to understand how that works under the hood. This gives them basically a dictionary attack + rules, without them realizing that's what they're doing.
    • If they do know what they're doing, they should be able to select a rules list file.
    • There should an option in the dictionary attack editor to choose "Previous Passwords" instead of a specific dictionary, in which case it should just use every plain text that has ever been recovered for the entire project.
    • Similar to how I'll describe for mask attack, you should be able to choose not to use "Previous Passwords" or a dictionary file and instead be able to add a single word. You should have a small button in this fieldset that says "Add word" that adds another small text field to add another word. This has the effect of creating a one-time use word list that only applies to this attack and doesn't show up in the larger list of available word lists and is deleted when the attack is deleted.
  • Mask (manual, not mask list file):
    • When creating a new mask attack you should be able to add a containing the mask, but then click a small button "Add mask" and add another line with a mask. There should be an X button next to the mask input line to remove the mask entry. This has the effect of basically generating a one-time mask list that applies only to that attack and shouldn't show up in the Resource Browser or when generating other attacks. It also gets deleted when the attack gets deleted.
    • If you put an invalid character in the mask field, it should indicate the edit field is invalid just like it would for a normal editor field.
  • Brute Force:
    • This is basically an incremental mask attack, but with a nicer UI. You should have check boxes with the different character types ("Lowercase", "Uppercase", "Numbers","Symbols", "Space") and it should create a mask that is basically ?1 * maximum_increment_number and then the first custom characterset is the tokes for whichever character type is selected in the UI. So, if the user pick the range of 5 to 7 characters with only lowercase and numbers selected you'd have the mask as ?1?1?1?1?1?1?1 and character set 1 being ?l?d. It's a connivence for the user.
• Users have asked for the ability to save an attack or an entire campaign as a file to their local computers and then load it in later to create new campaigns. We can define our own schema, but it should be JSON-based.