Re: Script selection - Gsoc

[Ron <ron () skullsecurity net>]

Hey,

You should learn the "grep" command (or get an IDE that automates it). The simplest is

grep -r functionname *
or
grep -rc functionname *

They'll tell you where the keyword shows up. 

Hope that helps! 

On Thu, 1 Apr 2010 11:35:51 +0530 kirubakaran S
<kirubakaran1989 () gmail com> wrote:
>    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/


-- 
Ron Bowes
http://www.skullsecurity.org
http://www.twitter.com/iagox86
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/