Nmap Development mailing list archives
Re: Lua bugfixes and a new buffering feature
From: Stoiko Ivanov <stoiko () xover htu tuwien ac at>
Date: Mon, 2 Jul 2007 21:36:05 +0200
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
Current thread:
- Re: Lua bugfixes and a new buffering feature Stoiko Ivanov (Jul 02)
- Re: Lua bugfixes and a new buffering feature Diman Todorov (Jul 03)
- Re: Lua bugfixes and a new buffering feature Fyodor (Jul 04)
- Re: Lua bugfixes and a new buffering feature majek04 (Jul 04)
- Re: Lua bugfixes and a new buffering feature Fyodor (Jul 04)
- Re: Lua bugfixes and a new buffering feature Diman Todorov (Jul 04)
- Re: Lua bugfixes and a new buffering feature majek04 (Jul 04)
- Re: Lua bugfixes and a new buffering feature doug (Jul 04)