mailing list archives
Re: Some scripts for analyzing NetBus
From: Toni Ruottu <toni.ruottu () iki fi>
Date: Fri, 14 Jan 2011 15:54:26 +0200
Ok. I try to find time for fixing the said things this weekend. There
are some other things that worry me a bit. Not too much but still. I
try to list them below.
While trying out netbus-info all mixer settings were always 0. I am
expecting this to follow from running NetBus under Wine. If someone
could try scanning a netbus server running on Windows, that would be
good. However, I am not sure if NetBus works on Windows Xp, Vista, or
For completeness I should say that NetBus also provides some file
system functionalities, and someone might want to write a netbus-ls
script to list the shared files. However I had some trouble getting
the file system working, possibly because I am running NetBus under
wine. Because the file system does not always work properly, and might
have lots of information it is probably not a good idea to add this
functionality into netbus-info.
Finally, I am worried that some old part of nmap might assume that
netbus can only run on Windows. Does nmap consider Wine a separate OS
or an implementation of Windows or what? Is there some os detection
flags that I should or should not set when NetBus is detected by my
On Fri, Jan 14, 2011 at 10:45 AM, Fyodor <fyodor () insecure org> wrote:
On Thu, Dec 30, 2010 at 02:37:38PM +0200, Toni Ruottu wrote:
The scripts store a password in nmap.registry.netbuspassword. This won't
work if more than host with different passwords is scanned at the same
time. You should make this indexed by IP address and port number.
Is string.format("%s:%d", host.ip, port.number) always unique and a
valid key, or is there some advanced library function for serializing
the host information? E.g. what would happen if the host was IPv6?
When you add that and the <empty> thing David mentioned, could you
also add an NSE script argument for specifying the Netbus password for
scripts like netbus-info? That way users don't need to use
netbus-brute every time. It would then need @args to be documented in
the NSEDoc section. See Patrik's informix-query (among many other
scripts which do this) for an example of passing the authentication in
a script arg. And would you add a @usage section to the scripts where
the default generated by our NSEDoc renderer "nmap -sV
--script=[scriptname] <target>" isn't ideal or informative enough?
I'm glad the new Nmap release will have some old school protocols like
Gopher and Netbus thanks to your scripts :).
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/