Hubbry Logo
NetcatNetcatMain
Open search
Netcat
Community hub
Netcat
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Netcat
Netcat
Netcat
View on Wikipedia
from Wikipedia
netcat
Original author*Hobbit*
DeveloperAvian Research
Initial releaseOctober 28, 1995; 29 years ago (1995-10-28)[1]
Final release
1.10 / March 1996; 29 years ago (1996-03)
Operating systemUnix and Unix-like, DOS, Microsoft Windows, Windows CE
TypeNetwork utility
LicenseOriginal version: custom, permissive license
GNU version: GPL
OpenBSD version: BSD
Websitenc110.sourceforge.io

netcat (often abbreviated to nc) is a computer networking utility for reading from and writing to network connections using TCP or UDP. The command is designed to be a dependable back-end 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 investigation tool, since it can produce almost any kind of connection its user could need and has a number of built-in capabilities.

It is able to perform port scanning, file transferring and port listening.

Features

[edit]

The original netcat's features include:[2]

  • 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 randomization
  • 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 establish connections
  • Optional telnet-options responder

Rewrites like GNU's and OpenBSD's support additional features. For example, OpenBSD's nc supports TLS, and GNU netcat natively supports a tunneling mode supporting UDP and TCP (optionally allowing one to be tunneled over the other) in a single command,[3] where other versions may require piping data from one netcat instance to another.

Ports and reimplementations

[edit]

The original version of netcat was a Unix program. The last version (1.10) was released in March 1996.[4]

There are several implementations on POSIX systems, including rewrites from scratch like GNU netcat[5] or OpenBSD netcat,[6] the latter of which supports IPv6 and TLS. The OpenBSD version has been ported to the FreeBSD base,[7] Windows/Cygwin,[8] and Linux.[9] Mac OS X comes with netcat installed as of OSX 10.13 or users can use MacPorts to install a variant.[10]

A DOS version of netcat called NTOOL is included in the FreeDOS Package group Networking.[11] It is based on the WatTCP stack and licensed under the European Union Public Licence Version 1.1.[12]

Known ports for embedded systems includes versions for Windows CE (named "Netcat 4 wince"[13]) or for the iPhone.[14]

BusyBox includes by default a lightweight version of netcat named mini-netcat.[15] Another version with more features, named bloaty nc, is also available.[16]

Solaris 11 includes netcat implementation based on OpenBSD netcat.[17]

Socat[18] is a more complex variant of netcat. It is larger and more flexible and has more options that must be configured for a given task. On February 1, 2016, Santiago Zanella-Beguelin and Microsoft Vulnerability Research issued a security advisory regarding a composite Diffie-Hellman parameter which had been hard-coded into the OpenSSL implementation of socat.[19] The implausibility that a composite might have been unintentionally introduced where a prime number is required has led to the suspicion of sabotage to introduce a backdoor software vulnerability.[20] This socat bug affected version 1.7.3.0 and 2.0.0-b8 it was corrected in following releases from 1.7.3.1 and 2.0.0-b9.[19]

Cryptcat[21] is a version of netcat with integrated transport encryption capabilities.

In the middle of 2005, Nmap announced another netcat incarnation called Ncat.[22] It features new possibilities such as "Connection Brokering", TCP/UDP Redirection, SOCKS4 client and server support, ability to "Chain" Ncat processes, HTTP CONNECT proxying (and proxy chaining), SSL connect/listen support and IP address/connection filtering. Like Nmap, Ncat is cross-platform.

On some systems, modified versions or similar netcat utilities go by the command name(s) nc, ncat, pnetcat, socat, sock, socket, sbd.

ncat

[edit]

Ncat is a similar tool to netcat provided by Nmap suite.[22] "While Ncat isn't built on any code from the “traditional” Netcat (or any other implementation), Ncat is most definitely based on Netcat in spirit and functionality."[23]

Ncat features includes: ability to chain Ncats together, redirect both TCP and UDP ports to other sites, SSL support, and proxy connections via SOCKS4 or HTTP (CONNECT method) proxies (with optional proxy authentication as well).[24]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Netcat

View on Grokipedia
from Grokipedia
Netcat, often abbreviated as nc, is a versatile command-line networking utility designed to read from and write to network connections using the TCP or UDP protocols. It functions as a reliable back-end tool that can establish connections, listen on ports, transfer data streams, and perform basic network diagnostics, making it a foundational program for scripting, , and ad-hoc networking tasks across systems. Originally developed in 1995 by an anonymous programmer known as Hobbit under the banner of Avian Research, netcat was released as public-domain software to provide a simple yet powerful interface for network I/O operations. The tool quickly gained popularity for its minimalist design and extensibility, earning the nickname "the Swiss Army knife of networking" due to its wide range of applications, including port scanning, file transfers, creating backdoors, and even simple chat servers. Over time, various implementations emerged to address limitations in the original version, such as lack of IPv6 support and security features; notable among these is Ncat, a modern reimplementation created by the Nmap Project in 2009, which adds capabilities like SSL encryption, proxy support, and IPv6 compatibility while maintaining backward compatibility with traditional netcat syntax. Netcat's core features include options for specifying source ports and addresses, enabling UDP mode, performing zero-I/O port scans, and executing programs upon connection, though some advanced options like program execution require compilation flags for reasons. It is included in most Unix distributions, such as those from and , and continues to be a staple in cybersecurity, system administration, and penetration testing due to its efficiency and lack of dependencies.

History

Origins and Development

Netcat was invented in 1995 by , a pseudonymous developer associated with the email address [email protected], as a straightforward Unix utility designed to read and write data across TCP and UDP network connections without imposing specific protocol assumptions. The tool emerged from the need for a lightweight, versatile backend for network debugging, exploration, and scripting, filling a gap left by more rigid utilities like , which lacked flexibility for arbitrary data stream handling. drew inspiration from earlier security and scanning tools such as and pscan, aiming to create a reliable program that could serve as a foundational component for other scripts while offering built-in capabilities for direct use in network tasks. Developed in specifically for systems, netcat was crafted in an era when networking tools were proliferating within the hacker and communities, emphasizing simplicity and portability across Unix variants. The initial implementation focused on core functionality for establishing inbound or outbound connections, with an emphasis on minimal dependencies to ensure broad usability on contemporary Unix platforms like and BSD derivatives. Early testing and refinements addressed common issues in network programming, such as handling half-closed connections and proxy behaviors, reflecting the practical challenges of infrastructure. Key milestones in netcat's early history include its release as version 1.00, announced on October 28, 1995, via the Bugtraq mailing list to the broader security and Unix user communities, marking its entry into public circulation. Subsequent updates, culminating in version 1.10 by early 1996, incorporated portability enhancements and bug fixes based on user reports, solidifying its role as an essential utility in the evolving landscape of open-source networking tools.

Release and Early Adoption

Netcat's initial public release occurred on October 28, , as version 1.00, authored by under the auspices of Avian Research. This version was distributed freely in full source form via the Avian Research FTP site at avian.org, with mirrors on sites such as zippy.telcom.arizona.edu and ftp.sterling.com, and no explicit restrictions beyond crediting the author. The tool was positioned as a versatile utility for reading and writing data across TCP or UDP connections, suitable for network exploration and debugging. A subsequent update, version 1.10, was released on March 20, 1996, incorporating bug fixes such as improved handling of stdin buffering and raw read operations to prevent in piped inputs, along with minor enhancements for reliability in various network scenarios. Distribution continued through the same channels, with the source code archived and shared within Unix and early open-source communities via FTP and mailing lists like Bugtraq. By the late 1990s, netcat had been integrated into several distributions as a standard networking package for system administrators. Early adoption centered on its utility in auditing—such as testing firewall rules and accessibility—network debugging for diagnosing connectivity issues, and scripting for automated data transfers in Unix environments. Its popularity surged in open-source circles due to the straightforward and broad applicability, despite the absence of a formal initially. The original implementation was released in the , enabling unrestricted use and modification, which accelerated its spread but also prompted the creation of licensed forks. This licensing status was later explicitly clarified as by the author, yet it influenced the development of GPL- and BSD-licensed variants, such as netcat, to comply with redistribution policies in corporate and distribution environments wary of unlicensed code.

Technical Overview

Protocol and Connection Support

Netcat primarily interacts with two core network protocols: TCP, which provides reliable, connection-oriented streams for ordered and error-checked data delivery, and UDP, which enables connectionless transmission without guarantees of delivery or order. These protocols allow netcat to function as a versatile backend for reading and writing data across network connections, with TCP as the default for most operations. The tool operates in two main connection modes to establish network interactions. In client mode, netcat initiates outbound connections by directly specifying the remote host and , facilitating data transfer to a listening endpoint. Conversely, server mode involves binding to a local using the -l option to listen for and accept incoming connections from remote clients. Protocol selection between TCP and UDP is controlled via dedicated command-line options, such as -u for UDP mode. Regarding address families, the original netcat implementation defaults to IPv4 support, handling numeric IP addresses and hostname resolution without native capabilities. was introduced in subsequent variants, including the rewrite, which explicitly added dual-stack compatibility for both address families. Netcat's data handling model treats network sockets as file-like bidirectional I/O streams, seamlessly integrating with Unix pipes and redirection. It reads input from standard input (stdin) and forwards it over the network connection, while simultaneously relaying any received network data to standard output (stdout), enabling efficient data shoveling in both directions until the connection closes. This approach allows network traffic to be processed as ordinary streams, supporting tasks like echoing data or tunneling without additional protocol overhead.

Command-Line Syntax and Options

The basic command-line syntax for netcat is nc [options] [host] [port], where host specifies the target hostname or IP address and port indicates the destination port number or range; omitting host and port places netcat in listening mode when combined with appropriate options. This structure allows netcat to function as either a client connecting to a remote endpoint or a server awaiting inbound connections, with options preceding the host and port arguments to customize protocol, timing, and behavior. For example, nc example.com 80 establishes a TCP connection to port 80 on the specified host, piping standard input to the remote side and relaying network data to standard output until the connection closes. Key options modify core operations, such as -l to enable listening mode for incoming connections (often paired with -p port to bind to a specific local ), -u to switch from the default TCP to UDP protocol, -v for that outputs diagnostic messages about connection progress, and -p source_port to specify the local source port for outgoing connections. Additional essential flags include -s source_IP to bind the connection to a particular local , -w timeout_seconds to set a timeout for connection establishment or inactivity (defaulting to no timeout), -e program to execute a specified program upon successful connection (available in the original implementation when compiled with the GAPING_SECURITY_HOLE option), and -z for zero-I/O scanning mode, which probes ports without sending data to detect listening services. By default, netcat operates with bidirectional input/output, reading from standard input (up to 8 KB chunks) and writing to standard output while mirroring network in the reverse direction, without performing end-of-line conversions for broad compatibility. Options for controlling flow include -i interval_seconds, which introduces delays between transmitted lines to regulate data rates, and in certain implementations like OpenBSD's port, -k to keep the listener active for multiple sequential connections after the initial one closes (incompatible with single-use modes). Netcat handles errors by exiting with a nonzero status code for failures such as denied connections or timeouts. Refused connections are generally treated as non-fatal, except when attempting a single TCP connection to one , in which case it exits with a nonzero status. The original implementation adheres to standards through the use of raw read() and write() system calls for I/O operations, ensuring portability across systems without relying on non-blocking modes or advanced buffering.

Features and Capabilities

Core Networking Functions

Netcat's core networking functions enable straightforward transfer and connection management over TCP and UDP, making it a fundamental tool for network communication without relying on higher-level protocols. At its essence, netcat reads from standard input and writes to standard output across network sockets, allowing bidirectional streams between endpoints. This simplicity supports tasks like file transmission, where one host connects to another to push or pull reliably. Data transfer is achieved by directing file contents through netcat commands, with the sender piping input to a remote connection and the receiver capturing output to a file. For instance, to send a file, the command nc host port < filename streams the file's contents to the specified host and port, while the receiving end uses nc -l -p port > filename to listen and save the incoming data. Transfers operate as raw streams, closing upon EOF, and can be resumed after interruption by combining netcat with the dd utility to skip known byte offsets on the sender (e.g., dd if=filename bs=1 skip=offset | nc host port) and append to the partial file on the receiver, requiring manual tracking of transferred bytes for alignment. Port listening and forwarding allow netcat to bind to local ports for incoming connections, enabling scenarios like reverse shells or basic proxies. In listening mode, nc -l -p port awaits a client connection and relays data bidirectionally; for a reverse shell, variants supporting the -e option execute a program upon connection, such as nc -l -p port -e /bin/sh, providing remote command execution over the established socket. Simple port forwarding can route traffic through proxies, as in nc -x proxyhost:proxyport host port using SOCKS or HTTP methods, though availability depends on the implementation. Banner grabbing involves initiating a connection to a remote service and capturing its initial response, aiding in service identification without full interaction. The command nc -v host port connects verbosely, displaying the server's greeting banner before closing, often combined with timeouts like -w 3 for efficiency across multiple ports (e.g., nc -v -w 3 host 20-30). This function leverages netcat's connection-handling to probe services minimally. Netcat integrates seamlessly with Unix , enhancing its utility for composite tasks like remote archiving. For example, to perform a network backup, the sender executes tar cf - /directory | nc host 1234, streaming the tar archive over the connection, while the receiver runs nc -l -p 1234 | tar xf - to extract it directly. This piping model supports compression or other preprocessing (e.g., via gzip), treating netcat as a for arbitrary data flows.

Diagnostic and Utility Extensions

Netcat provides several built-in options for network diagnostics, enabling users to perform tasks such as port scanning and without requiring additional software. One key feature is the zero-I/O mode, activated by the -z flag, which allows netcat to scan for open ports on a target host by attempting connections without sending any data, thereby minimizing network disturbance. For instance, the command nc -z host 1-1024 probes ports 1 through 1024 on the specified host, reporting only those that are listening, and can be combined with -v for verbose output including connection timings. This mode supports both TCP and UDP protocols when used with the -u option and is particularly useful for initial reconnaissance in network . In certain implementations, such as netcat-traditional, the -o option enables hexadecimal dumping of network traffic to a file, facilitating detailed protocol by capturing raw byte-level exchanged during sessions. For example, nc -o traffic.hex [example.com](/page/Example.com) 80 would connect to port 80 and log the hex representation of all incoming and outgoing packets to traffic.hex, aiding in malformed packets or custom protocol inspections. This feature is absent in some streamlined versions like OpenBSD's nc, where users may need external tools for similar functionality. Netcat also handles telnet protocol negotiation through the -t option, which automatically responds to RFC 854 DO and WILL requests with DON'T and WON'T messages, allowing seamless scripting of interactive sessions without manual intervention. Complementing this, the -n flag suppresses DNS resolution, forcing netcat to use numeric IP addresses directly and bypassing hostname lookups to reduce overhead and potential resolution delays in diagnostic runs. For example, nc -t -n 192.168.1.1 23 establishes a connection to the specified IP while handling negotiation and avoiding DNS queries. For basic tunneling, netcat supports simple by chaining instances to traffic between interfaces, creating lightweight proxies without dedicated software. A common setup involves one netcat process listening on a local and output to another connecting to the remote target, such as nc -l -p 8080 | nc remotehost 80 on the , which forwards incoming connections from 8080 to the remote 80. This approach leverages netcat's core connection capabilities to build ad-hoc tunnels for testing or bypassing restrictions.

Implementations

Original Unix Implementation

The original Unix implementation of netcat, developed by the anonymous programmer known as of Avian Research, was written in as a single source file named netcat.c, comprising approximately 1,850 lines of code. This compact codebase was designed for simplicity and portability, allowing it to function as a versatile backend tool for network data transfer on systems. Compilation requires a POSIX-compliant environment and standard Unix tools such as gcc or equivalent compilers, with no external dependencies beyond core system libraries like <sys/socket.h>, <netinet/in.h>, and <unistd.h>. The build process typically involves a simple make command, optionally with preprocessor defines (e.g., -DGAPING_SECURITY_HOLE to enable the -e option for program execution) passed via flags, ensuring broad compatibility across Unix variants without additional configuration. Key limitations of this implementation include exclusive support for IPv4 addresses, absence of any built-in encryption mechanisms, single-threaded operation relying on blocking I/O and the select() system call for handling connections, and fixed buffer sizes of 8 KB for input/output operations to manage data streams efficiently. These constraints reflect the tool's focus on core functionality rather than advanced features, prioritizing reliability in basic TCP and UDP networking tasks. The source code for version 1.10, the final official release, remains publicly available and archived at SourceForge under the project nc110, with the last update occurring in March 1996. This preservation ensures ongoing access for study and historical reference, underscoring netcat's enduring influence as a foundational networking utility.

Platform Ports and Variants

Netcat has been adapted to various non-Unix platforms through ports that leverage platform-specific APIs, such as the Winsock interface on Windows for handling TCP/IP connections. Early Windows ports emerged in the late 1990s, with Weld Pond releasing a Netcat version for Windows NT in 1998, compiled for Win32 to support networking tasks on Microsoft systems. These ports translated the original Unix socket programming to Winsock, enabling similar functionality like port scanning and data transfer on Windows environments. Later adaptations, such as Nmap's ncat introduced in 2009, built upon these by incorporating IPv6 and SSL support while maintaining compatibility with the Winsock API. Ports for legacy systems like were developed using compilers such as Open Watcom to create minimal implementations suitable for resource-constrained environments. The mTCP suite, updated in 2010, includes a Netcat component ported to DOS with Open Watcom 1.8, allowing TCP/IP operations on real-mode systems without requiring extensions. For embedded networking devices, third-party adaptations like IOScat provide Netcat-like TCP functions directly in , implemented as a scriptable to facilitate penetration testing and data relay on routers without native support for external binaries. On BSD-derived systems, Netcat is integrated into base installations, with including it since early versions and adding support around 2000 as part of broader protocol enhancements in FreeBSD 4.0. The FreeBSD nc utility supports IPv6 connections natively, enabling commands like nc -6 for address family specification. Similarly, macOS includes a built-in nc from the OpenBSD codebase in its base system, while Homebrew offers an additional netcat formula for users seeking the classic version with options like -e for program execution. Minor variants extend Netcat's core with targeted modifications, such as Cryptcat, released around 2001, which adds encryption to secure data streams over TCP or UDP connections using a shared password as the key. For mobile and embedded platforms, basic forks like those in on Android provide OpenBSD-derived Netcat via package managers, supporting lightweight networking tasks such as port listening without root access. These adaptations preserve Netcat's simplicity while accommodating platform constraints like limited memory or non-standard APIs.

Notable Reimplementations

GNU netcat is a reimplementation of the original netcat utility developed as part of the project to ensure portability and compatibility across various systems. It adds support for the -e option to execute programs upon connection, improved error handling for more robust operation, and is included by default in many distributions such as and . The netcat represents a significant rewrite integrated into the operating system starting in 2001, with version 1.89 appearing in 3.5. This version introduces native support, compatibility with Unix domain sockets and proxies, and tight integration with the PF packet filter for enhanced firewall capabilities. For security reasons, it deliberately omits the -e option to prevent its use in creating unauthorized backdoors. Ncat, developed by the Project, was released in 2009 as a modern reimplementation of netcat, emphasizing with the original syntax while extending functionality for contemporary networks. Key additions include built-in SSL/TLS encryption via the --ssl option, support for scripting to enable custom behaviors like advanced proxying and data transformation, and full compatibility. It is distributed as part of the security scanner suite and supports cross-platform use on , Windows, and macOS. Socat, authored by Gerhard Rieger and first released in 2001, serves as a more versatile superset of netcat rather than a direct clone, focusing on bidirectional data relay across diverse address types. It handles not only TCP and UDP but also Unix sockets, SSL, and raw IP protocols, with features like address option chaining for complex relaying scenarios that netcat cannot achieve natively. Often recommended as an advanced alternative, socat is widely used in scripting and automation for its flexibility in protocol bridging and encryption support.

Security Considerations

Known Vulnerabilities

The -e option in traditional netcat implementations enables the execution of arbitrary commands upon establishing a connection, facilitating remote execution if the tool is misconfigured or exposed on a network, such as in bind shell attacks where incoming connections trigger shell access. This feature has been widely recognized as a risk, allowing attackers to create persistent backdoors with minimal effort. Early versions of netcat, including the Windows port 1.1, contained a stack-based in the doexec.c function when using the -e option, enabling remote attackers to execute arbitrary via long command-line arguments; this was documented as CVE-2004-1317. maintainers applied patches to address potential s in input handling for netcat version 1.10, closing related bug reports. In variants like socat, a heap-based existed in the xioscan_readline function of xio-readline.c (versions 1.4.0.0 through 1.7.2.0 and 2.0.0-b1 through 2.0.0-b4), allowing local denial-of-service or potential execution when invoked with the READLINE address without the 'prompt' option; this was assigned CVE-2012-0219 and patched in later releases. Netcat's UDP mode lacks inherent rate limiting, making it susceptible to denial-of-service attacks if used to relay or listen for traffic, as it can consume resources without bounds on incoming packets. The OpenBSD reimplementation omitted the -e option for command execution to reduce the risk of inadvertent backdoor creation, prioritizing security in its base system utility.

Best Practices and Alternatives

When using netcat, it is advisable to avoid the -e option on untrusted networks, as it enables program execution upon connection, potentially allowing unauthorized access if exploited. Instead, integrate netcat with firewalls such as to restrict access to specific ports and IP addresses, ensuring that modes are only exposed to authorized sources. For instance, an iptables rule can limit incoming connections to a designated , mitigating risks from external probes. For protocol selection, prefer UDP with netcat for broadcast scenarios where speed is prioritized over guaranteed delivery, such as network discovery tasks, but opt for TCP when reliability is essential, as it ensures ordered and error-checked data transmission. Secure configurations include combining netcat with SSH tunneling to encrypt traffic; a common setup pipes netcat output through SSH for forwarding, as seen in rsync operations where nc relays data via an SSH proxy to the target host. Additionally, employ the -w timeout option to prevent indefinite hangs during stalled connections, specifying a duration in seconds to automatically close idle sessions. In modern deployments, plain netcat should be used with caution in production environments due to its lack of built-in encryption and authentication; consider isolated execution within containers or under SELinux policies for enhanced confinement. As secure alternatives, Ncat from the Nmap project extends netcat with TLS/SSL support for encrypted connections, using options like --ssl to secure data in transit without additional tools. Socat provides advanced multiplexing capabilities, supporting complex stream handling and native SSL/TLS via address types like OPENSSL, making it suitable for bidirectional relays with authentication. For file transfers, scp or rsync over SSH offer encrypted alternatives to netcat's unsecure piping, ensuring integrity and confidentiality through OpenSSH protocols.

References

  1. https://ps.uci.edu/~franklin/doc/netcat.html
  2. https://docs.oracle.com/cd/E86824_01/html/E54763/netcat-1.html
  3. https://www.giac.org/paper/gcih/512/netcat-friend/104820
  4. https://docs.oracle.com/cd/E26502_01/html/E29030/nc-1.html
  5. https://www.sciencedirect.com/science/article/pii/B9781597492577000017
  6. https://nmap.org/ncat/
  7. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/networking_guide/sec-managing_data_using_the_ncat_utility
  8. https://www.commandlinux.com/man-page/man1/nc.1.html
  9. https://seclists.org/bugtraq/1995/Oct/28
  10. https://www.giac.org/paper/gsec/436/netcat-tcp-ip-swiss-army-knife/101060
  11. https://netcat.sourceforge.net/
  12. https://man.openbsd.org/nc.1
  13. https://linux.die.net/man/1/nc
  14. https://www.cyberciti.biz/faq/linux-unix-copy-clone-hard-disk/
  15. https://www.linode.com/docs/guides/netcat/
  16. http://chousensha.github.io/blog/2014/05/31/network-tools-netcat
  17. https://www.ired.team/offensive-security/lateral-movement/simple-tcp-relaying-with-netcat
  18. https://unix.stackexchange.com/questions/293304/using-netcat-for-port-forwarding
  19. https://sourceforge.net/projects/nc110/
  20. https://forum.vcfed.org/index.php?threads/mtcp-updates.21334/
  21. https://www.giac.org/paper/gcih/9459/ioscat-port-netcats-tcp-functions-cisco-ios/110952
  22. https://formulae.brew.sh/formula/netcat
  23. https://cryptcat.sourceforge.io/
  24. https://repology.org/project/gnu-netcat/versions
  25. https://packages.debian.org/sid/netcat-openbsd
  26. https://nmap.org/changelog.html
  27. https://sources.debian.org/src/socat/1.7.3.2-2/doc/socat.1/
  28. https://sectools.org/tool/socat/
  29. https://serverfault.com/questions/246347/whats-the-difference-between-socat-and-netcat
  30. https://nvd.nist.gov/vuln/detail/CVE-2004-1317
  31. https://nvd.nist.gov/vuln/detail/CVE-2012-0219
  32. https://man.openbsd.org/nc
  33. https://cycle.io/learn/netcat-usage
  34. https://www.digitalocean.com/community/tutorials/how-to-use-netcat-to-establish-and-test-tcp-and-udp-connections
  35. https://www.redhat.com/en/blog/ncat-security
  36. https://linux.die.net/man/1/rsync
  37. https://serverfault.com/questions/423960/what-is-the-purpose-of-netcats-w-timeout-option-when-ssh-tunneling
  38. https://linux.die.net/man/1/socat
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.