/qs-netcat

Primary LanguageGoMIT LicenseMIT



GitHub All Releases Build Issues Go Report Card Docker Pulls License: MIT

qs-netcat is a cross-platform networking utility which reads and writes E2E encrypted data across systems using the QSocket relay network (QSRN). It allows redirecting fully interactive PTY sessions with reverse connections, effectively allowing remote access to systems, forwarding traffic, and transferring files to and from systems under NAT networks or firewalls.

Warning

This tool is in its early alpha development stage, featuring experimental functionality that may lack backwards compatibility, and users are advised to exercise caution and not use it in production environments.

Caution

Due to the changes to the relay protocol, clients starting from version v0.0.8-beta will not be compatible with the older versions. You can still access your older instances using previous client versions (>= v.0.0.7-beta) until October 23, 2024. After October 23, 2024, legacy relay support will end, and all out-of-date QSocket instances will become inaccessible!

Installation

Open in Cloud Shell

Tool Build From Source Docker Image Binary Release
qs-netcat go install github.com/qsocket/qs-netcat@master Download Download

qs-netcat supports 10 architectures and 12 operating systems, following table contains detailed list of all Supported Platforms.

Supported Platforms
  • ✅ Supported
  • 🚧 In progress
  • ❌ Unsupported
ARCH/OS Linux MacOS Windows Android IOS FreeBSD OpenBSD NetBSD Solaris Illumos Dragonfly AIX
AMD64 ✅ ✅ ✅ ✅ 🚧 ✅ ✅ ✅ ✅ ✅ ✅ ❌
ARM64 ✅ ✅ ✅ ✅ 🚧 ✅ ✅ ❌ ❌ ❌ ❌ ❌
386 ✅ ❌ ✅ ✅ ❌ ✅ ✅ ✅ ❌ ❌ ❌ ❌
ARM32 ✅ ❌ ✅ ✅ ❌ ✅ ✅ ✅ ❌ ❌ ❌ ❌
RISCV64 🚧 ❌ ❌ ❌ ❌ 🚧 ❌ ❌ ❌ ❌ ❌ ❌
MIPS64 ✅ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌
MIPS32 ✅ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌
MIPSLE ✅ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌
PPC64 ✅ ❌ ❌ ❌ ❌ ❌ 🚧 ❌ ❌ ❌ ❌ 🚧
PPC64LE ✅ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌
S390X ✅ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌

Docker Install

Docker

docker pull qsocket/qsocket:latest
docker run -it qsocket -h

Usage

Usage: qs-netcat

Flags:
  -h, --help                 Show context-sensitive help.
  -s, --secret=STRING        Secret (e.g. password).
  -e, --exec=STRING          Execute command [e.g. "bash -il" or "cmd.exe"]
  -f, --forward=STRING       IP:PORT for traffic forwarding.
  -x, --socks=STRING         User socks proxy address for connecting QSRN.
      --cert-fp=STRING       Hex encoded TLS certificate fingerprint for validation.
  -n, --probe=5              Probe interval for connecting QSRN.
  -C, --plain                Disable all encryption.
      --e2e                  Use E2E encryption. (default:true)
  -i, --interactive          Execute with a PTY shell.
  -l, --listen               Server mode. (listen for connections)
  -g, --generate             Generate a Secret. (random)
  -K, --pin                  Enable certificate pinning on TLS connections.
  -q, --quiet                Quiet mode. (no stdout)
  -T, --tor                  Use TOR for connecting QSRN.
      --qr                   Generate a QR code with given stdin and print on the terminal.
  -v, --verbose              Verbose mode.
      --in-pipe=IN-PIPE
      --out-pipe=OUT-PIPE
      --version

Example to forward traffic from port 2222 to 192.168.6.7:22:
  $ qs-netcat -s MyCecret -f 2222:192.168.6.7:22
Example file transfer:
	$ qs-netcat -l -s MyCecret > warez.tar.gz         # Server
	$ qs-netcat -s MyCecret < warez.tar.gz            # Client
Example for a reverse shell:
	$ qs-netcat -s MyCecret -l -i                     # Server
	$ qs-netcat -s MyCecret -i                        # Client

Examples

  • Log in to Workstation A from Workstation B through any firewall/NAT
qs-netcat -l -i   # Workstation A
qs-netcat -i      # Workstation B
  • SSH from Workstation A to Workstation B by port forwarding through any firewall/NAT
qs-netcat -l                    # Workstation B
qs-netcat -f "22:localhost:22"  # Workstation A
ssh user@localhost              # Workstation A
  • Transfer files from Workstation B to Workstation A using smart pipes
qs-netcat -s MySecret -l > file.txt     # Workstation A
qs-netcat -s MySecret < file.txt        # Workstation B
  • Port forward. Access 192.168.6.7:80 on Workstation A's private LAN from Workstation B:
qs-netcat -l                  # Workstation A
qs-netcat -f 192.168.6.7:80   # Workstation B
  • Execute any command (nc -e style) on Workstation A
qs-netcat -l                         # Workstation A
qs-netcat -e "echo hello_world; id"  # Workstation B
  • Access entirety of Workstation A's private LAN (Sock4/4a/5 proxy)
qs-netcat -l                    # Workstation A
qs-netcat -f "22:localhost:22"  # Workstation B
ssh -D 9090 root@localhost      # Workstation B
# Access www.google.com via Workstation A's private LAN from your Workstation B:
curl --socks4a 127.1:9090 http://www.google.com
  • Mount a remote folder of Workstation A using sshfs and qs-netcat
qs-netcat -l                    # Workstation A
qs-netcat -f "22:localhost:22"  # Workstation B
sudo sshfs -o allow_other,default_permissions root@localhost:/remote_dir /mnt/local_dir # Workstation B

Crypto / Security Mumble Jumble

  • The connections are end-2-end encrypted. This means from User-2-User (and not just to the Relay Network). The Relay Network relays only (encrypted) data to and from the Users.
  • The QSocket uses SRP for ensuring perfect forward secrecy. This means that the session keys are always different, and recorded session traffic cannot be decrypted by the third parties even if the user secret is known.
  • The session key is 256 bit and ephemeral. It is freshly generated for every session and generated randomly (and is not based on the password).
  • A brute force attack against weak secrets requires a new TCP connection for every guess. But QSRN contains a strong load balancer which is limiting the consecutive connection attempts.
  • Do not use stupid passwords like 'password123'. Malice might pick the same (stupid) password by chance and connect. If in doubt use qs-netcat -g to generate a strong one. Alice's and Bob's password should at least be strong enough so that Malice can not guess it by chance while Alice is waiting for Bob to connect.
  • If Alice shares the same password with Bob and Charlie and either one of them connects then Alice can not tell if it is Bob or Charlie who connected.
  • Assume Alice shares the same password with Bob and Malice. When Alice stops listening for a connection then Malice could start to listen for the connection instead. Bob (when opening a new connection) can not tell if he is connecting to Alice or to Malice.
  • We did not invent SRP. It's a well-known protocol, and it is well-analyzed and trusted by the community.
qsocket-demo-final.mp4
RDP connection over QSRN
fin.mp4
ADB access over QSRN
android_adb_remoting.mov