socks

Overview ¶

Package socks decodes the SOCKS proxy protocol (SOCKS4 / SOCKS4a / SOCKS5, RFC 1928) — the proxy / pivot / exfil channel. A captured SOCKS exchange is a network-reconnaissance source: the **request reveals the proxied destination** (host or IP + port) a client is reaching through the proxy, which is exactly what matters when analysing a capture for data-exfiltration channels, malware command-and-control over a SOCKS proxy, or an attacker pivoting through a compromised host's proxy. It is an application-layer complement to the project's other capture decoders.

Wrap-vs-native judgement ¶

Native. SOCKS is a tiny fixed wire format — a version byte then a
command/atyp + address + port (no checksums, no length-prefixed
containers beyond the SOCKS5 domain octet). A byte-field read; stdlib
only (net for the IP formatting), no new go.mod dep.

Verifiable / no confidently-wrong output ¶

Implemented to RFC 1928 (SOCKS5) / the SOCKS4/4a spec. The SOCKS5
IPv4 / IPv6 request+reply and the SOCKS4 request were cross-checked
against scapy's SOCKS layer; the SOCKS5 **domain** address and the
SOCKS4 **reply** are hand-verified against the RFC because scapy's
layer is wrong for those two (it encodes the domain as DNS labels and
omits the SOCKS4-reply bound address — RFC 1928 §5 specifies a plain
1-octet-length + name with no NUL, and a SOCKS4 reply is 8 bytes).
Because a lone SOCKS5 message does not always distinguish a request
from a reply (both share cmd/rep + rsv + atyp + addr + port, and the
values 1-3 are valid as either a command or a reply code), the
unambiguous **destination address + port** is always surfaced, and the
leading byte is reported as a command when it can only be one, as a
reply when it can only be that, and with both readings noted when it
is genuinely ambiguous — never guessed.