Nmap Development mailing list archives
Re: Nmap tty and NSE
From: "Patrick Donnelly" <batrick.donnelly () gmail com>
Date: Mon, 22 Dec 2008 05:27:58 -0700
On Mon, Dec 22, 2008 at 1:04 AM, Fyodor <fyodor () insecure org> wrote:
On Sun, Dec 21, 2008 at 11:36:23PM -0700, Patrick Donnelly wrote:When speaking to Ron and Brandon about some of the problems debugging their scripts, I had thought it would be useful to have some form of interactive debugger they could use at arbitrary moments during a Script Scan to inspect script threads. In particular, they would like to see all the threads waiting/running and inspect the stacks of the threads. I expect it would be as simple as adding an extra character command (like 'v' increases the verbosity) that signals to NSE the debugger should run. I don't think this is possible right now with (the basic) Lua debugger debug.debug [1] because Nmap takes control of the tty. There would need to be some changes (while maintaining compatibility) to nmap_tty.cc module to make this possible. Does this sound like a good idea?Hi Patrick. I've also been frustrated by having little insight into NSE's operations. Part of the fix may be this item in nmap-dev/TODO: o With sufficient debug level, NSE should show all the script instances being run. It should also say when a script starts and when it completes. [David]
This is fairly easy to do. In fact I had already made a patch (for Brandon and Ron) that does the first part. Having it print when a script finishes is about as easy. Index: nse_main.cc =================================================================== --- nse_main.cc (revision 11421) +++ nse_main.cc (working copy) @@ -391,6 +391,22 @@ std::list<struct thread_record>::iterator iter; struct timeval now; + if (o.debugging >= 3) + { + log_write(LOG_STDOUT, "Running %d script threads:\n", unfinished); + for (iter = running_scripts.begin(); iter != running_scripts.end(); iter++) + { + const char *filename; + char name_ip[512]; + lua_getfield(iter->thread, 1, FILENAME); + assert((filename = lua_tostring(iter->thread, -1)) != NULL); + iter->rr.host->NameIP(name_ip, 512); + log_write(LOG_STDOUT, "Script %s thread %p against target %s.\n", + filename, (void *) iter->thread, name_ip); + lua_pop(iter->thread, 1); + } + } + // while there are scripts in running or waiting state, we loop. // we rely on nsock_loop to protect us from busy loops when // all scripts are waiting.
I have mixed feelings about enhancing runtime interaction to handle NSE debugging. On the one hand, it definitely sounds useful in many cases. On the other hand, it involves changing Nmap's TTE handling a bit and adding an NSE debugger for everyone (even the 99+% of Nmap users who are non-developers). I think it would depend on how invovled the implementation is. Diman integrated an NSE debugger into one of his nmap-exp branches a while back, which could make for a good start. I'm interested in how other people feel about including such a debugger. At the very minimum, having such a thing available for developers to install sounds like a big win. And including it in mainstream Nmap builds may be worthwhile too if it doesn't bloat the code too much or slow things down. Also, if it is activated by runtime interaction, it needs to print out an easy way to resume when it is activated. I can easily see Nmap users triggering it accidentally during their scan and then being stuck in a debugger and not knowing what to do. Maybe it should only work when the debug level is at least one (which you can of course change on the fly during run time if you didn't specify it on the command line). A simpler (but less powerful) option is to include more information in the status information printed when you press enter (or most other keys) during a scan. For example, it could print each currently running script thread, including the target/port it is running against and the amount of time it has been running for.
Right, we could print out information concerning scripts but I feel this will never really satisfy script developers. I have the idea that the majority of the debugger would simply execute input code. This provides flexibility that a developer can basically do whatever he wants while maintaining minimal complexity. A lot of the tools the developer would use to debug scripts can be moved into a debug library (probably very similar to Diman's debug library which I haven't looked at closely yet), separating it from the engine itself. The code can then be loaded on demand and used by the developer during a script scan. So, NSE would not hold the hand of the developer by making very user friendly commands but would facilitate an environment that the developer can use to inspect their code. -- -Patrick Donnelly "One of the lessons of history is that nothing is often a good thing to do and always a clever thing to say." -Will Durant _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- Nmap tty and NSE Patrick Donnelly (Dec 21)
- Re: Nmap tty and NSE Fyodor (Dec 22)
- Re: Nmap tty and NSE Patrick Donnelly (Dec 22)
- Re: Nmap tty and NSE David Fifield (Dec 22)
- Re: Nmap tty and NSE doug (Dec 22)
- Re: Nmap tty and NSE David Fifield (Dec 22)
- Re: Nmap tty and NSE Brandon Enright (Dec 22)
- Re: Nmap tty and NSE Fyodor (Dec 22)
- Re: Nmap tty and NSE doug (Dec 22)
- Re: Nmap tty and NSE Patrick Donnelly (Dec 23)
- Re: Nmap tty and NSE David Fifield (Dec 23)
- Re: Nmap tty and NSE Patrick Donnelly (Dec 24)
- Re: Nmap tty and NSE Fyodor (Dec 24)
- Re: Nmap tty and NSE Patrick Donnelly (Dec 24)
- Re: Nmap tty and NSE Fyodor (Dec 22)