ByeByeVPN is a single static byebyevpn.exe that scores how detectable your own VPN endpoint looks to a TSPU-class DPI censor, for authorized operators hardening self-hosted tunnels.
| Tool | pwnnex/ByeByeVPN — client-side scanner that evaluates a VPN endpoint's detectability from an external, censor-like vantage point |
| Category | Network scanning and DPI fingerprinting (C++, GPL-3.0) |
| Primary Use | Auditing your own WireGuard/AmneziaWG/TLS-fronted nodes against the Russian OCR methodology and modern tunnel fingerprints before a censor does |
| Safe Use | For authorized assessment of infrastructure you own or administer — lab validation, pre-deployment hardening, and defensive research into DPI classification behavior |
| Telemetry Note | Every probe (TCP connects, UDP initiations, TLS ClientHellos, J3 probes) reaches the target and is visible in its logs and upstream DPI; the keyed WireGuard self-check additionally rotates the tested peer's endpoint on the server |
ByeByeVPN occupies a genuinely interesting niche in the network tooling landscape: it is a scanner that deliberately adopts the adversary's point of view. Given an IP or hostname, it runs the Russian OCR methodology (§5-10) plus what the README calls modern 2026 tunnel fingerprints against the target from an external vantage point — no VPN connection to the target is required. The output is a detection score, an identified stack, and a prediction of what a TSPU-class classifier would decide. Written in C++ and shipped as a single static byebyevpn.exe for Windows that also runs under Wine on Linux and macOS, it needs no administrator rights and carries no DLL dependencies, which keeps the scanning environment itself clean.
What makes the tool operationally credible is its preflight stage, step 1b, which checks whether the host running the scanner is itself compromised by tunnels or packet rewriters before any verdict is issued. If the route to the target leaves through a tunnel adapter — Wintun, WireGuard, TAP, sing-tun, or PPP — the scan is blocked with an UNRELIABLE label and exit code 5. The same refusal applies when a TCP connect to 192.0.2.1 (an RFC 5737 address routed nowhere) succeeds, which would mean a local stack accepting every SYN and faking every open port; when zapret (winws), GoodbyeDPI or clumsy is running and rewriting packets in flight; and when the target resolves to a fake-IP or CGNAT address. This is unusually disciplined design for a scanning tool, and it tells you the author has thought hard about measurement validity rather than just probe volume.
The pipeline itself is a numbered sequence of eight stages. After DNS resolution (A and AAAA, IPv4 preferred) comes the preflight, then GeoIP aggregation across five HTTPS-only providers in parallel — ASN and country flags, marked as reference only and never scored. Stage 3a is a TCP connect scan of 1-65535 ports by default (or 205 curated ports) with 500 threads and, notably, no SYN retransmission, so a closed port reads as refused rather than timeout — a deliberate choice that changes how middleboxes along the path are interpreted. A path check follows with ten connects to the first open port to measure loss and RTT, plus three random dynamic-range ports that must refuse, as an ack-all control against interception.
Stage 3b fingerprints the TCP stack via handshake distribution and SIO_TCP_INFO peer window and MSS values plus the closed-port reply — again reference only, with no OS guess attached. The UDP stage (4) probes the signature-less modern tunnels: WireGuard, AmneziaWG, and QUIC, with each reply validated against the protocol's actual response layout in src/scan/udp_validate.h. Version 2.6.0 added an AmneziaWG S1 deep-probe: a twelve-step junk-prefix size sweep on :51820 framed strictly as a response experiment that cannot confirm AWG or S1. Legacy probes for OpenVPN, IKEv2, L2TP, TUIC, plain-QUIC and DNS were removed in that version, on the reasoning that their fixed-port, fixed-header signatures are already trivially caught by any DPI, so probing for them cost scan time without adding detection value.
The UDP validation logic is where the README's engineering quality shows most clearly. A returning datagram is not treated as evidence of a protocol, because echo services, reflectors and generic middleboxes all answer. A WireGuard hit is accepted only on a valid MessageResponse — type 0x02, three reserved zero bytes, exactly 92 bytes — or a cookie reply (type 0x03, 64 bytes) whose receiver index matches the probe's sender index. Any verbatim echo of the scanner's own payload is discarded outright, a rule the author says was added after 92 bytes of unrelated 02 00 00 00 garbage scored IMMEDIATE BLOCK on a lab stand. Two agreeing replies are required before a signal counts, and real WireGuard/AmneziaWG servers that don't recognize the prober stay silent, reported as not measured.
The keyed WireGuard self-check is the tool's most defensible feature: an owner can verify their own node using byebyevpn scan <your-node> --wg-pubkey server.pub --wg-key peer.key (optionally --wg-psk and --wg-port). Because a WireGuard server silently drops initiations from unknown peers, the check needs the server public key and the private key of a configured peer, both from the operator's own configs. The response's mac1 is verified cryptographically, meaning only the holder of the server private key could have produced it — a tier-A wg-keyed signal worth -15. Key hygiene is handled seriously: keys are passed only as files (never argv for private material), never printed, and never written to JSON; the wg_self_check object holds only requested, ran and port. The README warns that the server will move that peer's endpoint to the scanning machine, so a spare peer should be used.
The TLS side is equally layered. Stage 5 fingerprints SSH, HTTP, TLS with SNI consistency, SOCKS5, CONNECT, Shadowsocks, queries crt.sh, and checks for proxy-header leaks. Stage 5b performs a dual uTLS probe — two ClientHellos per TLS port, one synthetic Chrome-style and one openssl-default — extracting JA4 and JA4S from the raw handshake bytes and classifying the server's stack against a backend table. Stage 6 fires the eight J3/TSPU active probes at every TLS-capable port: empty connect, GET / with a real Host header, CONNECT example.com:443, a plausible OpenSSH banner, 512 random bytes from RAND_bytes, a ClientHello with a random .invalid SNI, an absolute-URI proxy-style GET, and 0xFF × 128. Each ends in reply, FIN, RST, held-open silence, or no connect — but J3 counts are only read when a well-formed TLS or HTTP exchange succeeded on the same port as a control, and J3 is explicitly reference output that never moves the score and does not identify Reality, Vision, or any other protocol.
Stage 7 combines the SNITCH heuristic with traceroute (RTT vs GeoIP per methodology §10.1), ICMP hop-count, and a check for Microsoft SSTP. Stage 8 produces the verdict: a 0-100 score or explicit INCONCLUSIVE/UNRELIABLE states with reasons and blind spots listed. The labels are honest about their limits — CLEAN (85-100) means no named signature answered, not that the node is invisible, and the report enumerates what the probes cannot see: Reality with a working target, Shadowsocks AEAD/2022, WireGuard without the owner's keys, AmneziaWG, Trojan or VLESS behind a real site. Only four signals actually move the score, each documented with a passport in docs/SIGNALS.md: wg-family (-15) and wg-keyed (-15) among them. Stage-8 honesty like this — refusing to dress heuristics up as detection probabilities — is rare in this space.
For defenders and authorized assessors, the value proposition is straightforward: this is a pre-deployment audit instrument for people who run their own censorship-resistant infrastructure and want to know how a national-scale DPI deployment would classify it before deployment, not after. The telemetry implications cut both ways — every probe is visible to the target and to any DPI on the path, and the keyed self-check perturbs the peer's endpoint state on the server — so it belongs pointed at nodes you own. With 438 stars, a GPL-3.0 license, an active discussion thread at ntc.party, and documentation split across docs/SIGNALS.md, docs/WEB_OBSERVATIONS.md and localized READMEs in Russian, simplified Chinese and Farsi, pwnnex/ByeByeVPN reads as a serious, methodology-driven instrument rather than a weekend scanner, and the preflight self-check alone sets a standard other detection tools would do well to copy.
pwnnex/ByeByeVPN.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.