tcpscan

stableUpdated 2026-04-18

A TCP SYN scanner with 6-type service fingerprinting that correctly distinguishes TLS from plain TCP services through ordered probe logic. Dual X.509 certificate extraction with library and raw DER fallback. 2-phase scanning architecture: SYN discovery followed by behavioral probing.

What it is

tcpscan is a network reconnaissance tool that operates in two phases. Phase 1 sends raw TCP SYN packets to target ports and identifies which are open by reading SYN-ACK responses. Phase 2 connects to each open port and runs an ordered sequence of probes (TCP banner, TLS banner, HTTP GET, generic probe) to classify the service into one of six types. The key insight is that TLS probes must be attempted before plain TCP probes for client-initiated services, because a TLS server is also a TCP server — probing TCP first would misclassify TLS services as plain TCP.

By the numbers

Metric	Value
Service types fingerprinted	6
Scanning phases	2 (SYN discovery + behavioral probing)
Certificate extraction	Dual strategy (cryptography library + raw DER OID fallback)
Port specification	Single, range, list, or mixed (e.g. `22,80-90,443`)
Response sanitization	Non-printable bytes replaced, capped at 1024 bytes
Timeout per probe	2 seconds

Architecture

Target + Ports
      |
      v
Phase 1: SYN Scan (Scapy, raw sockets)
      |
      +-- SYN-ACK (flags 0x12) --> Open port list
      +-- No response / RST ----> Skip
      |
      v
Phase 2: Fingerprinting (per open port)
      |
      +-- TCP connect + wait
      |     +-- Banner received -----> Type 1: TCP server-initiated
      |     +-- No banner -----------> TLS handshake
      |                                 +-- Success + banner --> Type 2: TLS server-initiated
      |                                 +-- Success, TLS GET --> Type 4: HTTPS (response) / Type 6: Generic TLS (none)
      |                                 +-- Failed, TCP GET ---> Type 3: HTTP (response) / Type 5: Generic TCP (none)

RST is sent after each SYN-ACK to clean up half-open connections. Raw socket access requires root.

Key features

Ordered probe logic — TLS handshake is attempted before plain TCP probes. If the handshake succeeds, only TLS-based probes are used from that point. If it fails, the service is TCP-only. Prevents misclassifying TLS services as plain TCP.
6-type service classification — TCP server-initiated (banner on connect), TLS server-initiated (banner on TLS), HTTP (GET over TCP), HTTPS (GET over TLS), Generic TCP, Generic TLS.
Dual X.509 certificate extraction — primary path parses DER-encoded certificates via the cryptography library and pulls the Common Name. Fallback path manually searches raw DER bytes for the CN OID sequence (0x55 0x04 0x03) when the library fails.
SYN scanning via Scapy — raw packet crafting, checks for flags 0x12 (SYN-ACK), sends RST to tear down half-open state.
Response sanitization — non-printable bytes replaced with . (matching tcpdump -A behavior) and output capped at 1024 bytes for clean console display.
Flexible port specification — single ports, ranges, comma-separated lists, or mixed (22,80-90,443).
Fresh connection per probe — try/finally cleanup, 2s timeouts throughout. Informational messages to stderr, results to stdout for scriptability.

What makes it stand out

Probe ordering as a first-class design decision — most naive scanners probe TCP first and mislabel HTTPS as HTTP. tcpscan flips the order and commits to the branch.
Dual-strategy certificate parsing — graceful degradation from a proper X.509 parser to raw DER byte-searching when the library can't handle the input.
Scriptable by default — stderr/stdout separation means results pipe cleanly into downstream tooling.

Stack

Layer	Technology
Language	Python 3.8+
Network	Scapy (SYN scanning), `socket` (TCP connections)
TLS	`ssl` module (handshake, cert retrieval)
Cryptography	`cryptography` (X.509 CN extraction)
Binary parsing	`struct` (DER OID fallback)