Re: Script selection - Gsoc

[David Fifield <david () bamsoftware com>]

On Thu, Apr 01, 2010 at 09:03:25PM +0200, Martin Holst Swende wrote:
> I thought a bit more about argument handling, and instead of just
> throwing ideas around, I implemented something a bit more concrete to
> show what I mean. I picked a script which uses arguments, it happened to
> be dns-zonetransfer.nse.
>
> To that script, I added the function :
>
> script_args = function()
>     return     {name="dnszonetransfer.domain", desc="Domain to transfer"},
>             {name="domain", desc="Fallback domain to transfer if
> dnszonetransfer.domain is not set"}
> end
>
> And modified the action function by basically just removing a call to
> nmap.registry as thus :
>
> action_ = function(host, port, args)
>     local soc, status, data
>     local catch = function() soc:close() end
>     local try = nmap.new_try(catch)
>    
>     local domain = nil
>    
>     if args.dnszonetransfer and args.dnszonetransfer.domain then
>         domain = args.dnszonetransfer.domain
>     elseif args['dnszonetransfer.domain'] then
>         domain = args['dnszonetransfer.domain']
> ...
>
> As you can see, the action is now called action_ . This is because I did
> not want to dive into nse_main.lua, but instead simulated the framework
> by wrapping the original action in another function (which is called
> action). So, something like this could be used by the framework to both
> determine what arguments are used and provide help to the end-user about
> them:
>
> From my view, it seems like a great benefit to have info about arguments
> as lua-code instead of relying on parsing tags from a bunch of files.
> The only drawback as I see it is that all scripts with comments need to
> be modified - but probably only very minor, but please correct me if I
> am wrong. Comments?

Making script arguments defined by code not comments--as we do for
description and categories--is a sensible design decision. There would
have to be a way to get arguments from included libraries too.

I don't like adding an extra parameter to action; isn't the pretty much
the same as nmap.registry.args? Also it puts args at a different
parameter index for portrule and hostrule scripts, which is a little
awkward but maybe it doesn't bother people. But the overall idea is
something I can support. --script-updatedb could then put args in
script.db and Zenmap could parse it.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/