The GC acted probabilistically, responding to only approximately 1.75% of eligible requests (526 out of 30,000 from three measurement IP addresses) and completely ignoring one of four measurement source IPs. Flow-cache exhaustion tests confirmed the probabilistic decision is made per-flow at cache insertion time: once the ~16,000-entry cache was filled, injections resumed on previously-ignored source ports, ruling out connection-tuple hashing as the selection mechanism.

Analysis of GreatFire.org's server logs (16.6M requests, 13K unique source IPs, March 18–19 2015) showed 67% of DDoS attack traffic originated from Taiwan and Hong Kong, while mainland China accounted for only 18 requests — confirming the GC weaponizes foreign browsers by intercepting traffic at China's network border, not domestic ones. The dominant attack vector (38% of requests) was pos.baidu.com (Baidu's ad network), meaning any user globally visiting a non-Baidu site that loads Baidu ad scripts became an unwitting DDoS participant without visiting any Chinese site directly.

§5, §7.1 policy

The Great Cannon (GC) operates as a distinct in-path system — not an extension of the GFW — capable of both injecting and suppressing traffic, enabling full man-in-the-middle capability against targeted IP addresses. Unlike the on-path GFW, the GC only examines the first data packet of each connection (avoiding TCP bytestream reassembly), targets specific destination IP addresses rather than all border traffic, and maintains a per-source-IP flow cache of approximately 16,000 entries to ignore already-processed connections.

§3, §3.1 detection

TLS/HTTPS provides complete protection against GC-style content injection: the GC can only replace unencrypted HTTP responses and cannot inject into TLS-encrypted streams. GitHub's universal TLS enforcement prevented the GC from selectively targeting GreatFire.org's repositories despite sustained attack — China had previously attempted to block GitHub entirely but reversed the block within two days due to domestic programmer backlash, leaving TLS as the effective barrier.

§6, §8, §9 defense

Both GFW and GC injected packets share a distinctive implementation side-channel: the IP TTL field progressively increments on successive packets injected into the same connection, paired with an incrementing TCP window size. Using this compound fingerprint, the authors identified GC activity in 8 months of Lawrence Berkeley National Laboratory enterprise border traces with only a single false-positive source IP, and used per-hop TTL probing to localize both the GFW and GC to the same network link on China Telecom (hop 12–13, 144.232.12.211→202.97.33.37) and China Unicom (hop 17–18, 219.158.101.61→219.158.101.49).

§3.1, §4, §6 detection

An internet-wide scan of 500k IP addresses from an in-country VPS vantage point found TCP establishment-interception injections on 43,479 addresses (8.7% of scanned), with over 70% concentrated in two Akamai ASes (AS16625 and AS20940). The injection pattern — triggered by the first packet sent to these addresses — is consistent with targeted blocking of domain-fronting proxies hosted on Akamai CDN.

2025-alaraj-iran-refraction §4.1.2 packet-injectionrst-injectionip-blocking

Iran's censorship of refraction-networking proxies (Conjure via Psiphon) is not monolithic: different ISPs independently deploy different techniques and timelines. Over 800 million logged Conjure connections from July 2023–February 2025 across 10+ Iranian ASes show TCI (AS58224, ~33% of traffic) uses packet injection, while MCCI/Hamrah-e Avval (AS197207, ~22%) applies IP-based blocking, and some ASes (Parsonline AS16322, Shatel AS31549) show no proxy blocking at all.

2025-alaraj-iran-refraction §4 rst-injectionip-blockingpacket-injectiondpi

136 Russian government domains (25.09% of 542 accessible ones) blocked access to all tested countries outside Russia, and a further 112 (20.66%) were accessible only from Russian and Kazakhstani vantage points. Geoblocking was implemented via heterogeneous, uncoordinated mechanisms—DNS timeouts, TCP timeouts, HTTP 403 Forbidden responses, and explicit blockpages—across different domains, indicating an ad hoc emergency response with no central policy.

2023-ramesh-network §4.2 ip-blockingdns-poisoningpacket-injection

Data center VPSes predominantly experienced TCP connection timeouts and resets—with the highest-blocking VPS censoring 96.8% of tested domains—while residential ISPs were substantially more likely to inject explicit blockpages citing Roskomnadzor's registry, confirming that blocking mechanism varies significantly by network tier even when blocking rates are similar.

2020-ramesh-decentralized §VI-B rst-injectionip-blockingpacket-injectionkeyword-filtering

Approximately 10% of respondents (n=23) held uncertain or incorrect beliefs about which actor was responsible for a given block, systematically conflating government censorship with geoblocking, paywalls, and platform-side restrictions. This misidentification cascaded into inappropriate tool selection and inaccurate risk assessment: users who could not distinguish state blocking from licensing restrictions could neither choose the right circumvention tool nor accurately gauge the legal jeopardy of accessing the content. Respondents specifically requested a pre-visit blocking-actor classification tool.

2017-gebhart-internet §5.2.3, §5.4.1, §6.2.1 ip-blockingpacket-injection

Users in Thailand relied on incident-driven tool selection—running a fresh Google search for a proxy or VPN each time they hit a block—which the paper identifies as a systematic vulnerability: the Thai Royal Police exploited this pattern after the 2014 coup by linking a phishing application to a government block page, harvesting email addresses and gaining application-level access to Facebook profile information. The paper further notes that orchestrated stricter censorship could drive users to a government-operated malicious tool.

2017-gebhart-internet §5.3.3, §6.2.2 ip-blockingpacket-injection