Nmap Windows Czar
While Windows is the second most popular platform for running
Nmap, that version is just not up-to-par with it's UNIX cousin. There
are also Windows-specific building and installation features which
could be added. This project will appoint someone as Windows Czar for
the summer. They will complete the tasks described in this document,
and possibly other Windows-related tasks that crop up. This is one of
the project options for the 2005 Google Summer of Code Program -- see
GoogleGrants.html for others.
Create a Windows installer
Currently, Nmap is only offered for Windows users in source format,
and a PKZip file of the binaries. This leaves Windows users to
manually perform a number of tasks to install Nmap properly. While
this is powerful and flexible, many users would prefer an executable
installer to do this work for them. This installer should meet the
- It should be a free, open source based system. An example would
be NSIS (formerly known as Pimp Installer) from
http://nsis.sourceforge.net/. But there may be better ones out
there. Take a look at what other major open source applications are
using, see how well they work, and decide what would best meet Nmap's
- It needs to handle checking for Winpcap and installing it if
required. You may be able to just execute the WinPcap 3.1 installer
and it might handle the checking work for you.
- It should do the Nmap performance registry changes described in
README-WIN32 (maybe query the user before doing them).
- User should be able to specify where Nmap is installed.
- Ideally the installer should be built using a hand-editable text
file, rather than something that requires a GUI to change or recreate.
- When new versions of Nmap are released, it needs to be easy for
Fyodor to build an accompanying new installer. He should only need to
do something simple, like run a makeInstaller script from the build
Automated Build System
Create an automated build system for building distributable
binaries and an executable installer for the Windows version of Nmap.
Right now, for every new version of Nmap, Fyodor has to manually open
Visual Studio, perform the compilation tasks described in
http://nmap.org/data/README-WIN32 , then open up a Cygwin
shell and manually create a zip archive containing all of the
appropriate files. And of course no self-installer exists at all yet.
This should be automated so that Fyodor only has to run one command
(preferably from the command-line) to perform these steps. Requiring
Cygwin is OK. Compilation should still be done with Visual C++,
unless you can demonstrat the g++ (or whatever) creates Nmap binaries
that are just as good or better on Windows. Compilation from within
Visual C++ using the "build" command should still work fine.
Changes to compilation rules (such as adding a souce file or library)
should only need to be made in one place (e.g. from the Visual Studio
GUI or in a text/make file.) Not both. The results should be a
convenient packaged nmap-VERSION-win32.zip and nmap-VERSION-setup.exe,
ready for distribution.
In addition to the build system and installer, there are a number
of ways that the Nmap Windows code could be improved to better compete
with the UNIX version. Here are some ideas:
- Make localhost raw scanning work on Windows, if possible. At a
very minimum, insure that users get an appropriate error message if
they do this.
- Reliability tests -- try some large-scale network scans and watch
for crashes or other bugs. Track them down and fix 'em. Try running
it under an automated bug finder, such as Insure++, Purify, and/or
Valgrind then fixing any real bugs discovered.
- Performance testing -- large-scale scanning may also help in
performance benchmarking. Try changing compilation flags and source
code changes to speed it up. Maybe run it under a profiler.
- Performance: Windows TCP connect() scan may be limiting itself to
too few sockets, because it looks like max_sd() always returns zero
for Windows. Investigate. Maybe should be limited it to 9 due to
the new SP2 limitations.
- Fix Windows-related bugs reported by Nmap users during the period.
- Fix problem that causes Nmap to quit on Windows platforms when one
of the targets is a broadcast or network address. Nmap should act
like it does on UNIX, which generally treats a broadcast address no
differently than any other. If Windows absolutely refuses to let you
send packets to such an address, the host should be skipped rather
than Nmap crashing. But you probably just need to set an appropriate
socket flag (like SO_BROADCAST on UNIX). For an example, try scanning
192.168.0.0 on a 192.168/16 net.
- Separate nbase into its own library on Windows and UNIX.
- Clean up winclude.h and mswin32/winclude.h. It probably shouldn't
be doing ugly stuff like #defining read(). We'll have to talk about
what to do here.