Project Report tool



Yüklə 52,46 Kb.
tarix14.10.2017
ölçüsü52,46 Kb.
#4661

Project Report

TOOL: NetCat is a simple Unix/Windows utility which reads and writes data across

network connections, using TCP or UDP protocol.




Source

NetCat is available at http://www.atstake.com/research/tools/network_utilities/

NetCat was originally developed by Hobbit for Unix platforms but has now

been adapted to windows as well. The author of windows version for netcat is

Chris Wysopal. Chris Wysopal, vice president of research and development,

leads @stake's product development team which is building the next generation

of application security software tools. Working with vendors and the general

public, Wysopal is also responsible for managing @stake's vulnerability

research and disclosure process.

Wysopal's career in the information security industry has spanned over 15 years

where he has held positions in the industry while also serving as a regular

advisor to various government agencies. Recognized as an expert in the field of information security, Wysopal presented expert testimony in May of 1998 on the state of government computer security to the US Senate Committee on Governmental Affairs and again in September of 2003 on the problem of viruses and worms to the US House Subcommittee on Technology. He has also presented at West Point and to the Defense Information Systems Agency (DISA) on how to build more secure software. As a co-founder of the Organization for Internet Safety (OIS), Wysopal works with leading technology vendors, security researchers and consultancies to develop standards for best practices on how the technology industry will report and respond to security vulnerabilities.



DEFINITION

Netcat has been dubbed the network swiss army knife. It is a simple Unix utility

which reads and writes data across network connections, using TCP or UDP

protocol. The current version for Unix was released in 1996 by Hobbit . The

Windows version was released by Chris Wysopal in 1998. 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.
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. 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

Netcat as a tool is almost simmilar to Telnet but netcat is a lot smaller and faster

as comparred to Telnet and has numerous other advantages as well.

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

Netcat is simple and versatile tool which can be used to perform various network tasks.How to Use Netcat ? the various ways in which netcat can be used are


We invoke the executable nc with command line parameters

nc [switches] [host] [port number]


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.
The host argument can be a name or IP address. If specified netcat will accept only numeric addresses and will not perform DNS look up. 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.


A port argument is required for outbound connections, and can be numeric or a name. If -n is specified, only numeric arguments are valid.
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. 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.
-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 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.
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.
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.
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.




Server side listening




Client side Receiving data

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. . 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.
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. 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. Netcat's handling of "-g" is modeled after "traceroute".



Example uses -- the light side
Driving netcat with simple shell or expect scripts is an easy and flexible way to do fairly complex tasks. 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.
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. 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.
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.

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 -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.


Example uses -- the dark side
A versatile tool like this can be useful to any Shade of Hat. Netcat can be used to attack or defend a system.
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 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.
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.

Design Subtelities of NetCat

Netcat picks out the first line and build the argument list, and send any remaining data across the net to one or multiple ports.



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.
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.

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.

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.



Test Case
Netcat can be used to pull Using netcat we can get the full HTTP header which allows us to see which webserver the website is running
We can also run a quick shell on the remote machine using –l and the –e option. We can run netcat listening on a particular port and when a connection is made netcat executes the program of our choice. We can use netcat to listen on any port, interestingly we can do that with firewall prot 53 and netbios port 139.


Test Results
We type at console the command
nc –v www.hotmail.com 80

and then we type in \HTTP \1.0


and we get the full header for the website


We find that the website is running Microsoft-Iis/5.0 Server

Network environment in which tool was used

I have used the tool in my home network setup where we have three computers connected to the router and router is connected to the ISP. All the functionality of the netcat has been tested in this environment.


Copy Of Tool
Alongwith the report I have enclosed a floppy disk having a zipped file of the tool which can be extarcted and used We need a unzip utility to extract the executable a common application like winzip is just fine.


References:
www.stake.com
Readme file of Netcat1.1 for Windows NT by Chris Wysopal
Readme file of Netcat1.10 for Unix by Hobbit

Yüklə 52,46 Kb.

Dostları ilə paylaş:




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©genderi.org 2024
rəhbərliyinə müraciət

    Ana səhifə