remove old cruft

2 files changed, 0 insertions, 1007 deletions

diff --git a/usr.bin/nc/README b/usr.bin/nc/README
deleted file mode 100644
index 4235bc41acf..00000000000
--- a/usr.bin/nc/README
+++ /dev/null
@@ -1,946 +0,0 @@
-Netcat 1.10
-===========							   /\_/\
-								  / 0 0 \
-Netcat is a simple Unix utility which reads and writes data	 ====v====
-across network connections, using TCP or UDP protocol.		  \  W  /
-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	 \__.=|___E
-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 <systype>".  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/services.  If -n is specified, only numeric arguments
-are valid.  Special syntax and/or more than one port argument cause different
-behavior -- see details below about port-scanning.
-
-The -v switch controls the verbosity level of messages sent to standard error.
-You will probably want to run netcat most of the time with -v turned on, so you
-can see info about the connections it is trying to make.  You will probably
-also want to give a smallish -w argument, which limits the time spent trying to
-make a connection.  I usually alias "nc" to "nc -v -w 3", which makes it
-function just about the same for things I would otherwise use telnet to do.
-The timeout is easily changed by a subsequent -w argument which overrides the
-earlier one.  Specifying -v more than once makes diagnostic output MORE
-verbose.  If -v is not specified at all, netcat silently does its work unless
-some error happens, whereupon it describes the error and exits with a nonzero
-status.  Refused network connections are generally NOT considered to be errors,
-unless you only asked for a single TCP port and it was refused.
-
-Note that -w also sets the network inactivity timeout.  This does not have any
-effect until standard input closes, but then if nothing further arrives from
-the network in the next <timeout> seconds, netcat tries to read the net once
-more for good measure, and then closes and exits.  There are a lot of network
-services now that accept a small amount of input and return a large amount of
-output, such as Gopher and Web servers, which is the main reason netcat was
-written to "block" on the network staying open rather than standard input.
-Handling the timeout this way gives uniform behavior with network servers that
-*don't* close by themselves until told to.
-
-UDP connections are opened instead of TCP when -u is specified.  These aren't
-really "connections" per se since UDP is a connectionless protocol, although
-netcat does internally use the "connected UDP socket" mechanism that most
-kernels support.  Although netcat claims that an outgoing UDP connection is
-"open" immediately, no data is sent until something is read from standard
-input.  Only thereafter is it possible to determine whether there really is a
-UDP server on the other end, and often you just can't tell.  Most UDP protocols
-use timeouts and retries to do their thing and in many cases won't bother
-answering at all, so you should specify a timeout and hope for the best.  You
-will get more out of UDP connections if standard input is fed from a source
-of data that looks like various kinds of server requests.
-
-To obtain a hex dump file of the data sent either way, use "-o logfile".  The
-dump lines begin with "<" or ">" to respectively indicate "from the net" or
-"to the net", and contain the total count per direction, and hex and ascii
-representations of the traffic.  Capturing a hex dump naturally slows netcat
-down a bit, so don't use it where speed is critical.
-
-Netcat can bind to any local port, subject to privilege restrictions and ports
-that are already in use.  It is also possible to use a specific local network
-source address if it is that of a network interface on your machine.  [Note:
-this does not work correctly on all platforms.]  Use "-p portarg" to grab a
-specific local port, and "-s ip-addr" or "-s name" to have that be your source
-IP address.  This is often referred to as "anchoring the socket".  Root users
-can grab any unused source port including the "reserved" ones less than 1024.
-Absence of -p will bind to whatever unused port the system gives you, just like
-any other normal client connection, unless you use -r [see below].
-
-Listen mode will cause netcat to wait for an inbound connection, and then the
-same data transfer happens.  Thus, you can do "nc -l -p 1234 < filename" and
-when someone else connects to your port 1234, the file is sent to them whether
-they wanted it or not.  Listen mode is generally used along with a local port
-argument -- this is required for UDP mode, while TCP mode can have the system
-assign one and tell you what it is if -v is turned on.  If you specify a target
-host and optional port in listen mode, netcat will accept an inbound connection
-only from that host and if you specify one, only from that foreign source port.
-In verbose mode you'll be informed about the inbound connection, including what
-address and port it came from, and since listening on "any" applies to several
-possibilities, which address it came *to* on your end.  If the system supports
-IP socket options, netcat will attempt to retrieve any such options from an
-inbound connection and print them out in hex.
-
-If netcat is compiled with -DGAPING_SECURITY_HOLE, the -e argument specifies
-a program to exec after making or receiving a successful connection.  In the
-listening mode, this works similarly to "inetd" but only for a single instance.
-Use with GREAT CARE.  This piece of the code is normally not enabled; if you
-know what you're doing, have fun.  This hack also works in UDP mode.  Note that
-you can only supply -e with the name of the program, but no arguments.  If you
-want to launch something with an argument list, write a two-line wrapper script
-or just use inetd like always.
-
-If netcat is compiled with -DTELNET, the -t argument enables it to respond
-to telnet option negotiation [always in the negative, i.e. DONT or WONT].
-This allows it to connect to a telnetd and get past the initial negotiation
-far enough to get a login prompt from the server.  Since this feature has
-the potential to modify the data stream, it is not enabled by default.  You
-have to understand why you might need this and turn on the #define yourself.
-
-Data from the network connection is always delivered to standard output as
-efficiently as possible, using large 8K reads and writes.  Standard input is
-normally sent to the net the same way, but the -i switch specifies an "interval
-time" which slows this down considerably.  Standard input is still read in
-large batches, but netcat then tries to find where line breaks exist and sends
-one line every interval time.  Note that if standard input is a terminal, data
-is already read line by line, so unless you make the -i interval rather long,
-what you type will go out at a fairly normal rate.  -i is really designed
-for use when you want to "measure out" what is read from files or pipes.
-
-Port-scanning is a popular method for exploring what's out there.  Netcat
-accepts its commands with options first, then the target host, and everything
-thereafter is interpreted as port names or numbers, or ranges of ports in M-N
-syntax.  CAVEAT: some port names in /etc/services contain hyphens -- netcat
-currently will not correctly parse those, so specify ranges using numbers if
-you can.  If more than one port is thus specified, netcat connects to *all* of
-them, sending the same batch of data from standard input [up to 8K worth] to
-each one that is successfully connected to.  Specifying multiple ports also
-suppresses diagnostic messages about refused connections, unless -v is
-specified twice for "more verbosity".  This way you normally get notified only
-about genuinely open connections.  Example: "nc -v -w 2 -z target 20-30" will
-try connecting to every port between 20 and 30 [inclusive] at the target, and
-will likely inform you about an FTP server, telnet server, and mailer along the
-way.  The -z switch prevents sending any data to a TCP connection and very
-limited probe data to a UDP connection, and is thus useful as a fast scanning
-mode just to see what ports the target is listening on.  To limit scanning
-speed if desired, -i will insert a delay between each port probe.  There are
-some pitfalls with regard to UDP scanning, described later, but in general it
-works well.
-
-For each range of ports specified, scanning is normally done downward within
-that range.  If the -r switch is used, scanning hops randomly around within
-that range and reports open ports as it finds them.  [If you want them listed
-in order regardless, pipe standard error through "sort"...]  In addition, if
-random mode is in effect, the local source ports are also randomized.  This
-prevents netcat from exhibiting any kind of regular pattern in its scanning.
-You can exert fairly fine control over your scan by judicious use of -r and
-selected port ranges to cover.  If you use -r for a single connection, the
-source port will have a random value above 8192, rather than the next one the
-kernel would have assigned you.  Note that selecting a specific local port
-with -p overrides any local-port randomization.
-
-Many people are interested in testing network connectivity using IP source
-routing, even if it's only to make sure their own firewalls are blocking
-source-routed packets.  On systems that support it, the -g switch can be used
-multiple times [up to 8] to construct a loose-source-routed path for your
-connection, and the -G argument positions the "hop pointer" within the list.
-If your network allows source-routed traffic in and out, you can test
-connectivity to your own services via remote points in the internet.  Note that
-although newer BSD-flavor telnets also have source-routing capability, it isn't
-clearly documented and the command syntax is somewhat clumsy.  Netcat's
-handling of "-g" is modeled after "traceroute".
-
-Netcat tries its best to behave just like "cat".  It currently does nothing to
-terminal input modes, and does no end-of-line conversion.  Standard input from
-a terminal is read line by line with normal editing characters in effect.  You
-can freely suspend out of an interactive connection and resume.  ^C or whatever
-your interrupt character is will make netcat close the network connection and
-exit.  A switch to place the terminal in raw mode has been considered, but so
-far has not been necessary.  You can send raw binary data by reading it out of
-a file or piping from another program, so more meaningful effort would be spent
-writing an appropriate front-end driver.
-
-Netcat is not an "arbitrary packet generator", but the ability to talk to raw
-sockets and/or nit/bpf/dlpi may appear at some point.  Such things are clearly
-useful; I refer you to Darren Reed's excellent ip_filter package, which now
-includes a tool to construct and send raw packets with any contents you want.
-
-Example uses -- the light side
-==============================
-
-Again, this is a very partial list of possibilities, but it may get you to
-think up more applications for netcat.  Driving netcat with simple shell or
-expect scripts is an easy and flexible way to do fairly complex tasks,
-especially if you're not into coding network tools in C.  My coding isn't
-particularly strong either [although undoubtedly better after writing this
-thing!], so I tend to construct bare-metal tools like this that I can trivially
-plug into other applications.  Netcat doubles as a teaching tool -- one can
-learn a great deal about more complex network protocols by trying to simulate
-them through raw connections!
-
-An example of netcat as a backend for something else is the shell-script
-Web browser, which simply asks for the relevant parts of a URL and pipes
-"GET /what/ever" into a netcat connection to the server.  I used to do this
-with telnet, and had to use calculated sleep times and other stupidity to
-kludge around telnet's limitations.  Netcat guarantees that I get the whole
-page, and since it transfers all the data unmodified, I can even pull down
-binary image files and display them elsewhere later.  Some folks may find the
-idea of a shell-script web browser silly and strange, but it starts up and
-gets me my info a hell of a lot faster than a GUI browser and doesn't hide
-any contents of links and forms and such.  This is included, as scripts/web,
-along with several other web-related examples.
-
-Netcat is an obvious replacement for telnet as a tool for talking to daemons.
-For example, it is easier to type "nc host 25", talk to someone's mailer, and
-just ^C out than having to type ^]c or QUIT as telnet would require you to do.
-You can quickly catalog the services on your network by telling netcat to
-connect to well-known services and collect greetings, or at least scan for open
-ports.  You'll probably want to collect netcat's diagnostic messages in your
-output files, so be sure to include standard error in the output using
-`>& file' in *csh or `> file 2>&1' in bourne shell.
-
-A scanning example: "echo QUIT | nc -v -w 5 target 20-250 500-600 5990-7000"
-will inform you about a target's various well-known TCP servers, including
-r-services, X, IRC, and maybe a few you didn't expect.  Sending in QUIT and
-using the timeout will almost guarantee that you see some kind of greeting or
-error from each service, which usually indicates what it is and what version.
-[Beware of the "chargen" port, though...]  SATAN uses exactly this technique to
-collect host information, and indeed some of the ideas herein were taken from
-the SATAN backend tools.  If you script this up to try every host in your
-subnet space and just let it run, you will not only see all the services,
-you'll find out about hosts that aren't correctly listed in your DNS.  Then you
-can compare new snapshots against old snapshots to see changes.  For going
-after particular services, a more intrusive example is in scripts/probe.
-
-Netcat can be used as a simple data transfer agent, and it doesn't really
-matter which end is the listener and which end is the client -- input at one
-side arrives at the other side as output.  It is helpful to start the listener
-at the receiving side with no timeout specified, and then give the sending side
-a small timeout.  That way the listener stays listening until you contact it,
-and after data stops flowing the client will time out, shut down, and take the
-listener with it.  Unless the intervening network is fraught with problems,
-this should be completely reliable, and you can always increase the timeout.  A
-typical example of something "rsh" is often used for: on one side,
-
-	nc -l -p 1234 | uncompress -c | tar xvfp -
-
-and then on the other side
-
-	tar cfp - /some/dir | compress -c | nc -w 3 othermachine 1234
-
-will transfer the contents of a directory from one machine to another, without
-having to worry about .rhosts files, user accounts, or inetd configurations
-at either end.  Again, it matters not which is the listener or receiver; the
-"tarring" machine could just as easily be running the listener instead.  One
-could conceivably use a scheme like this for backups, by having cron-jobs fire
-up listeners and backup handlers [which can be restricted to specific addresses
-and ports between each other] and pipe "dump" or "tar" on one machine to "dd
-of=/dev/tapedrive" on another as usual.  Since netcat returns a nonzero exit
-status for a denied listener connection, scripts to handle such tasks could
-easily log and reject connect attempts from third parties, and then retry.
-
-Another simple data-transfer example: shipping things to a PC that doesn't have
-any network applications yet except a TCP stack and a web browser.  Point the
-browser at an arbitrary port on a Unix server by telling it to download
-something like http://unixbox:4444/foo, and have a listener on the Unix side
-ready to ship out a file when the connect comes in.  The browser may pervert
-binary data when told to save the URL, but you can dig the raw data out of
-the on-disk cache.
-
-If you build netcat with GAPING_SECURITY_HOLE defined, you can use it as an
-"inetd" substitute to test experimental network servers that would otherwise
-run under "inetd".  A script or program will have its input and output hooked
-to the network the same way, perhaps sans some fancier signal handling.  Given
-that most network services do not bind to a particular local address, whether
-they are under "inetd" or not, it is possible for netcat avoid the "address
-already in use" error by binding to a specific address.  This lets you [as
-root, for low ports] place netcat "in the way" of a standard service, since
-inbound connections are generally sent to such specifically-bound listeners
-first and fall back to the ones bound to "any".  This allows for a one-off
-experimental simulation of some service, without having to screw around with
-inetd.conf.  Running with -v turned on and collecting a connection log from
-standard error is recommended.
-
-Netcat as well can make an outbound connection and then run a program or script
-on the originating end, with input and output connected to the same network
-port.  This "inverse inetd" capability could enhance the backup-server concept
-described above or help facilitate things such as a "network dialback" concept.
-The possibilities are many and varied here; if such things are intended as
-security mechanisms, it may be best to modify netcat specifically for the
-purpose instead of wrapping such functions in scripts.
-
-Speaking of inetd, netcat will function perfectly well *under* inetd as a TCP
-connection redirector for inbound services, like a "plug-gw" without the
-authentication step.  This is very useful for doing stuff like redirecting
-traffic through your firewall out to other places like web servers and mail
-hubs, while posing no risk to the firewall machine itself.  Put netcat behind
-inetd and tcp_wrappers, perhaps thusly:
-
-	www stream tcp nowait nobody /etc/tcpd /bin/nc -w 3 realwww 80
-
-and you have a simple and effective "application relay" with access control
-and logging.  Note use of the wait time as a "safety" in case realwww isn't
-reachable or the calling user aborts the connection -- otherwise the relay may
-hang there forever.
-
-You can use netcat to generate huge amounts of useless network data for
-various performance testing.  For example, doing
-
-	yes AAAAAAAAAAAAAAAAAAAAAA | nc -v -v -l -p 2222 > /dev/null
-
-on one side and then hitting it with
-
-	yes BBBBBBBBBBBBBBBBBBBBBB | nc othermachine 2222 > /dev/null
-
-from another host will saturate your wires with A's and B's.  The "very
-verbose" switch usage will tell you how many of each were sent and received
-after you interrupt either side.  Using UDP mode produces tremendously MORE
-trash per unit time in the form of fragmented 8 Kbyte mobygrams -- enough to
-stress-test kernels and network interfaces.  Firing random binary data into
-various network servers may help expose bugs in their input handling, which
-nowadays is a popular thing to explore.  A simple example data-generator is
-given in data/data.c included in this package, along with a small collection
-of canned input files to generate various packet contents.  This program is
-documented in its beginning comments, but of interest here is using "%r" to
-generate random bytes at well-chosen points in a data stream.  If you can
-crash your daemon, you likely have a security problem.
-
-The hex dump feature may be useful for debugging odd network protocols,
-especially if you don't have any network monitoring equipment handy or aren't
-root where you'd need to run "tcpdump" or something.  Bind a listening netcat
-to a local port, and have it run a script which in turn runs another netcat
-to the real service and captures the hex dump to a log file.  This sets up a
-transparent relay between your local port and wherever the real service is.
-Be sure that the script-run netcat does *not* use -v, or the extra info it
-sends to standard error may confuse the protocol.  Note also that you cannot
-have the "listen/exec" netcat do the data capture, since once the connection
-arrives it is no longer netcat that is running.
-
-Binding to an arbitrary local port allows you to simulate things like r-service
-clients, if you are root locally.  For example, feeding "^@root^@joe^@pwd^@"
-[where ^@ is a null, and root/joe could be any other local/remote username
-pair] into a "rsh" or "rlogin" server, FROM your port 1023 for example,
-duplicates what the server expects to receive.  Thus, you can test for insecure
-.rhosts files around your network without having to create new user accounts on
-your client machine.  The program data/rservice.c can aid this process by
-constructing the "rcmd" protocol bytes.  Doing this also prevents "rshd" from
-trying to create that separate standard-error socket and still gives you an
-input path, as opposed to the usual action of "rsh -n".  Using netcat for
-things like this can be really useful sometimes, because rsh and rlogin
-generally want a host *name* as an argument and won't accept IP addresses.  If
-your client-end DNS is hosed, as may be true when you're trying to extract
-backup sets on to a dumb client, "netcat -n" wins where normal rsh/rlogin is
-useless.
-
-If you are unsure that a remote syslogger is working, test it with netcat.
-Make a UDP connection to port 514 and type in "<0>message", which should
-correspond to "kern.emerg" and cause syslogd to scream into every file it has
-open [and possibly all over users' terminals].  You can tame this down by
-using a different number and use netcat inside routine scripts to send syslog
-messages to places that aren't configured in syslog.conf.  For example,
-"echo '<38>message' | nc -w 1 -u loggerhost 514" should send to auth.notice
-on loggerhost.  The exact number may vary; check against your syslog.h first.
-
-Netcat provides several ways for you to test your own packet filters.  If you
-bind to a port normally protected against outside access and make a connection
-to somewhere outside your own network, the return traffic will be coming to
-your chosen port from the "outside" and should be blocked.  TCP may get through
-if your filter passes all "ack syn", but it shouldn't be even doing that to low
-ports on your network.  Remember to test with UDP traffic as well!  If your
-filter passes at least outbound source-routed IP packets, bouncing a connection
-back to yourself via some gateway outside your network will create "incoming"
-traffic with your source address, which should get dropped by a correctly
-configured anti-spoofing filter.  This is a "non-test" if you're also dropping
-source-routing, but it's good to be able to test for that too.  Any packet
-filter worth its salt will be blocking source-routed packets in both
-directions, but you never know what interesting quirks you might turn up by
-playing around with source ports and addresses and watching the wires with a
-network monitor.
-
-You can use netcat to protect your own workstation's X server against outside
-access.  X is stupid enough to listen for connections on "any" and never tell
-you when new connections arrive, which is one reason it is so vulnerable.  Once
-you have all your various X windows up and running you can use netcat to bind
-just to your ethernet address and listen to port 6000.  Any new connections
-from outside the machine will hit netcat instead your X server, and you get a
-log of who's trying.  You can either tell netcat to drop the connection, or
-perhaps run another copy of itself to relay to your actual X server on
-"localhost".  This may not work for dedicated X terminals, but it may be
-possible to authorize your X terminal only for its boot server, and run a relay
-netcat over on the server that will in turn talk to your X terminal.  Since
-netcat only handles one listening connection per run, make sure that whatever
-way you rig it causes another one to run and listen on 6000 soon afterward, or
-your real X server will be reachable once again.  A very minimal script just
-to protect yourself could be
-
-	while true ; do
-	  nc -v -l -s <your-addr> -p 6000 localhost 2
-	done
-
-which causes netcat to accept and then close any inbound connection to your
-workstation's normal ethernet address, and another copy is immediately run by
-the script.  Send standard error to a file for a log of connection attempts.
-If your system can't do the "specific bind" thing all is not lost; run your
-X server on display ":1" or port 6001, and netcat can still function as a probe
-alarm by listening on 6000.
-
-Does your shell-account provider allow personal Web pages, but not CGI scripts?
-You can have netcat listen on a particular port to execute a program or script
-of your choosing, and then just point to the port with a URL in your homepage.
-The listener could even exist on a completely different machine, avoiding the
-potential ire of the homepage-host administrators.  Since the script will get
-the raw browser query as input it won't look like a typical CGI script, and
-since it's running under your UID you need to write it carefully.  You may want
-to write a netcat-based script as a wrapper that reads a query and sets up
-environment variables for a regular CGI script.  The possibilities for using
-netcat and scripts to handle Web stuff are almost endless.  Again, see the
-examples under scripts/.
-
-Example uses -- the dark side
-=============================
-
-Equal time is deserved here, since a versatile tool like this can be useful
-to any Shade of Hat.  I could use my Victorinox to either fix your car or
-disassemble it, right?  You can clearly use something like netcat to attack
-or defend -- I don't try to govern anyone's social outlook, I just build tools.
-Regardless of your intentions, you should still be aware of these threats to
-your own systems.
-
-The first obvious thing is scanning someone *else's* network for vulnerable
-services.  Files containing preconstructed data, be it exploratory or
-exploitive, can be fed in as standard input, including command-line arguments
-to netcat itself to keep "ps" ignorant of your doings.  The more random the
-scanning, the less likelihood of detection by humans, scan-detectors, or
-dynamic filtering, and with -i you'll wait longer but avoid loading down the
-target's network.  Some examples for crafting various standard UDP probes are
-given in data/*.d.
-
-Some configurations of packet filters attempt to solve the FTP-data problem by
-just allowing such connections from the outside.  These come FROM port 20, TO
-high TCP ports inside -- if you locally bind to port 20, you may find yourself
-able to bypass filtering in some cases.  Maybe not to low ports "inside", but
-perhaps to TCP NFS servers, X servers, Prospero, ciscos that listen on 200x
-and 400x...  Similar bypassing may be possible for UDP [and maybe TCP too] if a
-connection comes from port 53; a filter may assume it's a nameserver response.
-
-Using -e in conjunction with binding to a specific address can enable "server
-takeover" by getting in ahead of the real ones, whereupon you can snarf data
-sent in and feed your own back out.  At the very least you can log a hex dump
-of someone else's session.  If you are root, you can certainly use -s and -e to
-run various hacked daemons without having to touch inetd.conf or the real
-daemons themselves.  You may not always have the root access to deal with low
-ports, but what if you are on a machine that also happens to be an NFS server?
-You might be able to collect some interesting things from port 2049, including
-local file handles.  There are several other servers that run on high ports
-that are likely candidates for takeover, including many of the RPC services on
-some platforms [yppasswdd, anyone?].  Kerberos tickets, X cookies, and IRC
-traffic also come to mind.  RADIUS-based terminal servers connect incoming
-users to shell-account machines on a high port, usually 1642 or thereabouts.
-SOCKS servers run on 1080.  Do "netstat -a" and get creative.
-
-There are some daemons that are well-written enough to bind separately to all
-the local interfaces, possibly with an eye toward heading off this sort of
-problem.  Named from recent BIND releases, and NTP, are two that come to mind.
-Netstat will show these listening on address.53 instead of *.53.  You won't
-be able to get in front of these on any of the real interface addresses, which
-of course is especially interesting in the case of named, but these servers
-sometimes forget about things like "alias" interface addresses or interfaces
-that appear later on such as dynamic PPP links.  There are some hacked web
-servers and versions of "inetd" floating around that specifically bind as well,
-based on a configuration file -- these generally *are* bound to alias addresses
-to offer several different address-based services from one machine.
-
-Using -e to start a remote backdoor shell is another obvious sort of thing,
-easier than constructing a file for inetd to listen on "ingreslock" or
-something, and you can access-control it against other people by specifying a
-client host and port.  Experience with this truly demonstrates how fragile the
-barrier between being "logged in" or not really is, and is further expressed by
-scripts/bsh.  If you're already behind a firewall, it may be easier to make an
-*outbound* connection and then run a shell; a small wrapper script can
-periodically try connecting to a known place and port, you can later listen
-there until the inbound connection arrives, and there's your shell.  Running
-a shell via UDP has several interesting features, although be aware that once
-"connected", the UDP stub sockets tend to show up in "netstat" just like TCP
-connections and may not be quite as subtle as you wanted.  Packets may also be
-lost, so use TCP if you need reliable connections.  But since UDP is
-connectionless, a hookup of this sort will stick around almost forever, even if
-you ^C out of netcat or do a reboot on your side, and you only need to remember
-the ports you used on both ends to reestablish.  And outbound UDP-plus-exec
-connection creates the connected socket and starts the program immediately.  On
-a listening UDP connection, the socket is created once a first packet is
-received.  In either case, though, such a "connection" has the interesting side
-effect that only your client-side IP address and [chosen?] source port will
-thereafter be able to talk to it.  Instant access control!  A non-local third
-party would have to do ALL of the following to take over such a session:
-
-	forge UDP with your source address [trivial to do; see below]
-	guess the port numbers of BOTH ends, or sniff the wire for them
-	arrange to block ICMP or UDP return traffic between it and your real
-	  source, so the session doesn't die with a network write error.
-
-The companion program data/rservice.c is helpful in scripting up any sort of
-r-service username or password guessing attack.  The arguments to "rservice"
-are simply the strings that get null-terminated and passed over an "rcmd"-style
-connection, with the assumption that the client does not need a separate
-standard-error port.  Brute-force password banging is best done via "rexec" if
-it is available since it is less likely to log failed attempts.  Thus, doing
-"rservice joe joespass pwd | nc target exec" should return joe's home dir if
-the password is right, or "Permission denied."  Plug in a dictionary and go to
-town.  If you're attacking rsh/rlogin, remember to be root and bind to a port
-between 512 and 1023 on your end, and pipe in "rservice joe joe pwd" and such.
-
-Netcat can prevent inadvertently sending extra information over a telnet
-connection.  Use "nc -t" in place of telnet, and daemons that try to ask for
-things like USER and TERM environment variables will get no useful answers, as
-they otherwise would from a more recent telnet program.  Some telnetds actually
-try to collect this stuff and then plug the USER variable into "login" so that
-the caller is then just asked for a password!  This mechanism could cause a
-login attempt as YOUR real username to be logged over there if you use a
-Borman-based telnet instead of "nc -t".
-
-Got an unused network interface configured in your kernel [e.g. SLIP], or
-support for alias addresses?  Ifconfig one to be any address you like, and bind
-to it with -s to enable all sorts of shenanigans with bogus source addresses.
-The interface probably has to be UP before this works; some SLIP versions
-need a far-end address before this is true.  Hammering on UDP services is then
-a no-brainer.  What you can do to an unfiltered syslog daemon should be fairly
-obvious; trimming the conf file can help protect against it.  Many routers out
-there still blindly believe what they receive via RIP and other routing
-protocols.  Although most UDP echo and chargen servers check if an incoming
-packet was sent from *another* "internal" UDP server, there are many that still
-do not, any two of which [or many, for that matter] could keep each other
-entertained for hours at the expense of bandwidth.  And you can always make
-someone wonder why she's being probed by nsa.gov.
-
-Your TCP spoofing possibilities are mostly limited to destinations you can
-source-route to while locally bound to your phony address.  Many sites block
-source-routed packets these days for precisely this reason.  If your kernel
-does oddball things when sending source-routed packets, try moving the pointer
-around with -G.  You may also have to fiddle with the routing on your own
-machine before you start receiving packets back.  Warning: some machines still
-send out traffic using the source address of the outbound interface, regardless
-of your binding, especially in the case of localhost.  Check first.  If you can
-open a connection but then get no data back from it, the target host is
-probably killing the IP options on its end [this is an option inside TCP
-wrappers and several other packages], which happens after the 3-way handshake
-is completed.  If you send some data and observe the "send-q" side of "netstat"
-for that connection increasing but never getting sent, that's another symptom.
-Beware: if Sendmail 8.7.x detects a source-routed SMTP connection, it extracts
-the hop list and sticks it in the Received: header!
-
-SYN bombing [sometimes called "hosing"] can disable many TCP servers, and if
-you hit one often enough, you can keep it unreachable for days.  As is true of
-many other denial-of-service attacks, there is currently no defense against it
-except maybe at the human level.  Making kernel SOMAXCONN considerably larger
-than the default and the half-open timeout smaller can help, and indeed some
-people running large high-performance web servers have *had* to do that just to
-handle normal traffic.  Taking out mailers and web servers is sociopathic, but
-on the other hand it is sometimes useful to be able to, say, disable a site's
-identd daemon for a few minutes.  If someone realizes what is going on,
-backtracing will still be difficult since the packets have a phony source
-address, but calls to enough ISP NOCs might eventually pinpoint the source.
-It is also trivial for a clueful ISP to watch for or even block outgoing
-packets with obviously fake source addresses, but as we know many of them are
-not clueful or willing to get involved in such hassles.  Besides, outbound
-packets with an [otherwise unreachable] source address in one of their net
-blocks would look fairly legitimate.
-
-Notes
-=====
-
-A discussion of various caveats, subtleties, and the design of the innards.
-
-As of version 1.07 you can construct a single file containing command arguments
-and then some data to transfer.  Netcat is now smart enough to pick out the
-first line and build the argument list, and send any remaining data across the
-net to one or multiple ports.  The first release of netcat had trouble with
-this -- it called fgets() for the command line argument, which behind the
-scenes does a large read() from standard input, perhaps 4096 bytes or so, and
-feeds that out to the fgets() library routine.  By the time netcat 1.00 started
-directly read()ing stdin for more data, 4096 bytes of it were gone.  It now
-uses raw read() everywhere and does the right thing whether reading from files,
-pipes, or ttys.  If you use this for multiple-port connections, the single
-block of data will now be a maximum of 8K minus the first line.  Improvements
-have been made to the logic in sending the saved chunk to each new port.  Note
-that any command-line arguments hidden using this mechanism could still be
-extracted from a core dump.
-
-When netcat receives an inbound UDP connection, it creates a "connected socket"
-back to the source of the connection so that it can also send out data using
-normal write().  Using this mechanism instead of recvfrom/sendto has several
-advantages -- the read/write select loop is simplified, and ICMP errors can in
-effect be received by non-root users.  However, it has the subtle side effect
-that if further UDP packets arrive from the caller but from different source
-ports, the listener will not receive them.  UDP listen mode on a multihomed
-machine may have similar quirks unless you specifically bind to one of its
-addresses.  It is not clear that kernel support for UDP connected sockets
-and/or my understanding of it is entirely complete here, so experiment...
-
-You should be aware of some subtleties concerning UDP scanning.  If -z is on,
-netcat attempts to send a single null byte to the target port, twice, with a
-small time in between.  You can either use the -w timeout, or netcat will try
-to make a "sideline" TCP connection to the target to introduce a small time
-delay equal to the round-trip time between you and the target.  Note that if
-you have a -w timeout and -i timeout set, BOTH take effect and you wait twice
-as long.  The TCP connection is to a normally refused port to minimize traffic,
-but if you notice a UDP fast-scan taking somewhat longer than it should, it
-could be that the target is actually listening on the TCP port.  Either way,
-any ICMP port-unreachable messages from the target should have arrived in the
-meantime.  The second single-byte UDP probe is then sent.  Under BSD kernels,
-the ICMP error is delivered to the "connected socket" and the second write
-returns an error, which tells netcat that there is NOT a UDP service there.
-While Linux seems to be a fortunate exception, under many SYSV derived kernels
-the ICMP is not delivered, and netcat starts reporting that *all* the ports are
-"open" -- clearly wrong.  [Some systems may not even *have* the "udp connected
-socket" concept, and netcat in its current form will not work for UDP at all.]
-If -z is specified and only one UDP port is probed, netcat's exit status
-reflects whether the connection was "open" or "refused" as with TCP.
-
-It may also be that UDP packets are being blocked by filters with no ICMP error
-returns, in which case everything will time out and return "open".  This all
-sounds backwards, but that's how UDP works.  If you're not sure, try "echo
-w00gumz | nc -u -w 2 target 7" to see if you can reach its UDP echo port at
-all.  You should have no trouble using a BSD-flavor system to scan for UDP
-around your own network, although flooding a target with the high activity that
--z generates will cause it to occasionally drop packets and indicate false
-"opens".  A more "correct" way to do this is collect and analyze the ICMP
-errors, as does SATAN's "udp_scan" backend, but then again there's no guarantee
-that the ICMP gets back to you either.  Udp_scan also does the zero-byte
-probes but is excruciatingly careful to calculate its own round-trip timing
-average and dynamically set its own response timeouts along with decoding any
-ICMP received.  Netcat uses a much sleazier method which is nonetheless quite
-effective.  Cisco routers are known to have a "dead time" in between ICMP
-responses about unreachable UDP ports, so a fast scan of a cisco will show
-almost everything "open".  If you are looking for a specific UDP service, you
-can construct a file containing the right bytes to trigger a response from the
-other end and send that as standard input.  Netcat will read up to 8K of the
-file and send the same data to every UDP port given.  Note that you must use a
-timeout in this case [as would any other UDP client application] since the
-two-write probe only happens if -z is specified.
-
-Many telnet servers insist on a specific set of option negotiations before
-presenting a login banner.  On a raw connection you will see this as small
-amount of binary gook.  My attempts to create fixed input bytes to make a
-telnetd happy worked some places but failed against newer BSD-flavor ones,
-possibly due to timing problems, but there are a couple of much better
-workarounds.  First, compile with -DTELNET and use -t if you just want to get
-past the option negotiation and talk to something on a telnet port.  You will
-still see the binary gook -- in fact you'll see a lot more of it as the options
-are responded to behind the scenes.  The telnet responder does NOT update the
-total byte count, or show up in the hex dump -- it just responds negatively to
-any options read from the incoming data stream.  If you want to use a normal
-full-blown telnet to get to something but also want some of netcat's features
-involved like settable ports or timeouts, construct a tiny "foo" script:
-
-	#! /bin/sh
-	exec nc -otheroptions targethost 23
-
-and then do
-
-	nc -l -p someport -e foo localhost &
-	telnet localhost someport
-
-and your telnet should connect transparently through the exec'ed netcat to
-the target, using whatever options you supplied in the "foo" script.  Don't
-use -t inside the script, or you'll wind up sending *two* option responses.
-
-I've observed inconsistent behavior under some Linuxes [perhaps just older
-ones?] when binding in listen mode.  Sometimes netcat binds only to "localhost"
-if invoked with no address or port arguments, and sometimes it is unable to
-bind to a specific address for listening if something else is already listening
-on "any".  The former problem can be worked around by specifying "-s 0.0.0.0",
-which will do the right thing despite netcat claiming that it's listening on
-[127.0.0.1].  This is a known problem -- for example, there's a mention of it
-in the makefile for SOCKS.  On the flip side, binding to localhost and sending
-packets to some other machine doesn't work as you'd expect -- they go out with
-the source address of the sending interface instead.  The Linux kernel contains
-a specific check to ensure that packets from 127.0.0.1 are never sent to the
-wire; other kernels may contain similar code.  Linux, of course, *still*
-doesn't support source-routing, but they claim that it and many other network
-improvements are at least breathing hard.
-
-There are several possible errors associated with making TCP connections, but
-to specifically see anything other than "refused", one must wait the full
-kernel-defined timeout for a connection to fail.  Netcat's mechanism of
-wrapping an alarm timer around the connect prevents the *real* network error
-from being returned -- "errno" at that point indicates "interrupted system
-call" since the connect attempt was interrupted.  Some old 4.3 BSD kernels
-would actually return things like "host unreachable" immediately if that was
-the case, but most newer kernels seem to wait the full timeout and *then* pass
-back the real error.  Go figure.  In this case, I'd argue that the old way was
-better, despite those same kernels generally being the ones that tear down
-*established* TCP connections when ICMP-bombed.
-
-Incoming socket options are passed to applications by the kernel in the
-kernel's own internal format.  The socket-options structure for source-routing
-contains the "first-hop" IP address first, followed by the rest of the real
-options list.  The kernel uses this as is when sending reply packets -- the
-structure is therefore designed to be more useful to the kernel than to humans,
-but the hex dump of it that netcat produces is still useful to have.
-
-Kernels treat source-routing options somewhat oddly, but it sort of makes sense
-once one understands what's going on internally.  The options list of addresses
-must contain hop1, hop2, ..., destination.  When a source-routed packet is sent
-by the kernel [at least BSD], the actual destination address becomes irrelevant
-because it is replaced with "hop1", "hop1" is removed from the options list,
-and all the other addresses in the list are shifted up to fill the hole.  Thus
-the outbound packet is sent from your chosen source address to the first
-*gateway*, and the options list now contains hop2, ..., destination.  During
-all this address shuffling, the kernel does NOT change the pointer value, which
-is why it is useful to be able to set the pointer yourself -- you can construct
-some really bizarre return paths, and send your traffic fairly directly to the
-target but around some larger loop on the way back.  Some Sun kernels seem to
-never flip the source-route around if it contains less than three hops, never
-reset the pointer anyway, and tries to send the packet [with options containing
-a "completed" source route!!] directly back to the source.  This is way broken,
-of course.  [Maybe ipforwarding has to be on?  I haven't had an opportunity to
-beat on it thoroughly yet.]
-
-"Credits" section: The original idea for netcat fell out of a long-standing
-desire and fruitless search for a tool resembling it and having the same
-features.  After reading some other network code and realizing just how many
-cool things about sockets could be controlled by the calling user, I started
-on the basics and the rest fell together pretty quickly.  Some port-scanning
-ideas were taken from Venema/Farmer's SATAN tool kit, and Pluvius' "pscan"
-utility.  Healthy amounts of BSD kernel source were perused in an attempt to
-dope out socket options and source-route handling; additional help was obtained
-from Dave Borman's telnet sources.  The select loop is loosely based on fairly
-well-known code from "rsh" and Richard Stevens' "sock" program [which itself is
-sort of a "netcat" with more obscure features], with some more paranoid
-sanity-checking thrown in to guard against the distinct likelihood that there
-are subtleties about such things I still don't understand.  I found the
-argument-hiding method cleanly implemented in Barrett's "deslogin"; reading the
-line as input allows greater versatility and is much less prone to cause
-bizarre problems than the more common trick of overwriting the argv array.
-After the first release, several people contributed portability fixes; they are
-credited in generic.h and the Makefile.  Lauren Burka inspired the ascii art
-for this revised document.  Dean Gaudet at Wired supplied a precursor to
-the hex-dump code, and mudge@l0pht.com originally experimented with and
-supplied code for the telnet-options responder.  Outbound "-e <prog>" resulted
-from a need to quietly bypass a firewall installation.  Other suggestions and
-patches have rolled in for which I am always grateful, but there are only 26
-hours per day and a discussion of feature creep near the end of this document.
-
-Netcat was written with the Russian railroad in mind -- conservatively built
-and solid, but it *will* get you there.  While the coding style is fairly
-"tight", I have attempted to present it cleanly [keeping *my* lines under 80
-characters, dammit] and put in plenty of comments as to why certain things
-are done.  Items I know to be questionable are clearly marked with "XXX".
-Source code was made to be modified, but determining where to start is
-difficult with some of the tangles of spaghetti code that are out there.
-Here are some of the major points I feel are worth mentioning about netcat's
-internal design, whether or not you agree with my approach.
-
-Except for generic.h, which changes to adapt more platforms, netcat is a single
-source file.  This has the distinct advantage of only having to include headers
-once and not having to re-declare all my functions in a billion different
-places.  I have attempted to contain all the gross who's-got-what-.h-file
-things in one small dumping ground.  Functions are placed "dependencies-first",
-such that when the compiler runs into the calls later, it already knows the
-type and arguments and won't complain.  No function prototyping -- not even the
-__P(()) crock -- is used, since it is more portable and a file of this size is
-easy enough to check manually.  Each function has a standard-format comment
-ahead of it, which is easily found using the regexp " :$".  I freely use gotos.
-Loops and if-clauses are made as small and non-nested as possible, and the ends
-of same *marked* for clarity [I wish everyone would do this!!].
-
-Large structures and buffers are all malloc()ed up on the fly, slightly larger
-than the size asked for and zeroed out.  This reduces the chances of damage
-from those "end of the buffer" fencepost errors or runaway pointers escaping
-off the end.  These things are permanent per run, so nothing needs to be freed
-until the program exits.
-
-File descriptor zero is always expected to be standard input, even if it is
-closed.  If a new network descriptor winds up being zero, a different one is
-asked for which will be nonzero, and fd zero is simply left kicking around
-for the rest of the run.  Why?  Because everything else assumes that stdin is
-always zero and "netfd" is always positive.  This may seem silly, but it was a
-lot easier to code.  The new fd is obtained directly as a new socket, because
-trying to simply dup() a new fd broke subsequent socket-style use of the new fd
-under Solaris' stupid streams handling in the socket library.
-
-The catch-all message and error handlers are implemented with an ample list of
-phoney arguments to get around various problems with varargs.  Varargs seems
-like deliberate obfuscation in the first place, and using it would also
-require use of vfprintf() which not all platforms support.  The trailing
-sleep in bail() is to allow output to flush, which is sometimes needed if
-netcat is already on the other end of a network connection.
-
-The reader may notice that the section that does DNS lookups seems much
-gnarlier and more confusing than other parts.  This is NOT MY FAULT.  The
-sockaddr and hostent abstractions are an abortion that forces the coder to
-deal with it.  Then again, a lot of BSD kernel code looks like similar
-struct-pointer hell.  I try to straighten it out somewhat by defining my own
-HINF structure, containing names, ascii-format IP addresses, and binary IP
-addresses.  I fill this structure exactly once per host argument, and squirrel
-everything safely away and handy for whatever wants to reference it later.
-
-Where many other network apps use the FIONBIO ioctl to set non-blocking I/O
-on network sockets, netcat uses straightforward blocking I/O everywhere.
-This makes everything very lock-step, relying on the network and filesystem
-layers to feed in data when needed.  Data read in is completely written out
-before any more is fetched.  This may not be quite the right thing to do under
-some OSes that don't do timed select() right, but this remains to be seen.
-
-The hexdump routine is written to be as fast as possible, which is why it does
-so much work itself instead of just sprintf()ing everything together.  Each
-dump line is built into a single buffer and atomically written out using the
-lowest level I/O calls.  Further improvements could undoubtedly be made by
-using writev() and eliminating all sprintf()s, but it seems to fly right along
-as is.  If both exec-a-prog mode and a hexdump file is asked for, the hexdump
-flag is deliberately turned off to avoid creating random zero-length files.
-Files are opened in "truncate" mode; if you want "append" mode instead, change
-the open flags in main().
-
-main() may look a bit hairy, but that's only because it has to go down the
-argv list and handle multiple ports, random mode, and exit status.  Efforts
-have been made to place a minimum of code inside the getopt() loop.  Any real
-work is sent off to functions in what is hopefully a straightforward way.
-
-Obligatory vendor-bash: If "nc" had become a standard utility years ago,
-the commercial vendors would have likely packaged it setuid root and with
--DGAPING_SECURITY_HOLE turned on but not documented.  It is hoped that netcat
-will aid people in finding and fixing the no-brainer holes of this sort that
-keep appearing, by allowing easier experimentation with the "bare metal" of
-the network layer.
-
-It could be argued that netcat already has too many features.  I have tried
-to avoid "feature creep" by limiting netcat's base functionality only to those
-things which are truly relevant to making network connections and the everyday
-associated DNS lossage we're used to.  Option switches already have slightly
-overloaded functionality.  Random port mode is sort of pushing it.  The
-hex-dump feature went in later because it *is* genuinely useful.  The
-telnet-responder code *almost* verges on the gratuitous, especially since it
-mucks with the data stream, and is left as an optional piece.  Many people have
-asked for example "how 'bout adding encryption?" and my response is that such
-things should be separate entities that could pipe their data *through* netcat
-instead of having their own networking code.  I am therefore not completely
-enthusiastic about adding any more features to this thing, although you are
-still free to send along any mods you think are useful.
-
-Nonetheless, at this point I think of netcat as my tcp/ip swiss army knife,
-and the numerous companion programs and scripts to go with it as duct tape.
-Duct tape of course has a light side and a dark side and binds the universe
-together, and if I wrap enough of it around what I'm trying to accomplish,
-it *will* work.  Alternatively, if netcat is a large hammer, there are many
-network protocols that are increasingly looking like nails by now...
-
-_H* 960320 v1.10 RELEASE -- happy spring!
diff --git a/usr.bin/nc/netcat.blurb b/usr.bin/nc/netcat.blurb
deleted file mode 100644
index 2c540ad9dcc..00000000000
--- a/usr.bin/nc/netcat.blurb
+++ /dev/null
@@ -1,61 +0,0 @@
-Netcat 1.10 is an updated release of Netcat, 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.
-
-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
-
-A very short list of potential uses:
-
-	Script backends
-	Scanning ports and inventorying services, automated probes
-	Backup handlers
-	File transfers
-	Server testing, simulation, debugging, and hijacking
-	Firewall testing
-	Proxy gatewaying
-	Network performance testing
-	Address spoofing tests
-	Protecting X servers
-	1001 other uses you'll likely come up with
-
-Changes between the 1.00 release and this release:
-
-	Better portability -- updated generic.h and Makefile [thanx folks!]
-	Indication of local-end interface address on inbound connections
-	That's *Dave* Borman's telnet, not Paul Borman...
-	Better indication of DNS errors
-	Total byte counts printed if -v -v is used
-	A bunch of front-end driver companion programs and scripts
-	Better handling of stdin arguments-plus-data
-	Hex-dump feature
-	Telnet responder
-	Program exec works inbound or outbound now
-
-Netcat and the associated package is a product of Avian Research, and is freely
-available in full source form with no restrictions save an obligation to give
-credit where due.  Get it via anonymous FTP at avian.org:/src/hacks/nc110.tgz
-which is a gzipped tar file and not to be confused with its version 1.00
-precursor, nc100.tgz.  Other distribution formats can be accomodated upon
-request.  Netcat is also mirrored at the following [faster] sites:
-
-	zippy.telcom.arizona.edu:/pub/mirrors/avian.org/hacks/nc110.tgz
-	ftp.sterling.com:/mirrors/avian.org/src/hacks/nc110.tgz
-	coast.cs.purdue.edu:/pub/tools/unix/netcat/nc110.tgz
-	ftp.rge.com:/pub/security/coast/mirrors/avian.org/netcat/nc110.tgz
-
-_H* 960320