Re: Nmap tty and NSE

[Fyodor <fyodor () insecure org>]

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]

While the idea has David's name on it, anyone else is welcome to take
a crack at it if they have ideas and find time.  David is very busy on
port scan performance work right now.

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.

Cheers,
-F

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