README ΒΆ
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
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 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.
RDP connection over QSRN
https://github.com/qsocket/qs-netcat/assets/17179401/af46c8fb-cb33-483a-b5c1-9142843da2bd
Documentation ΒΆ
There is no documentation for this package.