One Year of Research on the Geedge Leak

For nearly three decades, researchers have had almost no option but to infer how the Great Firewall works from outside it. They sent crafted packets, recording which were blocked and how, and working back to the equipment behind them. When internal files from Geedge Networks leaked, researchers for the first time had the source code, build packages and tickets of a commercial censorship vendor closely tied to the Great Firewall. The authors of the USENIX Security 2026 paper state that this is the first time the source code of commercial DPI (deep packet inspection, which analyses the content of each connection to decide whether to let it through) has leaked.¹ Researchers can now read the code first to find distinguishing traits, then go back to real networks to compare, instead of relying on black-box inference alone.

A year on, the matches found are narrower than some reporting has claimed. The measurements suggest that the leaked code, or a close derivative of it, is deployed on part of the Great Firewall's equipment. Other Great Firewall devices measured in the same way do not match it, no device matches the latest leaked version exactly in the TLS comparison, and for the other customer countries the results mostly stop at "potential" or "cannot confirm".^2,3,4 At the same time, these conclusions rest on evidence from both the source code and measurement, which makes them more solid than earlier work based on remote inference alone. It is written for readers who build circumvention tools, do measurement research or follow supply chains. Technical detail stops at the level of mechanisms, and the original papers cover the rest.

For readers without a technical background

In September 2025, internal files and source code leaked from Geedge Networks, a company that builds internet censorship systems for China and other countries. For the first time, researchers could read the code of censorship equipment directly instead of only inferring how it works from outside.

A research team built the software and compared it with real networks. Judging by the results, part of China's Great Firewall likely runs this code or a close version of it. The other devices do not match, and there is no public evidence of who built them. According to the leaked documents, Geedge also sold the system to Kazakhstan, Ethiopia, Pakistan and Myanmar, but in those countries measurements mostly stop at "possible" or "cannot confirm".

Circumvention tools and VPNs are a constant target: customers report which tools can still connect, and Geedge adjusts its blocking rules. The paper did not test Tor. InterSecLab's report states that at the time of the leak Geedge appeared to have no effective way to block WebTunnel (a way of connecting to Tor that disguises traffic as ordinary web browsing), and InterSecLab found no evidence of Geedge discovering or exploiting unknown vulnerabilities in Tor.

More than 90% of the sites in the leak that were measured as blocked do not appear on the two website lists researchers commonly measure with, so when a list-based measurement finds no blocking, that does not mean there is none.

Geedge's system relies heavily on open source software such as Linux and Kafka, and some of that code may have been used in breach of its licence terms. Open source licences do not restrict use, so the censorship system and circumvention tools such as Tor are both built on open source software.

ADLINK, a Taiwanese company, shipped a batch of hardware to Geedge between 2019 and early 2020. Geedge is still not on the US or EU sanctions lists we checked.

The anoni.net Docs site's What a Year of Research on the Geedge Leak Found covers this story for general readers, including what people who use circumvention tools, Tor or VPNs should know.

For background, see the anoni.net Docs site's Why networked freedom matters, What surveillance can actually do, What Is Tor? and VPN: risks and how to choose.

A Year of Research

In the year since the leak, joint investigations have read the documents to map Geedge's clients and deployments, while academics have read the source code and measured remotely, and the two produce different kinds of evidence.

The leaked files come from both Geedge and the MESA Lab. The MESA Lab (Massive and Effective Stream Analysis) belongs to the Institute of Information Engineering of the Chinese Academy of Sciences, and in GFW Report's description the two together are an important branch of the Great Firewall's R&D capacity. According to GFW Report, Geedge was founded in Hainan in 2018, with Fang Binxing, known as the "father of the Great Firewall", as its chief scientist. By the FOCI paper's count, the leak totals 572 GiB, comprising source code repositories, project management records, client deployment configurations and operational data, and more than 80% of it is an archive of an RPM package repository (RPM being a Linux software package format).⁵

Geedge deployment locations recorded in the leaked documents. Client countries are shown in the main colour: ① Kazakhstan (K18, K24), ② Ethiopia (E21), ③ Pakistan (P19), ④ Myanmar (M22). China is shown in a second shade, with dots for the provincial firewall projects: ⑤ Xinjiang (J24), ⑥ Fujian, ⑦ Jiangsu. The unidentified client A24 is not on the map.⁶

1. 2025-09-08The Globe and MailReporting from the joint investigation begins, three days before the files are made public
2. 2025-09-09InterSecLab, "The Internet Coup"Amnesty International's Shadows of Control and Justice For Myanmar's Silk Road of Surveillance come out the same month. The community has a Traditional Chinese translation
3. 2025-09-11Files made publicEnlace Hacktivista releases all the files, and DDoSecrets also makes them available for download
4. 2025-09-12GFW Report analysisLast updated on 29 December, noting that the source code part of the leak has not yet been carefully analysed
5. 2026
6. 2026-02-19FOCI 2026, "Geedge Cases"Researchers from the University of Massachusetts Amherst and GFW Report compare the domains in the leak with two widely used domain lists
7. 2026-04-24InterSecLab, "MADLink"The first instalment of a supply chain series, on the server and networking hardware Geedge uses, including hardware from ADLINK in Taiwan. The community has a Traditional Chinese translation
8. 2026-08-05geedge.report postThe USENIX paper's authors publish an explanatory post on their project site
9. 2026-08-12USENIX Security 2026 paper"Technical Analysis of the Geedge Networks Firewall Source Code Leak" is presented at the symposium (12 to 14 August), by authors from the University of Michigan, Paderborn University, the University of Massachusetts Amherst, the University of Colorado Boulder and GFW Report
10. 2026-08-21Risky BulletinReports the paper's results in more assertive terms than the paper (see the section on the gap between reporting and the paper's wording below)

The news reports came out three days before the files were made public. In the introduction to the USENIX paper, the authors write that several news organisations and journalists "who were granted early access have worked together for the past year to analyze the documents from a non-technical perspective".⁷ According to the acknowledgements in "The Internet Coup", the Tor Project was also a partner in this joint investigation.⁸ The joint investigation worked from documents and tickets, establishing Geedge's customers, the countries where it deployed and the features of its products. Before the USENIX paper, the source code itself had been left largely unexplored.^7,9 Academic research has followed a separate track: reading the source code, building the system and then running remote measurements.

From documents we can learn whom Geedge sold to and what its customers asked for, while measurement is used to judge whether a particular device behaves consistently with the code. Some reporting has applied conclusions of the first kind to the second (see the section on the gap between reporting and the paper's wording below for examples).

This review draws mainly on five papers and reports, which differ widely in scope and method. The table below can help in choosing which to read first (sources and links are in the references at the end).

Paper or report	Scope	Method	Suited to
"Technical Analysis of the Geedge Networks Firewall Source Code Leak", USENIX Security 2026	TSG's architecture and third-party code; how TSG compares with censors in the Great Firewall, Henan, Kazakhstan, Myanmar, Pakistan and Iran; ticket records of circumvention tool signatures being tuned	Reading the source code, building the latest tagged release and testing it in isolation, then comparing DNS, IP fragment, TCP, TLS and QUIC fingerprints from remote vantage points10,11	Researchers working on DPI fingerprinting, censorship measurement or circumvention tools
"Geedge Cases", FOCI 2026	Domains that appear in the leak, and how their coverage differs from Tranco and the Citizen Lab test lists	Extracting candidate domains from the leak, filtering by resolution, and testing DNS injection and TLS SNI blocking from vantage points in China, Pakistan, Myanmar and Algeria, 25 times per domain12	Researchers who maintain test lists or choose measurement targets
"The Internet Coup", InterSecLab, September 2025	Geedge's products, client countries and deployment modes, its ties to the MESA Lab, and its handling of circumvention tools	Reading the leaked documents and tickets, as part of a joint investigation with media and civil society organisations8	Readers interested in clients, deployments and human rights impact; a community Chinese translation is available
"MADLink", InterSecLab, April 2026	The sources and suppliers of three generations of TSG hardware, and ADLINK's shipments	Matching hardware records and MAC address vendor prefixes in the leaked documents, and putting questions to the vendor and Taiwan's Ministry of Economic Affairs13	Readers studying export controls and supply chains; a community Chinese translation is available
"Geedge & MESA Leak", GFW Report, September 2025	The composition of the leak, the background of Geedge and the MESA Lab, and a round-up of published investigations	Mapping the file structure and existing reporting, with advice on handling the files safely5	Researchers coming to the leaked material for the first time

TSG in the Source Code

The researchers built a working copy of TSG from the leaked source code and found it is made of separately developed components, with two of its three application detection systems built on third-party code.

Build and Testing

The USENIX paper analyses Geedge's flagship product, the Tiangou Secure Gateway (TSG), which the authors describe as "a full-stack censorship platform designed to fully integrate into national telecommunications controls". The leak contains more than 100,000 internal documents and over 500 Git repositories alone, covering more than five years of commit history, with the newest files dating from November 2024. Analysis is hard because TSG's logic is spread across many repositories and the same component exists in several branches and versions, and the authors found at least two fully separate IP, UDP and TCP protocol stacks (the part of the code that implements basic protocols such as IP and TCP).

The research team read the code following the four stages of DPI: receiving traffic, reassembly and parsing, rule matching, and interfering with connections. For the build, the team started from the latest tagged release, mapped it across several repositories and package archives, and bypassed the licence check.

Once the build was complete, the team tested its handling of DNS, HTTP, TLS and QUIC (a protocol carried over UDP and used by HTTP/3) in an isolated test environment, successfully triggering injected forged responses, packet drops and deferred blocking, and used the rule engine to define a custom blocking target.¹⁰ The authors do not say whether all three application detection systems (see Third-Party Code below) were running in this build, so this article only goes as far as saying that the team built and ran TSG's latest tagged release and tested its blocking of several protocols locally. The authors deliberately withhold the full build procedure, for reasons covered in the research ethics section below.

Core Components

TSG consists of several components that are developed and versioned separately. SAPP is the lowest-level packet processing platform, developed by the MESA Lab since 2005 through four major iterations, and written in C. SAPP assembles packets into TCP and UDP streams and hands them to plugins. It makes no blocking decisions itself and only provides the functions that blocking needs. Plugins come in three types: platform plugins provide shared functions, protocol plugins extract fields such as domain names from DNS queries and from TLS and QUIC handshakes, and business plugins use those fields to implement application logic such as blocking.

Stellar is a separate platform developed by Geedge in C++, with more complete connection state tracking than SAPP and richer ways for plugins to communicate. Stellar-on-SAPP is a SAPP platform plugin that converts SAPP streams into Stellar sessions for Stellar plugins to process, and it is explicitly identified in its README as a transition solution between the two platforms. In the leaked version, Stellar plugins run on SAPP through Stellar-on-SAPP. The standalone stellar repository appeared to be under active development at the time, was not referenced in any build repository, and had not been integrated into TSG.

Maat is the rule engine. Blocking rules are stored in Maat, and plugins match the fields they extract against those rules to get the action to take. Rules can match a wide range of fields, including transport and application protocols, the inner and outer addresses of tunnel encapsulation, source and destination IPs, ports, domain names and SNI (the site name sent in plaintext at the start of a TLS connection), ASN (autonomous system number) and country. The Firewall plugin is attached to both SAPP and Stellar, aggregates the fields extracted along each path, queries Maat and then enforces the block. Besides packet drops and RST (the TCP reset packet, which terminates the connection), blocking actions include throttling, HTTP and DNS redirects, mail and SIP blocking, tampering and deferred blocking.

The USENIX paper analyses TSG, the part that does the censoring. According to "The Internet Coup", Geedge also has management and analysis products that sit above TSG: Cyber Narrator is the surveillance interface that government analysts use, drawing on data from the TSG Galaxy surveillance data warehouse, and Network Zodiac monitors devices across the network.¹⁴ Neither paper analyses the code of this layer.

From management and analysis down to hardware, Geedge's system can be arranged in eight layers:^15,16,17

How TSG handles one connection can be simplified into the path below. In practice several processing paths run in parallel, and their results are combined in the Firewall plugin.¹⁸

1. 1Ingest and reassembly (SAPP)Receives traffic and assembles packets into TCP and UDP streams for the plugins
2. 2Field extraction (protocol plugins)Pulls domain names, the SNI and other fields from DNS queries and the TLS and QUIC handshakes
3. 3Application detectionDecides, with three systems, which app a flow belongs toCBD: Geedge's ownGlimpse: libprotoident, nDPIQDPI: Qosmos ixEngine
4. 4Rule matching (Firewall plugin and Maat)Combines the extracted fields and detection results and matches them against the blocking rules in Maat
5. ✓ActionAllows the connection, or drops it, sends RSTs, throttles, redirects, tampers with content or delays blocking

The authors draw two points from the architecture, and both bear on every comparison that follows. Because components are developed and versioned separately, fingerprinting one plugin remotely (a fingerprint being a trait that identifies a system or version) does not mean another plugin is present in the same deployment, and reveals nothing about that plugin's version. Blocking decisions are made only after the results of several processing paths are aggregated, so a connection can be blocked on the result of any one of them.¹⁸

Third-Party Code

TSG has three application detection systems, which determine which app or protocol a flow belongs to, and two of them are built on third-party code. CBD (Context-Based Detector, formerly AppSketch) is TSG's own system and works from signatures loaded through Maat. Glimpse's protocol classification core is libprotoident, free software from the Libtrace team at the University of Waikato, and all the code required for its classification function carries libprotoident's copyright notice. Glimpse's OpenVPN detection code, as the paper describes it, appears to be a modified copy of code from a 2022 version of nDPI (an LGPL-licensed DPI library, described in the paper as GPL)¹⁹, with the main function renamed and the logic nearly identical. The third system, QDPI, is built on Qosmos ixEngine, a proprietary commercial DPI library; the authors base this on the code calling ixEngine functions and including its header file.¹⁶

For libprotoident and nDPI, the paper's wording is that the code was copied and adapted. For Qosmos it says only that QDPI is built on it, and the authors make no judgement on whether Geedge had a licence. The team disclosed Geedge's use of this code to the libprotoident team and to Enea, the parent company of Qosmos. Both had responded by the time the paper was published and meetings had been scheduled, but what they said has not been made public. nDPI is not among the parties the paper lists as notified. In the authors' words, TSG's reliance on third-party libraries for two of its three detection systems "suggests that comprehensive protocol classification is costly to build from scratch, even for a well-resourced, state-linked vendor".²⁰ Findings like these depend on reading the source code, since remote measurement can hardly tell whose code a detection system uses.²¹

Comparison with the Great Firewall

The paper reports "high levels of correspondence" only for three Great Firewall devices (Injector 2, GFW II and GFW III). Other devices and Geedge's client countries mostly come out as no match or inconclusive.

Comparison Method

According to the USENIX paper, the Great Firewall was long thought to be highly centralised, but a growing body of evidence in recent years points to multiple DPI devices operating independently with different roles, and earlier measurement studies have named several of them.²² Devices doing DNS injection (a censor sending a forged DNS response before the real server can answer) are known as Injector 1, 2 and 3, names taken from "Triplet Censors" at FOCI 2020. Devices that send RSTs to terminate TCP connections are known as GFW I, II and III, alongside a separate regional censorship system in Henan province, names taken from "A Wall Behind A Wall" at IEEE S&P 2025.

From the source code, the team identified traits that can be measured remotely, such as idiosyncrasies in how protocols are parsed and a custom random number generator used to set packet fields. They then sent test packets between two hosts they own and compared whether censors in each location responded as TSG would. Measurements covered China's Great Firewall, Henan, Kazakhstan, Myanmar and Pakistan, with only DNS tested in Iran, across DNS, IP fragment reassembly, TCP, TLS and QUIC.

The comparison has four steps and a verdict, and every comparison rests on both the source code and measurements:¹¹

1. 1Source code analysisPicks out behaviour observable from a distance, such as fields in forged packets or idiosyncrasies in protocol parsing
2. 2Local verificationRuns TSG in an isolated testbed to confirm the behaviour actually occurs
3. 3Remote measurementSends test packets from vantage points in each location to hosts the team owns and records how censors respond
4. 4Behaviour comparisonChecks the measured responses against TSG's behaviour item by item
5. ✓VerdictEach comparison falls into one of the results in the matrix legendMatch, same as an older version, partial matchNo match, inconclusive

Censors can be connected to a network in two ways, and how much measurement can reveal depends on which one a device uses:²³

As the authors explain in the TLS section, a path may have more than one censorship device on it. A test packet that TSG lets through may still be blocked by another device, whereas a packet that TSG blocks is guaranteed to be blocked whenever it passes through TSG. Our inference is that when the blocking behaviour does not reveal its source, a measured "blocked" result could come from any device on the path and cannot on its own prove that TSG is there. Conversely, a result where TSG should block but the measured packet gets through rules out a TSG component with the same behaviour on that path.²⁴ Because the components are modular, one deployment might run the same version of SAPP with a different version of the SSL plugin, so each comparison speaks to only one component.

Geedge's clients appear in the leaked documents under code names: Kazakhstan is K18 and K24, Ethiopia E21, Pakistan P19, Myanmar M22 and Xinjiang J24, with one unidentified client, A24.²⁵ The table summarises the results for the five protocols, with the client code names from the leaked documents. The codes identify the clients on record, not that the devices measured belong to those projects. Great Firewall devices are listed under the names used in earlier research. The QUIC comparison does not separate Great Firewall devices, so it has its own row.²⁶

• Match
• Same as an older version of TSG
• Partial match
• Inconclusive
• No match
• Not measured, or no conclusion in the paper

DNS

the forged DNS responses a censor races back, compared on their flags, whether they use compression pointers, and the limit on following compression pointers when parsing a query

IP fragments

whether a censor reassembles an IP packet sent in several fragments before inspecting it, and how many fragments it will reassemble

TCP RST

the RST packets a censor forges to tear down a connection, compared on their header settings, how many are sent at once, and whether a constant seed can be worked back from the header fields

TLS

whether a censor still extracts the domain and blocks the connection when the length fields in the first TLS packet (the ClientHello) are tampered with

QUIC

which QUIC versions a censor supports, and how it handles fragment reassembly, the minimum packet size and length fields

Matches

China's Injector 2 is the only injector that matches all three DNS traits: the flag value in forged responses, the use of compression pointers in those responses (the way a DNS packet refers back to a domain name already written), and the limit on compression pointers when parsing queries. The authors write that these results "strongly suggest that TSG provides the GFW Injector 2's DNS injection implementation".²⁷

When TSG forges RST packets, it fills several header fields using a custom random number generator. From the packets sent by GFW II and GFW III, a fixed seed value (the generator's starting value) can be worked back, and it is TSG's default. The authors estimate the probability of a constant seed occurring by chance at about 10⁻⁴⁴, before even considering that the value equals TSG's default, and describe the result as "strongly indicating usage of TSG code".²⁸

The same section lists where both deviate from TSG. The RSTs sent by GFW II and GFW III both use a fixed TTL (the count of how many more routers a packet may pass through), whereas TSG's TTL varies with internal state. In measurements from December 2023, GFW II's TTL was still consistent with TSG, which the authors take as suggesting that GFW II has slightly changed its implementation since then. Earlier research recorded GFW II sending several identical RSTs in a row; when the team configured TSG to send the same number of RSTs in a row, the IPID (the identification field of an IP packet) changed between packets.²⁹

IP fragment reassembly produced a partial match: the maximum number of fragments GFW II reassembles at once is very close to TSG's. The authors are more cautious on this point, writing only that the result suggests "the two potentially share similar code".³⁰

The TLS tests altered each of the length fields in the ClientHello to see whether a device still parsed out the domain and blocked it. No device behaved exactly like the latest leaked version. GFW II's behaviour is equivalent to an older version of TSG's SSL module, which, the authors write, "suggests usage of this older version in GFW II's SSL parsing". For QUIC, the Great Firewall and Kazakhstan blocked the same test packets as TSG, but both support different QUIC versions from TSG, so they cannot be matched fully. Kazakhstan's parsing fingerprint does fully match an older version of TSG's QUIC parsing code.³¹

Section 6 of the paper sums up these results in one sentence: "Notably, we find high levels of correspondence with GFW DNS Injector 2 and TCP GFW II and GFW III, suggesting that the leaked TSG code (or a close derivative) is indeed deployed on part of China's national firewall."

The authors hedge the claim with "suggesting" and add emphasis with "indeed". The TLS match for GFW II and the QUIC match for Kazakhstan are with older TSG versions, the RSTs from GFW II and GFW III also deviate from TSG, and the geedge.report post likewise explains that the match changes over time and that the deployed code has drifted from the leaked version.²

Mismatches and Inconclusive Results

Injector 1 and Injector 3 do not match; in these measurements Injector 3 used different flags and no longer used compression pointers, unlike when it was first observed in 2020. For GFW I, Henan, Myanmar, and the device in Pakistan that sends RSTs, no fixed seed could be worked back. In the IP fragment comparison, several devices handle reassembly differently from TSG's default, and since the paper notes that reassembly is an option in TSG's configuration file, we class these as inconclusive.³

Myanmar's RST behaviour can be reproduced with TSG's settings, and its supported QUIC versions are exactly the same as TSG's. Its parsing fingerprint does not match, however, and the authors conclude that "we cannot confirm its use". Some devices in Kazakhstan and Pakistan block by dropping packets, which makes it impossible to tell whether a test packet got through, and the authors write that both countries "support potential TSG deployments". Kazakhstan's censors do not send RSTs, so no RST comparison was done there. Even with a QUIC parsing result that fully matches an older version, the authors still do not describe Kazakhstan as a confirmed deployment.⁴ Iran's DNS flags differ from TSG's, and Ethiopia appears only in the leaked documents, with no measurements.

The evidence that Geedge has customers in these countries comes from documents. The paper's background section cites civil society investigations listing deployments in Kazakhstan, Ethiopia, Pakistan and Myanmar, and the records the team found by searching Jira for "vpn" also mostly concern sites in Myanmar and Ethiopia.³² As far as the USENIX paper's measurements go, the only devices the paper describes as showing "high levels of correspondence" are some of China's.²

The Gap between Reporting and the Paper's Wording

In Risky Bulletin's report, TSG is "one of the Great Firewall's three known traffic filtering capabilities",³³ a phrase that appears nowhere in the paper.³⁴ The "three" may come from earlier research's classification of Great Firewall devices. DNS injectors are divided into three, and the paper finds a match for one. RST injectors are also divided into GFW I, II and III, and the paper matches two. The researcher's post quoted in the same report also states that Geedge is only one of the vendors involved in the Great Firewall.³³ The bold headline on the geedge.report home page reads "China's Great Firewall is running parts of TSG", which is more assertive than the paper, while the text under the same item uses "appears to be".³⁵

The paper's results support a narrower claim: part of the Great Firewall's equipment uses TSG or a close version of it, the other devices measured do not match TSG, and there is currently no public evidence of who supplied them. Nor do the authors say that Geedge developed the Great Firewall; the words they use are "ties", "affiliated", and a "close collaborative relationship" with the MESA Lab.³⁶ That is far narrower than claims equating Geedge with the Great Firewall, but it rests on evidence from both default values in the source code and remote measurement, which earlier research relying only on remote inference could not achieve.

Circumvention Tool Signatures and Blocking

TSG's signatures for circumvention tools are revised again and again in response to client reports, and tools without obvious traffic features, such as Psiphon, are blocked by server IP instead.

According to the USENIX paper, the leaked files show client-driven, iterative efforts to block specific circumvention tools, including Psiphon, Tor and popular VPNs such as ExpressVPN and NordVPN, with methods ranging from IP-based blocking to matching byte patterns. Signatures (rules describing the traffic traits of a given app) combine server IPs, domain names, TLS fingerprints, certificate fields, packet lengths and byte patterns. A Confluence document analysed in the paper records several updates to a signature bundle between March and November 2024, with signature risk levels between 3 and 5, most of them 5, while another test log aimed mainly at Chinese apps gives every signature a risk level of 1.³⁷ The specific signature conditions are in the paper's tables, and this article does not repeat them.

Tool	What the leak and the research show
Commercial VPNs (ExpressVPN, NordVPN and others)	Signatures combine server IPs, domain names, TLS fingerprints, certificate fields and byte patterns, revised in response to client reports.37 The leak also contains complete NordVPN server lists.38
Psiphon	According to internal documents, no obvious traffic features, so blocking moved to server IPs, with a whitelist to limit collateral blocking.39 The leak contains Psiphon's CDN domains.38
OpenVPN	The detection code appears to be taken from the open-source nDPI.16
Tor	Listed in the signature risk table. The USENIX paper neither describes the signature nor tests Tor connections.40
WebTunnel	A Tor pluggable transport that disguises traffic as ordinary HTTPS web browsing. At the time of the leak Geedge appeared to have no effective countermeasure, and MESA Lab students had done preliminary research on blocking it.41
Signal	One ticket records blocking failing once Signal's censorship circumvention option was enabled.37

Searching Jira for "vpn", the team found 700 tickets across 182 issues, covering reports of extracted server IPs, setting blocking priorities, repeated revisions after signatures stopped working, and over-blocking of other services. The authors' summary is that circumvention tool signatures are tuned with customer involvement: customers can report failures, set priorities and flag over-blocking.³⁷

In the Psiphon records, obfuscation (techniques that make traffic look unlike any known protocol) raised the cost of detection. According to an internal document analysing the collateral damage of blocking Psiphon, Psiphon traffic lacks obvious signatures, so identification switched to server IPs, combined with a "whitelist protection mechanism" to avoid misidentification. The risk of over-blocking when blocking by IP and SNI also comes up in another ticket. In their conclusion, the authors balance this against the opposite finding, that TSG "is capable of identifying circumvention tools at a relatively low cost", often matching very early in the connection.³⁹

The only material in the paper relating to TSG blocking Tor is the target list in the introduction and the signature risk level table, which includes an entry for Tor Browser.⁴⁰ The paper does not describe the content of the Tor Browser signature and did not test Tor connections, so it reveals nothing about how TSG identifies Tor, still less that it can block Tor. InterSecLab's "The Internet Coup", which works from documents, reports that "Geedge Networks appears to lack any effective countermeasures against WebTunnel at the time of the leak", and that students at the MESA Lab had done preliminary research on ways to block it. InterSecLab also states that it found no evidence of Geedge discovering or exploiting previously unknown vulnerabilities in Tor, and coordinated disclosure with the Tor Project.⁴¹

The FOCI paper adds evidence from the domain side. Several files in the leak specifically target VPNs and circumvention tools, including complete NordVPN server lists and Psiphon's CDN domains.³⁸ For developers of circumvention tools, server IPs and domains are themselves targets of collection and blocking, and traffic traits are only one of the methods.

The authors conclude that TSG's complexity and flexibility are "a double-edged sword": they make circumvention harder, but they also undermine code maintainability and correctness. The core components SAPP and its protocol plugins are written in memory-unsafe C, the system still relies on transitional solutions such as Stellar-on-SAPP, and code is copied from several third parties. The tickets include a case of an AppSketch database upgrade causing SAPP to restart, which the authors describe as part of a "patchwork" development process, and they see room for further study with fuzzing (feeding in large amounts of malformed input to find bugs) and symbolic execution (analysing a program's execution paths with symbolic rather than actual inputs). The paper reports no CVE numbers or specific exploitable vulnerabilities.⁴²

Domain List Coverage

More than nine in ten of the leaked domains that were measured as blocked appear in neither of the two lists researchers usually rely on, so measuring with those lists alone shows only part of what is censored.

Censorship measurement starts by deciding which domains to test, and two lists are commonly used. Tranco is a ranking of popular sites by traffic, while the Citizen Lab test lists are maintained manually by researchers and the community and organise sites likely to be blocked by content category. The FOCI paper extracted 14,365,453 candidate domains from the leak, leaving 6,915,266 after resolution filtering. Vantage points in Guangzhou and Nanjing tested DNS injection, which is more reliable. Vantage points in Pakistan, Myanmar and Algeria tested whether TLS handshakes were cut off because of the SNI, which is less reliable. Each domain was tested 25 times so that intermittent blocking was also counted. Kazakhstan and Ethiopia are known customers, but the team could not obtain suitable vantage points there.¹²

Of the leaked domains measured as blocked, 298,955 (93.7%) appear in neither Tranco nor the Citizen Lab lists. Conversely, the leak covers only 37.1% to 61.6% of the blocked Tranco domains. Each of the three lists has its own role. In the FOCI authors' words, "Tranco informs which globally popular sites are censored, CitizenLab monitors types of sensitive content over time, and the GNL [Geedge Networks leak] reveals which domains commercial vendors consider of interest".⁴³

The FOCI authors do not treat a domain's appearance in the leak as meaning it is blocked. Explicit blocklists are sensitive customer data and rare in the leak; the domains mostly come from internal documents discussing customer environments and represent content "of interest" to Geedge or its customers. The largest source is the MESA Lab's SNI datasets, which the authors judge "appear to be gathered from network taps" (a network tap is a device that copies traffic on a line). The leak also contains copies of ranking lists such as Alexa and SecRank, used for MESA research.⁴⁴ So the 93.7% reflects a gap in the common lists, and which domains are actually blocked still has to be confirmed by measurement, the same approach the USENIX paper takes in reading the code first and then going back to the network to compare.

The community-maintained Taiwan section of the Citizen Lab test lists (tw.csv in anoni-net/citizenlab-test-lists) is likewise a hand-curated list, reflecting what its maintainers consider important. In light of FOCI's results, when measurement with a list finds no blocking, the conclusion covers only the sites on the list; domains outside it were never within the scope of observation. How to read a single measurement is covered in OONI Blocking Verdicts, and how many measurements each network has in OONI Coverage.

Supply Chain and Policy

From the leaked documents, InterSecLab traced part of Geedge's hardware to ADLINK in Taiwan, yet Geedge does not appear on the US and EU sanctions lists we checked.

In "MADLink", InterSecLab followed the leaked documents to the hardware supply chain. ADLINK of Taiwan, through its Beijing branch, shipped 1,708 CSA-7400 units (a high-density network platform the vendor markets for firewall and DPI use) to Geedge between 2019 and early 2020. According to the report, they were the hardware basis of the first-generation TSG platform, and in the leaked documents this configuration was deployed only in Kazakhstan. Geedge's own EtherFabric (a network packet broker that distributes traffic among multiple TSG nodes) is deployed in Myanmar, and in the leaked documents the vendor prefix of its management interface's MAC address is registered to ADLINK. On that basis InterSecLab judges that it contains ADLINK components, most likely a management compute board.¹³

The leaked documents show three generations of TSG hardware, plus Geedge's own EtherFabric:¹⁵

Product	Hardware	Supplier	Deployed in
First generation, TSG-ADC	CSA-7400 high-density network platform	ADLINK (Taiwan)	Kazakhstan
Second generation, TSG-9140	ATCA-format telecom equipment, apparently based on the VELA ATCA platform	Beijing Hengguang Information Technology	Ethiopia (E21)
Current generation, TSG-X	Commodity x86 compute and storage servers	Nettrix (a Sugon subsidiary), Inspur	Ethiopia (E21), Pakistan (P19), Myanmar (M22)
EtherFabric	Apparently reuses the TSG-9140's VELA ATCA hardware, with some networking components possibly from ADLINK	Beijing Hengguang Information Technology, ADLINK	Myanmar (M22), a proof of concept for A24

In its reply to InterSecLab, ADLINK confirmed the number of units shipped, and said that it had screened against export control lists before shipping, that Geedge was not on any restricted list, and that it would begin an internal audit. According to ADLINK, it supplies only general-purpose hardware platforms and was not involved in software integration or system design related to end use. InterSecLab's rebuttal is that the leaked documents contain records of TSG-ADC load balancing depending on ADLINK's PacketManager software, and that the CSA-7400 itself is marketed as DPI and firewall equipment.⁴⁵ According to the Ministry of Economic Affairs, Taiwan's export control framework draws on international non-proliferation regimes and sanctions lists, and the ministry declined to comment on individual cases, citing legal restrictions.

The report argues that Geedge's current servers are mostly general-purpose x86 hardware that could still be obtained on the secondary market when regular procurement is blocked, and that purpose-built DPI and firewall equipment such as the CSA-7400 is where export controls can actually have an effect.⁴⁵ We have made a Traditional Chinese translation of the full report, and recorded Taiwan's public response to the MADLink report.

MADLink rests on documents and the vendor's replies, which can be set against the USENIX paper's three measurements in Kazakhstan: QUIC parsing matching an older version, TLS inconclusive because of packet drops, and no RST comparison possible. There is a time gap between the two. The CSA-7400 is first-generation hardware shipped between 2019 and early 2020, years before the paper's measurements, and whether the devices measured are still that batch of hardware cannot currently be determined.⁴⁶

According to MADLink, the servers in Geedge's current hardware come from Nettrix, whose parent company Sugon is already under US sanctions.⁴⁵ In a press release on 19 June 2024, Justice For Myanmar called on governments to sanction companies including Geedge Networks.⁴⁷ As of 30 October 2026, we had checked the sanctions lists of the US Treasury's OFAC and of the EU, and the Entity List notices in the US Federal Register, and found no listing of Geedge.⁴⁸

Open Source Software in the Censorship System

Open source software publishes its source code for anyone to use, and Geedge's censorship system relies on it heavily. The researchers, journalists and communities who exposed the system have worked in the open too.

Open Source Software in Geedge's System

Open source software makes its source code public and lets anyone use, modify and redistribute it; Linux and many networking tools are examples. According to MADLink, Geedge's entire software stack is built on open source foundations. The leaked documents also record that Geedge considered switching to Huawei's EulerOS but dropped the idea because the licensing fees were too high.¹⁷ The two reports and the USENIX paper mention seven open source projects:^49,16

Open source project	What it was made for	Use in Geedge's system
Rocky Linux	A Linux operating system	The TSG-OS operating system on the censorship equipment
DPDK	Letting ordinary servers process large volumes of network packets quickly	Processing the packets passing through the equipment without tying it to one vendor's network hardware
Apache Kafka	Handling large volumes of real-time data, often for retail and advertising analytics	The TSG Galaxy surveillance data warehouse
tcpdump	Capturing and recording network packets	Modified into tcpdump_mesa to extract application traffic fingerprints
Grafana	Dashboards for monitoring system status	Apparently the model for the Network Zodiac monitoring product
libprotoident	Identifying which protocol a flow belongs to, developed by a university team	The core of the Glimpse protocol detection system
nDPI	Identifying which application a flow belongs to	Glimpse's OpenVPN detection code, apparently a modified copy

As MADLink sees it, the software is open source and the servers are widely available general-purpose hardware, so both can still be obtained on secondary markets if regular procurement is blocked. The only place export controls can realistically bite is specialised hardware such as the CSA-7400.⁵⁰

Licences That Do Not Restrict Use

Open source software comes with licence terms that set conditions for use, modification and distribution. "The Internet Coup" reports that Geedge incorporates open source code in ways that may violate licensing terms, which it suggests helps Geedge match leading competitors faster while building resilience to sanctions.⁵¹ libprotoident and nDPI are both licensed under LGPL-3.0.¹⁹ Commercial products may use them, but distribution comes with conditions, such as publishing the source of a modified library. Neither the reports nor the papers reach a conclusion on whether Geedge met them.

Licence terms govern how software is distributed and modified, not what it is used for. Section 6 of the Open Source Initiative's Open Source Definition requires that a licence not restrict anyone from using the program in a specific field, and freedom 0 in the Free Software Foundation's definition is the freedom to run the program for any purpose.⁵² Vendors building censorship and surveillance systems can draw on the same code as anyone else. When "The Internet Coup" describes Tor and Psiphon, two of the tools being blocked, it calls both free and open source.⁵³ In our view, the same open source ecosystem supplies both the censors and those circumventing them, and that is one of the costs of openness.

Open Source Values in Practice

Over the year since the leak, the researchers, journalists and communities exposing Geedge have worked in the open:

Practice	Who	What they did
Circumvention tools are open source	Tor, Psiphon	Free, open source tools whose code users and researchers can inspect for themselves53
Learning about DPI from open source systems	The research community	Before this source code leaked, outside knowledge of how DPI works internally came, apart from measurement, mainly from open source systems such as Snort, Suricata, Zeek and nDPI54
Publishing research tools and results	The USENIX paper's team	Published its measurement results, anonymised packet captures and scripts on Zenodo,55 and built its test vectors by extending the open source tool Censor-Scanner54
Open licensing of papers	The FOCI paper's team	The paper is licensed under CC BY 4.056
Notifying open source maintainers	The USENIX paper's team	Notified the Libtrace team about Geedge's use of libprotoident code; the team responded and meetings have been scheduled20
Investigating with open source tools	InterSecLab	Used the open source tools Datashare and Apache Tika to process more than 100,000 leaked documents for partners in several countries to search54
Open licensing and translation	InterSecLab, the anoni.net community	InterSecLab's website is licensed under CC BY-NC-SA 4.0; the community translated "The Internet Coup" and "MADLink" into Chinese, and InterSecLab links to the translations from its report pages57
Open analysis and discussion	GFW Report	Published its analysis in Chinese and English, with later findings posted to the public net4people thread58
Publicly maintained test lists	Citizen Lab, the anoni.net community	The test lists are public on GitHub, and the community maintains the Taiwan list (see the section on domain list coverage above)

The USENIX paper's openness has limits: its measurement results and scripts are public, but the leaked source code and the team's build are not, on the grounds that the risk of censors benefiting outweighs the benefit to the community (see the next section).⁵⁵ We think what the community can do is keep exposing the use of open source software in censorship and surveillance, and keep circumvention and measurement tools open and easy to obtain.

Research Ethics and Data Handling

Neither research team publishes the raw leak, and the USENIX authors withhold the full method for building TSG, so what outsiders can reproduce is mainly the remote measurement.

The ethical considerations section of the USENIX paper identifies five groups of stakeholders: Geedge employees and shareholders, third-party companies whose code is integrated in TSG, the countries deploying TSG, users under censorship in those countries, and the anti-censorship community. The leaked Git repositories contain developers' names and email addresses. The authors handle this by focusing on the systems and architecture, not reporting on individuals, and not including source material from the leak in their public repository.⁵⁹

Running a local copy of TSG carries its own risk, since it could help deploying countries refine their systems or make deployment easier for other censors. The authors therefore chose not to publish how to set up the firewall, and the published material is limited to what is useful for identifying deployments. The team also considered not running it locally at all. They concluded that with a working copy, the anti-censorship community can fingerprint deployments in different places, develop and test circumvention strategies against a real system, and generalise those strategies to other countries' firewalls.⁵⁹

Measurements were run only between two hosts the team owns, with no third-party server as a target, and when renting vantage points the team checked that the providers were not on the EU sanctions list. Neither the leaked source code nor the team's build is published, and the authors have committed to sharing the build with trusted network security researchers on request. What is public on Zenodo is the measurement results, anonymised packet captures and the measurement scripts. As a result, other researchers can reproduce the remote measurements with the published scripts, while the source code side of the comparison can only be reproduced by researchers who are given access.⁶⁰

The FOCI authors take the position that the broad public interest of the information overrides potential intellectual property concerns, since the leaked data has already been made public by Enlace Hacktivista and DDoSecrets. The GFW Report analysis recommends analysing these files only in an isolated (virtual) machine without internet access.⁶¹

Lantern's geedge.lantern.io, an index of findings extracted from the leak, takes a different approach. Its page describes it as a sibling to corpus.lantern.io, meant to tell circumvention tool builders exactly what they are up against, but does not say who is behind it, and its relationship to the Lantern circumvention tool cannot be confirmed from the page.⁶² The index does not rehost raw leak content, and each finding comes with source information.

The findings in the index are extracted automatically by an LLM. According to the page, extraction is done by Sonnet-tier agents reading batches of extracted text, and the home page listed 880 findings when we read it. We sampled five, all marked at the highest confidence level. Three of them inferred that the system logs every connection from the field names of data tables alone, mostly citing test configuration files and giving no commit hash.⁶³ Lantern's index can serve as a starting point for finding leads, but anything taken from it should first be checked against the original material, and it cannot be treated as evidence on its own.

In the net4people discussion thread, the only sourced follow-up research after October 2025 is the FOCI paper. The rest is mostly commenters' own comparisons and speculation,⁶⁴ and some comments link to mirrors of the leaked internal systems, which this article does not cite.

This article holds to the same lines. It does not reproduce content from the leaked files, domain lists or file paths, does not give parameters, trait values or signature conditions that could be used to evade detection or improve blocking (the papers themselves publish some of these, and readers who want more can go to the originals), and does not mention the people who appear in the leaked data.

Open Questions

Who A24 is, who supplies the rest of the Great Firewall, and whether measurement can confirm the deployments in client countries all remain without public answers.

Injector 1, Injector 3 and GFW I all fail to match TSG. The paper's results point only to part of the Great Firewall's equipment using TSG or similar code, and there is no public evidence yet on who developed the rest.

In September 2025 InterSecLab wrote that the data on A24 contains no locations or ISPs that could identify it, and that the only clues are the first letter A and the year 2024, although the digits in a code name do not always mark a year. The relationship was at an early stage when the files leaked, with two proof-of-concept deployments of Geedge equipment, one in mirrored mode and one in-line. In April 2026, InterSecLab's "MADLink" still described A24 as an unknown customer known only by its code name, and added that Geedge's EtherFabric had also been installed there as a proof of concept. Neither paper, nor GFW Report, nor the net4people thread offers any further clue.⁶⁵

Kazakhstan, Pakistan, Myanmar and Ethiopia all have documentary evidence of a customer relationship, yet measurement stops at "potential" or "cannot confirm". The FOCI team could not obtain vantage points in Kazakhstan and Ethiopia, the USENIX paper had a vantage point in Kazakhstan but some results were inconclusive, and neither paper has measurements from Ethiopia. Deployments also keep changing. The leaked files stop at November 2024, and GFW II's TTL had changed between December 2023 and the paper's measurements,²⁹ so future measurements will need to account for version differences.

The team's build loaded only three SAPP protocol plugins, DNS, SSL and QUIC, and the AppSketch database archives are all encrypted. The authors found no code converting the signature formats into Maat rules and only inferred such a conversion from similarities between the formats, and the paper does not cover the rest of the source code. The authors hope the paper will "serve as a guide for future research on the leak". The FOCI authors list as future work searching the leak for IP addresses, analysing PDFs and other documents, improving OCR (optical character recognition), and comparing against domain data from Common Crawl and ICANN.⁶⁶

On the circumvention side, in the net4people thread tracking the leak (comments from October 2025 onwards), we saw no public statement from Tor, Psiphon or VPN providers on adjustments made in response to the leak.⁶⁴ The Tor Project had reviewed the Tor section of "The Internet Coup", and the Psiphon team the Psiphon section.⁸ With the leaked source code, researchers can now compare real censorship equipment against it; what comes next depends on whether vantage points can be extended to more customer countries, and on how tool developers use the results. You are welcome to join the discussion with us on Matrix.

References

• Technical Analysis of the Geedge Networks Firewall Source Code Leak: USENIX Security 2026, by the University of Michigan, Paderborn University, the University of Massachusetts Amherst, the University of Colorado Boulder and GFW Report
• Geedge Cases: Censorship Measurement Insights from the Geedge Networks Leak: FOCI 2026, by the University of Massachusetts Amherst and GFW Report, 2026-02-19
• geedge.report: the project site of the USENIX paper's authors, with the summary post Geedge firewall source code analysis published on 2026-08-05
• Geedge & MESA Leak: Analyzing the Great Firewall's Largest Document Leak: GFW Report, 2025-09-12, updated 2025-12-29
• The Internet Coup: InterSecLab, 2025-09-09
• MADLink: A Taiwanese Vestige in the Geedge Supply Chain: InterSecLab, 2026-04-24
• Pakistan: Shadows of Control: Amnesty International, 2025-09
• Silk Road of Surveillance: Justice For Myanmar, 2025-09
• JFM calls for action against Chinese and Myanmar companies involved in junta digital surveillance and censorship: Justice For Myanmar press release, 2024-06-19
• Leaked files show a Chinese company is exporting the Great Firewall's censorship technology: The Globe and Mail, 2025-09-08
• Academics find source code overlaps between Geedge and China's Great Firewall: Risky Bulletin, 2026-08-21
• geedge.lantern.io: Lantern's index of the leak, with findings extracted automatically by an LLM, usable only as leads

Related Reading

• The Internet Coup, Traditional Chinese translation: the community's translation of InterSecLab's "The Internet Coup"
• MADLink, Traditional Chinese translation: the community's translation of InterSecLab's "MADLink"
• OONI Blocking Verdicts: the gap between the verdict on a single measurement and a confirmed block
• OONI Coverage: which networks the measurements in Taiwan and nearby regions come from