GoCat Part 3: Using It in Security Testing

Part 1 covered the raw pipe; part 2 added TLS, proxies, interactive mode, and multiple listeners. Part 3 is the security angle: scanning, binary protocols, and the honest boundary between "flexible network tool" and "dedicated scanner."

Examples illustrative; confirm flags with gocat --help. Only test systems you own or have explicit written authorization to test.

Port scanning#

GoCat can probe ports as part of its feature set. This is useful for a quick check inside a session or a lab, not for mapping a network.

# Scan a range on a host
gocat --scan 10.0.0.5 1-1024

A connect-based scan tells you a port accepted a TCP connection (or answered on UDP). It does not tell you the service, version, or whether the answer is a filter, a proxy, or the real daemon. For a single host in a lab, that is enough. For an engagement, reach for the right tool:

The pattern worth internalizing: scan with a scanner, interact with a network tool. GoCat's value in a test is the interaction step — connecting to a service you found and speaking to it by hand.

Reading binary protocols#

HTTP is text, so netcat-style interaction "just works." Real protocols are often binary: a length byte, a type byte, packed fields. Dump those to a terminal naively and you get unreadable garbage or a terminal knocked sideways by control bytes.

Hex output is the fix — render received bytes as hex so you can read structure:

gocat 10.0.0.5 9000 | gocat --hex

Or capture the raw stream and dissect it offline, which is usually the better habit:

gocat 10.0.0.5 9000 > /tmp/session.bin
xxd /tmp/session.bin | head

For binary services, "print it as hex and look for patterns" is how you reverse a protocol: send a known input, diff the byte responses, find the field that echoes your value. That is the same discipline as any protocol RE, and a pipe plus a hex view is a perfectly good starting instrument.

A realistic lab workflow#

Putting the whole series together on a host you control:

# 1. Connect to a service you already know is open
gocat 10.0.0.5 9000
 
# 2. If it is binary, capture and inspect
gocat 10.0.0.5 9000 > /tmp/session.bin
xxd /tmp/session.bin | head -40
 
# 3. For a service that expects TLS
gocat --tls 10.0.0.5 9443

Each step uses the tool for what it is good at: an interactive, pipe-able, TLS-capable connection to one endpoint.

Where GoCat stops#

Being honest about limits is more useful than a feature list:

• Not a scanner. No OS detection, no version DB, no scripting engine. Use Nmap for that.
• Not an exploitation framework. No payloads, no session management, no post-exploitation. It is a transport.
• Not encrypted-with-authentication by default. Enable TLS and verify certificates; an unverified TLS session protects against passive observers, not active impersonation.
• Not a substitute for authorization. The tool is neutral; the legality is entirely about permission.

Series wrap-up#

Three parts, one idea: a network tool should get out of the way. GoCat is a single Go binary that gives you the netcat pipe you know, plus the things 1999 netcat never had — native TLS, IPv6, proxying, multiple listeners, hex output — without the platform-by-platform flag roulette. Use it to talk to networks; use the specialist tools to map and exploit them.

Project, issues, and the full command reference: github.com/realibrahimsql/Gocat. Run gocat --help for your build — that is the authoritative flag list.