How the Zenmap command line should work
The dream
Ideally, this is how scanning in Zenmap should work.
- The user should be able to enter a command with a typed command line, using a command constructor, or from a profile.
- Command lines should be able to be constructed with an assistant like the current profile editor. The constructed command line would go right in the box, not in a new profile.
- The way to create a new profile is to build a command line (by just typing it or through the constructor) and then save it as a profile. Similarly a profile is modified by selecting the profile, editing the command line, and saving it again.
- However a command line was created (by typing or through the constructor), it can be edited by either method. That is, if you type in a command you can go back and modify it by clicking buttons.
- A scan profile is optional. Typing in a command does not associate a profile with the scan. If you set a command line from a profile and then edit it, the scan should not be associated with a profile.
- The final say for how a command runs is the command line string, not the profile specification. When a scan is loaded from a file, the options that are shown are those loaded from the command line in the file, not from the stored profile name.
However
Realizing this ideal requires Zenmap to parse Nmap command lines so that it can make them editable through the graphical interface. That is, if the command is "nmap -v", it would have to know that the -v checkbox should be checked. Doing this in full generality could be difficult. It is also not worth it if it is too hard to maintain.
Therefore we sacrifice the parts of the ideal that require parsing a command line string.
Requirements
- The user must be able to enter a command with a typed command line or from a profile.
- A scan profile is optional. Typing in a command does not associate a profile with the scan. If you set a command line from a profile and then edit it, the scan should not be associated with a profile. Loading scan results from an Nmap XML file leaves the profile blank.
- Once a single character of a command line is edited, the current profile is deselected (made blank). This guards against the user's typed command line being erased when the profile is inadvertently selected again. Similarly, selecting a different target or starting a scan must not wipe out the user's current command.
- The final say for how a command runs is the command line string, not the profile specification. When a scan is loaded from a file, the options that are shown are those loaded from the command line in the file, not from the stored profile name.
- The command line entry must reflect the command that was actually run, not the options that come from the currently selected profile.
Observations on command line parsing
Zenmap currently has two ways to represent a command: an "internal" representation, which is basically a list of option specifications like "Aggressive Options" and "UDP Scan"; and an "external" representation, just a plain command string. The class CommandConstructor in zenmapCore/NmapCommand.py holds the internal representation and converts it to the external representation through its get_command method. This internal representation leaks out sometimes, like in the file ~/.zenmap/scan_profile.usp:
[Test]
scan random hosts = 500
description =
hint =
options = Operating system detection,Scan random hosts,Max Retries
command = nmap --max_retries 2 -iR 500 -O %s
annotation =
max retries = 2
Those strings "Operating system detection,Scan random hosts,Max Retries" are command specifiers that map to the options -O, -iR, and --max_retries. The arguments are saved as other keys in the section (max retries = 2).
Removing this dichotomy would require putting a command line parser in Zenmap, but it could simplify other parts of Zenmap while enabling the ideal interface described above. Perhaps it would not be as bad as I thought.
