Ncat/Nping Google SOC project

These were the ORIGINAL SPECIFICATIONS for developing these two programs. The applications themselves can now be found at http://nmap.org/ncat/ and http://nmap.org/nping/

The goal for this project is to create an updated, portable, and maintainable version of Netcat which supports all of the Netcat 1.10 features except for port scanning (there is another tool I prefer for that particular task ;). In addition, Ncat will support IPv6, SSL, connection tunneling, and other nifty features described in the feature list and infrastructure requirements below.

And while we're updating and re-implementing well-loved tools, we might as well create Nping, which is similar to hping2 with the sort of extra features that Nmap users will love.

This is a challenging project, so we are fortunate enough to have received applications from many highly talented individuals! Do read this over and be certain you are up to the task before taking it on, as we are excited to see the results, but can only assigning one student to the task. The features and infrastructure requirements for the Ncat/Nping project are listed below.

If you guys think of other important features/requirements for this document, of feel it should be changed in other ways, let me know. Labels such as "should" or "would be nice" denote optional features, while "musts" have to be met. Here are the proposed features and infrastructure requirements for the new Nmap GUI and results viewer:

Note that even the "required" features are negotiable. For example, just let me know if you have no access to an OS X box to test on.

To avoid confusion, and allow people to have both on their systems, and out of respect for the original authors, these tools will not use the names 'nc' or 'hping2'. An admin can always create symlinks if she wants them.

REQUIRED FEATURES (both NCAT & NPING)

Must support IPv6
Small, stable, secure, resource-efficient, well-written.
Must be fully documented in a man page and HTML. One good option is to write the docs in Docbook XML and then use automated conversion to get man page (nroff) and HTML. Or you could write the nroff directly and convert to HTML. Or write separate HTML and man pages. HTML generated from a non-text source (Word, Dreamweaver, Frongpage, etc.) is unacceptable unless you have a rare tool that produces readable and concise HTML.
Command line interface. I'm not convinced that a GUI is necessary, but you can always write one if you want.
Verbose/Debugging levels.
Lern from other Netcat reimplimentations, such as Socat, Cryptcat, OpenBSD nc, Netcat6, and so-called GNU Netcat (any others?)

REQUIRED FEATURES (NCAT)

Must support all Netcat 1.10 options, except for port scanning.
Connection redirection (cause TCP connections or UDP packets and responses to be transparently proxies to a 3rd host/port. Like the TCP "redir" program).
Connection brokering. Listen for two connections (possibly on different ports), and connect the two parties together. Hmm, maybe this should even work with N parties. This is great for communication between two parties behind NAT gateways. (Idea from William Letourneau's proposal).
SSL support using OpenSSL (we'll have to decide on the best interface for this). This could be useful for both connecting to SSL servers, and encrypting/authenticating connections between Ncat instances. OpenSSL support must be optional at compile time.
Channel must support optional.authentication and encryption, maybe through the OpenSSL support. Needs to be simple but secure -- we're not talking about reimplementing OpenSSH here. Should be as simple to use as specifying a password -- user should not have to manually generate SSL keys on both sides or anything.
Inetd-like Ability to spawn multiple concurrent applications (such as shells), one for each incoming connection.
Ability to limit incoming connections to only those from a given list of netblocks (which may be as simple as a single IP).
Simple HTTP and/or SOCKS proxy client and server support.

REQUIRED FEATURES (NPING)

Must support all hping2 features, though we may juggle around the option flags. Some flags may use the Nmap-style option name rather than hping-style.
TCP connect() and UDP pings (for non-root users)
ARP ping. (The next Nmap will support ARP/ethernet via libdnet).
MAC address spoofing on ethernet networks.

INFRASTRUCTURE REQUIREMENTS (both)

Must be written in C or C++ (no exceptions).

Must support and be tested under Linux, Windows, and one of the following: Mac OS X, Free-, Net-, or Open-BSD, and Solaris. There should be no barrier towards supporting most of the other systems, though no need to test on all of those initially. That is what users are for :).

Must be able to compile Ncat as a single, statically-linked executable on all platforms.

Must use the Nmap infrastructure libraries, such as nsock and nbase. Nping should use libdnet.

Must limit the number of external libraries/programs it depends on. Anything that ships with Nmap is OK. Check with Fyodor before adding other dependencies.

Development must be done in the open, hosted on a project server such as Sourceforge. Test versions and such should be sent to the nmap-dev list (just send links, not the binaries themselves). That is a good list for bouncing ideas around too.

Should initially be designed to be integrated into Nmap tarball, though with an eye toward making separation easy in the future.