mailing list archives
Re: Script suggestions
From: Martin Holst Swende <martin () swende se>
Date: Sun, 04 Dec 2011 20:53:20 +0100
On 12/04/2011 05:25 PM, Djalal Harouni wrote:
On Sun, Dec 04, 2011 at 04:07:19AM -0500, Patrick Donnelly wrote:
On Mon, Nov 28, 2011 at 12:43 PM, Duarte Silva
<duarte.silva () serializing me> wrote:
On Monday 28 November 2011 00:52:35 David Fifield wrote:
On Sun, Nov 27, 2011 at 10:34:44PM +0000, Duarte Silva wrote:
The script option may be specified without arguments. So if you could
take it as an example I guees it would make your live easier ;)
--script requires an argument. You may be thinking of -sC (which is
really the short option -s taking the argument "C" in disguise).
It's possible to have options that take optional arguments, but I don't
think we should because it works in a suprising way. It requires you to
use '=' instead of a space after the option.
Then, it seems the two options, -scS (no arguments) and --script-suggest (same
arguments as --script) are viable options. As I come to think about it, this
way is even better.
Maybe what we really need is an option which allows the user to pass
directives to NSE. For example:
possibly in some sort of option=argument format. I could see
--script-updatedb being replaced with a directive.
I also think that we need some arguments/directives to control NSE
We should try to define the best approache to take. Currently this is the
list of options that affect directly NSE's behaviour:
o Others that use --script-args like the 'newtargets' stuff.
o We can also count the 'script suggest' and 'script force' features ...
IMHO most of these features are related to NSE behaviour more than scripts
or Nmap. Another feature is the possiblity to control how NSE output is
reported, especially for large networks, we could add an argument to let
NSE report results as early as possible (to not concatenate data).
The '--script-directives' seems currently the best proposed approache,
at least for me. It should handle any new NSE feature that can not
be done in the '--script-args' or '--script'.
Here's a suggestion, why not let all directives have double syntax? E.g,
lets say we add
the directives 'crash' and 'burn', which crash the nse and set fire to
the target machine respectively.
These would be sematically equivalent:
nmap -sC <target> --script-directives=crash=200ms,burn
nmap -sC <target> --script-crash=200ms --script-burn
By adding such a mechanism, we could incorporate all previous
The only one that would be awkward to fit into this would be
--script-args, since it would be like a three-level-nesting of args:
This idea could be implemented with some refactoring in how nmap parses
options, and would probably simplify the code a bit. I don't see
any point in *removing* shortcuts such as --script-help or
Another idea while we're at it, why not add default supershortcuts:
crash : C. ==> -sCC : crash with default (whatever that is)
suggest: S ==> -sCS : suggest=all
help : H ==> -sCH : no default exists, same error as --script-help
The code to add another directive would just be to write a new
directive-definition, and the rest would just fall into place by itself,
of having to fiddle with that gigantic switch-statement...
Anyway, I don't really see this as a necessary prerequisite for adding
--script-suggest, I see it as a nice refactoring.
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/