Rook constructs per-field symbol tables by observing 600 packets (~60 seconds) of real gameplay at session start, then restricts substituted values to only those previously observed with frequency within two orders of magnitude of the median. This ensures altered packets never contain field values that are absent or anomalously rare in legitimate traffic, defeating value-anomaly and out-of-range DPI filters.

Rook achieves 34 bits/second client-to-server and 26 bits/second server-to-client within Team Fortress 2, sufficient for OTR-encrypted real-time chat. Rook use did not trigger Valve Anti-Cheat warnings and did not noticeably degrade gameplay for co-located legitimate players.

§4.1 defense

Kolmogorov-Smirnov two-sample tests on packet-size distributions and inter-packet timing show that standard Rook (altering ~1-in-10 packets) is statistically indistinguishable from normal TF2 gameplay across 20 samples each. High-bandwidth Rook (1-in-2 packets) shows a slightly higher average bandwidth but remains difficult to distinguish on traffic-shape metrics.

§4.3 Traffic Shape Analysis evaluation

Because Rook runs the actual game client and server rather than mimicking them, active anti-mimicry probes receive identical responses to a normal game instance. Systems based on protocol mimicry are vulnerable to probes that expose non-conforming behavior, but Rook eliminates this attack surface entirely.

§4.2 Anti-Mimicry defense

Game-specific trigram analysis of mutable fields distinguishes high-bandwidth Rook (1-in-2 substitution rate) in server-side packet counts, showing clearly reduced distinct-trigram counts versus baseline. Standard Rook (1-in-10) produces only a few outliers and is not reliably distinguishable; any detector would face a high false-negative or false-positive rate against normal-rate Rook.

§4.3 Game-Specific n-gram Analysis evaluation

State-of-the-art ML-based obfs4 detection (Wang et al. decision tree) achieves 97% precision at equal base rates (λ=1) but precision collapses to 3% at a still-conservative λ=1,000; at λ=10⁶ precision approaches zero for all classifiers tested. This base-rate failure was previously uncharacterized because prior evaluations only considered balanced or near-balanced datasets.

2024-wails-precisely §IV-D (Scalability), Figure 3, Table I ml-classifierrandom-payload-detectdpi

The GFW detects Shadowsocks by flagging apparently high-entropy connections that are not TLS or HTTP, but this detection is brittle: connections are explicitly allowed if the first 6 bytes of the first packet of a flow are all printable ASCII characters (range 0x20–0x7E). Adding a 6-byte alphanumeric preamble to the Shadowsocks message definition is sufficient to bypass this heuristic and requires only a short patch to the protocol specification file.

2023-wails-proteus §3.2 random-payload-detectfully-encrypted-detectdpi

The GFW's fully-encrypted detector (deployed Nov 2021) operates by exempting likely-benign traffic and blocking the rest. Five inferred exemption rules applied to the first TCP payload (pkt): Ex1 — popcount(pkt)/len(pkt) ≤ 3.4 or ≥ 4.6 (bits/byte); Ex2 — first 6+ bytes are printable ASCII [0x20–0x7e]; Ex3 — more than 50% of bytes are printable ASCII; Ex4 — more than 20 contiguous printable ASCII bytes; Ex5 — first bytes match TLS or HTTP fingerprint. Traffic failing all five exemptions is blocked. Experiments confirmed all rules still held as of February 2023.

2023-wu-fully-encrypted-detect §4, Algorithm 1 fully-encrypted-detectdpirandom-payload-detect

Current randomized-payload circumvention tools (obfs4/ScrambleSuit, SkypeMorph, VoIP-tunneling) rely on censors 'defaulting open' — treating unidentified traffic as innocuous. If censors instead block all traffic not explicitly recognizable as meaningful plaintext, these tools fail entirely. The paper notes anecdotal evidence this is already occurring, including blocking of some TLS 1.3 connections.

2021-kaptchuk-meteor §1 Introduction random-payload-detectfully-encrypted-detectdpi

The GFW's passive classifier uses two features of the first data packet to flag probable Shadowsocks traffic: (1) high Shannon entropy (per-byte entropy > ~7 bits strongly correlates with replay probability, which is nearly 4x higher at entropy 7.2 than at 3.0) and (2) packet length in the range 160–700 bytes with specific remainders mod 16. A single data packet after the TCP handshake is sufficient to trigger the downstream active-probing pipeline.

2020-alice-shadowsocks-detection §4.2 dpirandom-payload-detecttraffic-shape

Measured packet loss rates under GFW censorship (Feb–Apr 2017, client at Tsinghua University/CERNET): Tor with meek obfuscation suffers 4.4% average PLR; Shadowsocks (AES-256-CFB) suffers 0.77% PLR; native VPN (PPTP/L2TP) and OpenVPN both achieve ~0.21% PLR. For comparison, the same tools accessed from a US vantage point show PLR below 0.1%, confirming the excess loss is GFW-induced. The GFW's DPI and active probing techniques specifically target Tor and Shadowsocks protocol signatures.

2017-lu-accessing §4.3 dpiactive-probingrandom-payload-detect