nc源码（含unix、windows版本）

WINDOWS VERSION README NetCat v1.11 , New fixed version Summary Netcat for Windows 1.1 has a buffer overflow vulnerability that allows remote execution of code. It is exposed when netcat is run using the -e option which execs a process and pipes the listening socket io to the stdio of the exec'd process. Note that this issue does not exist in netcat for the unix platform.Thanx to @stake and Chris Wysopal wich finally react due to the critical hole that Hat-Squad found yesterday into Netcat v1.10. Related - http://vulnwatch.org/netcat http://www.hat-squad.com/weblog/archives/000143.html More @ source UNIX VERSION README Netcat 1.10 Netcat is a simple Unix utility which reads and writes data across network connections, using TCP or UDP protocol. It is designed to be a reliable "back-end" tool that can be used directly or easily driven by other programs and scripts. At the same time, it is a feature-rich network debugging and exploration tool, since it can create almost any kind of connection you would need and has several interesting built-in capabilities. Netcat, or "nc" as the actual program is named, should have been supplied long ago as another one of those cryptic but standard Unix tools. In the simplest usage, "nc host port" creates a TCP connection to the given port on the given target host. Your standard input is then sent to the host, and anything that comes back across the connection is sent to your standard output. This continues indefinitely, until the network side of the connection shuts down. Note that this behavior is different from most other applications which shut everything down and exit after an end-of-file on the standard input. Netcat can also function as a server, by listening for inbound connections on arbitrary ports and then doing the same reading and writing. With minor limitations, netcat doesn't really care if it runs in "client" or "server" mode -- it still shovels data back and forth until there isn't any more left. In either mode, shutdown can be forced after a configurable time of inactivity on the network side. And it can do this via UDP too, so netcat is possibly the "udp telnet-like" application you always wanted for testing your UDP-mode servers. UDP, as the "U" implies, gives less reliable data transmission than TCP connections and some systems may have trouble sending large amounts of data that way, but it's still a useful capability to have. You may be asking "why not just use telnet to connect to arbitrary ports?" Valid question, and here are some reasons. Telnet has the "standard input EOF" problem, so one must introduce calculated delays in driving scripts to allow network output to finish. This is the main reason netcat stays running until the *network* side closes. Telnet also will not transfer arbitrary binary data, because certain characters are interpreted as telnet options and are thus removed from the data stream. Telnet also emits some of its diagnostic messages to standard output, where netcat keeps such things religiously separated from its *output* and will never modify any of the real data in transit unless you *really* want it to. And of course telnet is incapable of listening for inbound connections, or using UDP instead. Netcat doesn't have any of these limitations, is much smaller and faster than telnet, and has many other advantages. Some of netcat's major features are: Outbound or inbound connections, TCP or UDP, to or from any ports Full DNS forward/reverse checking, with appropriate warnings Ability to use any local source port Ability to use any locally-configured network source address Built-in port-scanning capabilities, with randomizer Built-in loose source-routing capability Can read command line arguments from standard input Slow-send mode, one line every N seconds Hex dump of transmitted and received data Optional ability to let another program service established connections Optional telnet-options responder Efforts have been made to have netcat "do the right thing" in all its various modes. If you believe that it is doing the wrong thing under whatever circumstances, please notify me and tell me how you think it should behave. If netcat is not able to do some task you think up, minor tweaks to the code will probably fix that. It provides a basic and easily-modified template for writing other network applications, and I certainly encourage people to make custom mods and send in any improvements they make to it. This is the second release; the overall differences from 1.00 are relatively minor and have mostly to do with portability and bugfixes. Many people provided greatly appreciated fixes and comments on the 1.00 release. Continued feedback from the Internet community is always welcome! Netcat is entirely my own creation, although plenty of other code was used as examples. It is freely given away to the Internet community in the hope that it will be useful, with no restrictions except giving credit where it is due. No GPLs, Berkeley copyrights or any of that nonsense. The author assumes NO responsibility for how anyone uses it. If netcat makes you rich somehow and you're feeling generous, mail me a check. If you are affiliated in any way with Microsoft Network, get a life. Always ski in control. Comments, questions, and patches to hobbit@avian.org. Building Compiling is fairly straightforward. Examine the Makefile for a SYSTYPE that matches yours, and do "make ". The executable "nc" should appear. If there is no relevant SYSTYPE section, try "generic". If you create new sections for generic.h and Makefile to support another platform, please follow the given format and mail back the diffs. There are a couple of other settable #defines in netcat.c, which you can include as DFLAGS="-DTHIS -DTHAT" to your "make" invocation without having to edit the Makefile. See the following discussions for what they are and do. If you want to link against the resolver library on SunOS [recommended] and you have BIND 4.9.x, you may need to change XLIBS=-lresolv in the Makefile to XLIBS="-lresolv -l44bsd". Linux sys/time.h does not really support presetting of FD_SETSIZE; a harmless warning is issued. Some systems may warn about pointer types for signal(). No problem, though. Exploration of features Where to begin? Netcat is at the same time so simple and versatile, it's like trying to describe everything you can do with your Swiss Army knife. This will go over the basics; you should also read the usage examples and notes later on which may give you even more ideas about what this sort of tool is good for. If no command arguments are given at all, netcat asks for them, reads a line from standard input, and breaks it up into arguments internally. This can be useful when driving netcat from certain types of scripts, with the side effect of hiding your command line arguments from "ps" displays. The host argument can be a name or IP address. If -n is specified, netcat will only accept numeric IP addresses and do no DNS lookups for anything. If -n is not given and -v is turned on, netcat will do a full forward and reverse name and address lookup for the host, and warn you about the all-too-common problem of mismatched names in the DNS. This often takes a little longer for connection setup, but is useful to know about. There are circumstances under which this can *save* time, such as when you want to know the name for some IP address and also connect there. Netcat will just tell you all about it, saving the manual steps of looking up the hostname yourself. Normally mismatch- checking is case-insensitive per the DNS spec, but you can define ANAL at compile time to make it case-sensitive -- sometimes useful for uncovering minor errors in your own DNS files while poking around your networks. A port argument is required for outbound connections, and can be numeric or a name as listed in /etc/se