Re: Script selection - Gsoc

[kirubakaran S <kirubakaran1989 () gmail com>]

   In that case I should modify option nmap --script -updatedb option.
it sets scriptupdatedb option as 1 in nmap_main.cc. The function should
be modified such that it  parses @args section and parse 'require' to
find out the arguments completly. I searched and could not locate
the implementation of this update funcionality. can you help me in which
file is this implemented?



On Thu, Apr 1, 2010 at 9:21 AM, David Fifield <david () bamsoftware com> wrote:

> On Wed, Mar 31, 2010 at 11:34:46PM +0530, kirubakaran S wrote:
> > Hi dev,
> >     I am working great on thinking about script selection
> > interface for Gsoc.  I deduced every script have two type
> > of arguments. One is direct argument which is accessed through
> > the nmap.registry.** - lua table.Another argument is variables in library
> > functions which have default values and it can be changed.
> > To design interface I should know what are all the arguments for a
> > particular script, In this case I can parse @args field in script to know
> > which are all essential arguments. But when script developers forget
> @args
> > field or if the script uses argument of library variables we cannot
> > enumerate
> >  what are all library variable arguments for this script. Because script
> > developers do not include @args field for arguments of library variables.
> >
> > Example : In pgsqlbrute.nse arguments are
> > 1. pgsql.version
> > 2. pgsql.nossl     ----> type one
> > 3. passdb, unpwdb.passlimit, unpwdb.timelimit, unpwdb.userlimit, userdb
> >      --> type 2 library variables.
> > But script only provides these lines
> > --@args pgsql.nossl If set to 1 or true disables SSL.
> > --@args pgsql.version Force protocol version 2 or 3
> >    while designing interface if I conclude arguments by parsing @ args I
> > miss the type2 arguments and user cannot change it!!
> >
> >
> >   To solve this problem , like script.db which stores categories of
> > script. store the names of arguments in script_arguments.db file.
> > And conclude the arguments by searching this file.will this solution for
> > finding out arguments for particular script work out? or can anyone
> suggest
> > me what is the best way to find out all arguments
> > for script. correct me If I am wrong..
>
> Storing arguments in a database file is reasonable. They could
> potentially go in the same script.db file. Like Ron said, you have to
> recurse into included libraries to find out all the supported arguments.
>
> David Fifield



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