Re: Lua bugfixes and a new buffering feature

[Stoiko Ivanov <stoiko () xover htu tuwien ac at>]

Hi,

On Sat, Jun 23, 2007 at 05:19:12AM -0700, doug () hcsw org wrote:
> Hi nmap-dev!
>
> I just found 2 showstopper bugs in the PCRE-Lua interface, fixed them
> and committed the fixes to SVN. It seems to work fine now although the
> documentation is still hopelessly insufficient for anybody that
> doesn't know how to read the C source code. :)
>
> The REAL required interface is:
>
> my_regex = pcre.new("my PCRE pattern", 0, "C")
>
> my_regex:exec(string_to_match_against, 0, 0)
>
> I am caching the compiled PCRE regexps into the NSE registry using
> a fairly straightfoward scheme:

Great! - I'll make sure to update the docs on pcre
> ...snip... 
>
> Then I'm having the action() function (NOT the portrule function) call
> init() so that these regexps are compiled at most once per Nmap
> invocation and only then if the action() function for the script is
> actually called.
>
> Perhaps it would be useful to look for an init function which is called
> only once per script per nmap invocation and only right before action()
> is called? Another solution we should consider is passing a table to the
> action function that scripts can use for cross-invocation persistent data

Actually variables defined (either as local or not) outside of functions in
a nse-script keep their value during multiple invocations of the script. 
So if you define an empty table right before the action function and fill
it during the first run of the action, the data saved in it will be
still there during the next invocation(s).

> structures. This would avoid any possible registry conflict problems
> (every script would have its own table if it wanted it). I don't know if
> better registry naming is required or not.

I think as long as each script, which uses the registry, uses its 'id' as
part of the key, we should be rather save. 

Maybe it would be a good practice if every script using the registry would
create its own table in the registry using its 'id' as key.

> IMPORTANT NOTE FOR NSE SCRIPT WRITERS: Don't use the function
> receive_lines() unless you plan on doing your own line parsing.
> This function WILL RETURN MORE THAN JUST THE FIRST LINE OF DATA
> IF MORE IS AVAILABLE.

I'll take a look at it - maybe there is an easy way to replace
receive_lines with your buffer-approach, which seems more flexible anyway.

> ...snip...
>
> Best,
>
> Doug

cheers
stoiko


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