Home page logo
/

NSE Libraries

In addition to the significant built-in capabilities of Lua, we have written or integrated many extension libraries which make script writing more powerful and convenient. These libraries (sometimes called modules) are compiled if necessary and installed along with Nmap. They have their own directory, nselib, which is installed in the configured Nmap data directory. Scripts need only require the default libraries in order to use them.

List of All Libraries

This list is just an overview to give an idea of what libraries are available. Developers will want to consult the complete documentation at http://nmap.org/nsedoc/.

afp

This module was written by Patrik Karlsson and facilitates communication with the Apple AFP Service. It is not feature complete and is missing several functions and parameters.

backdoor

This config file is designed for adding a backdoor to the system. It has a few options by default, only one enabled by default. I suggest

base64

Base64 encoding and decoding. Follows RFC 4648.

bin

Pack and unpack binary data.

bit

Bitwise operations on integers.

citrix

This module was written by Patrik Karlsson and facilitates communication with the Citrix XML Service. It is not feature complete and is missing several functions and parameters.

comm

Common communication functions for network discovery tasks like banner grabbing and data exchange.

datafiles

Read and parse some of Nmap's data files: nmap-protocols, nmap-rpc, and nmap-services.

default

More verbose network scripts

dns

Simple DNS library supporting packet creation, encoding, decoding, and querying.

drive

This configuration file pulls info about a given harddrive

experimental

This is the configuration file for modules that aren't quite ready for prime time yet.

http

Client-side HTTP library.

imap

IMAP functions.

ipOps

Utility functions for manipulating and comparing IP addresses.

listop

Functional-style list operations.

match

Buffered network I/O helper functions.

mongodb

Library methods for handling MongoDB, creating and parsing packets

msrpc

By making heavy use of the 'smb' library, this library will call various MSRPC functions. The functions used here can be accessed over TCP ports 445 and 139, with an established session. A NULL session (the default) will work for some functions and operating systems (or configurations), but not for others.

msrpcperformance

This module is designed to parse the PERF_DATA_BLOCK structure, which is stored in the registry under HKEY_PERFORMANCE_DATA. By querying this structure, you can get a whole lot of information about what's going on.

msrpctypes

This module was written to marshall parameters for Microsoft RPC (MSRPC) calls. The values passed in and out are based on structs defined by the protocol, and documented by Samba developers. For detailed breakdowns of the types, take a look at Samba 4.0's .idl files.

mysql

Simple MySQL Library supporting a very limited subset of operations

netbios

Creates and parses NetBIOS traffic. The primary use for this is to send NetBIOS name requests.

network

This is the default configuration file. It simply runs some built-in Window programs to gather information about the remote system. It's intended to be simple, demonstrate some of the concepts, and not break/alte anything.

nmap

Interface with Nmap internals.

nsedebug

Converts an arbitrary data type into a string. Will recursively convert tables. This can be very useful for debugging.

openssl

OpenSSL bindings.

packet

Facilities for manipulating raw packets.

pcre

Perl Compatible Regular Expressions.

pop3

POP3 functions.

proxy

Functions for proxy testing

pwdump

This config file is designed for running password-dumping scripts. So far, it supports pwdump6 2.0.0 and fgdump.

shortport

Functions for building short portrules.

smb

Implements functionality related to Server Message Block (SMB, also known as CIFS) traffic, which is a Windows protocol.

smbauth

This module takes care of the authentication used in SMB (LM, NTLM, LMv2, NTLMv2). There is a lot to this functionality, so if you're interested in how it works, read on.

snmp

SNMP functions.

ssh1

Functions for the SSH-1 protocol.

ssh2

Functions for the SSH-2 protocol.

stdnse

Standard Nmap Scripting Engine functions.

strbuf

String buffer facilities.

strict

Strict Declared Global library.

tab

Arrange output into tables.

unpwdb

Username/password database library.

url

URI parsing, composition, and relative URL resolution.

Hacking NSE Libraries

Libraries often accidentally make use of globals variables when local scope was intended. Two or more scripts that make use of library functions which unintentionally use the same global variable will find that variable constantly rewritten. This is a serious bug that can cause NSE to stall or a correct script to spectacularly fail, and, because Lua uses global-by-default scope assignment when it encounters a variable, this is also a common bug.

Consider a global variable being used by two different scripts, within the library, to hold sockets or data. When one script is yielded after storing data in the variable, another script awakens only to replace that data. In contrast, a local variable would store the information on the stack of the running script separate from others.

To help correct this problem, NSE now uses an adapted library from the standard Lua distribution called strict.lua. The library will raise a runtime error on any access or modification of a global variable which was undeclared in the file scope. A global variable is considered declared if the library makes an assignment to the global name (even nil) in the file scope.

Adding C Modules to Nselib

A few of the modules included in nselib are written in C or C++ rather than Lua. Two examples are bit and pcre. We recommend that modules be written in Lua if possible, but C and C++ may be more appropriate if performance is critical or (as with the pcre and openssl modules) you are linking to an existing C library. This section describes how to write your own compiled extensions to nselib.

The Lua C API is described at length in Programming in Lua, Second Edition, so this is a short summary. C modules consist of functions that follow the protocol of the lua_CFunction type. The functions are registered with Lua and assembled into a library by calling the luaL_register function. A special initialization function provides the interface between the module and the rest of the NSE code. By convention the initialization function is named in the form luaopen_<module>.

The smallest compiled module that comes with NSE is bit, and one of the most straightforward is openssl. These modules serve as good examples for a beginning module writer. The source code for bit is found in nse_bit.cc and nse_bit.h, while the openssl source is in nse_openssl.cc and nse_openssl.h. Most of the other compiled modules follow this nse_<module name>.cc naming convention.

Reviewing the openssl module shows that one of the functions in nse_openssl.cc is l_md5, which calculates an MD5 digest. Its function prototype is:

static int l_md5(lua_State *L);

The prototype shows that l_md5 matches the lua_CFunction type. The function is static because it does not have to be visible to other compiled code. Only an address is required to register it with Lua. Later in the file, l_md5 is entered into an array of type luaL_reg and associated with the name md5:

static const struct luaL_reg openssllib[] = {
  { "md5", l_md5 },
  { NULL, NULL }
};

This function will now be known as md5 to NSE. Next the library is registered with a call to luaL_register inside the initialization function luaopen_openssl, as shown next. Some lines relating to the registration of OpenSSL BIGNUM types have been omitted:

LUALIB_API int luaopen_openssl(lua_State *L) {
  luaL_register(L, OPENSSLLIBNAME, openssllib);
  return 1;
}

The function luaopen_openssl is the only function in the file that is exposed in nse_openssl.h. OPENSSLLIBNAME is simply the string "openssl".

After a compiled module is written, it must be added to NSE by including it in the list of standard libraries in nse_init.cc. Then the module's source file names must be added to Makefile.in in the appropriate places. For both these tasks you can simply follow the example of the other C modules. For the Windows build, the new source files must be added to the mswin32/nmap.vcproj project file using MS Visual Studio (see the section called “Compile from Source Code”).

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]