China (Great Firewall)

A June 2024 internal MESA Team survey ('针对审查系统的科学研究及探测技术调研报告') catalogs the academic censorship-measurement toolkit (OONI, Augur, Satellite, Quack/Hyperquack, GFWatch, GFWeb, middlebox weaponization studies, traceroute-based middlebox localization, device fingerprinting) and separately reviews circumvention-tool countermeasures, explicitly naming Lantern alongside Psiphon, Tor Meek and Signal as tools using uTLS-style TLS ClientHello mimicry and domain-fronting.

An internal TSG operations/troubleshooting manual lays out TSG's full traffic pipeline (NIC -> mrzcpd/marsio capture driver -> sapp DPI engine -> firewall/proxy(KNI->TFE)/active-defense/WAN-NAT policy branches) and shows engineers using maat_redis_tool to pull the live Redis-synced blocking policy tables (TSG_SECURITY_COMPILE, TSG_OBJ_IP_ADDR, TSG_OBJ_APP_ID) and filter them by numeric policy/object ID to debug why a block rule isn't firing.

The internal 'MAAT网络流处理配置统一描述框架' engineering manual (v3.1.20, author 郑超, 2021) documents MAAT's Redis-synced rule-compilation framework and its RuleScan/Hyperscan-based pattern-matching engine (libmaatframe.so / librulescan), and records that RuleScan's fast-scan feature caused a production outage on 2019-03-19 and has been disabled ever since.

An internal TSG functional-requirements spec ('加密协议JG') defines device support for identifying and blocking ECH, ESNI and QUIC traffic via per-connection SNI/region-matching tables (e.g. DF_QUIC_REGION), plus a companion 'FD报文全流程感知' feature that both passively monitors and actively injects synthetic verification traffic end-to-end through the network path to compute a live per-rule 'CT率' (breakthrough/penetration rate) — the system self-measures how often its own QUIC/ESNI/ECH blocks fail to take effect, and separately throttles logging/blocking detail for rule IDs receiving unusually high hit counts (DF_ATTACK_PROTECTION, 'targeted attack detection').

An internal MESA Lab report (2021-06-25) documents a live test in which a second sapp instance ('sapp B') receives fully decrypted plaintext HTTP traffic via a Unix domain socket from a third-party TLS decryption platform, while sapp A separately captures raw ciphertext via the mrzcpd driver. 24 hours of the decrypted logs (319,569 HTTP records) show the top intercepted destinations are Facebook, Twitter, Google/YouTube and Instagram, with client IPs traced to residential China Telecom/Unicom/Mobile subscribers in Guangdong, Zhejiang and other provinces.

Raw structured DNS event logs (dated 2021-08-23) captured from what appears to be a GFW-adjacent DNS monitoring/injection pipeline use a schema purpose-built for DNS response forgery ('CHEAT_TYPE', 'CHEAT_RCODE', 'CHEAT_STRATEGY', 'CHEAT_RR', 'INJECTED_PKT_FILE' fields) alongside per-query geolocation; sampled records show lookups for facebook.com and tiktokv.com originating from residential China Telecom/Unicom/Mobile subscriber IPs in Guangdong, Zhejiang, Anhui and other provinces, resolving against both domestic and foreign (8.8.8.8, OpenDNS) resolvers.

A 2023 MESA Lab monthly report describes the 'TF' project's active-defense work: test cases for serial ('串联') HTTP hijack/tamper and parallel ('并联') DNS race-injection ('DNS抢答'), performance tuning that scaled active-defense capacity from 3 to 5 units, converting two existing TSG boxes to active-defense mode, and rewriting the active-defense flow-control logic to no longer depend on sapp.

A MESA Lab monthly report states that adjustments to a VPN-detection module accumulated over 10,000 Psiphon3 server IPs and delayed a Psiphon3 client's ability to get online by at least 3 minutes in the researchers' test environment, an earlier-stage data point consistent with the much larger-scale (~70-73K IP) 'vpn-thwarting'/CyberNarrator Psiphon-harvesting pipeline documented elsewhere in this corpus.

An internal design note for a 'Shadowsocks traffic parsing/restoration module' describes decrypting captured Shadowsocks payloads back to the original HTTP request/response, given a known pre-shared key (AES-256-CFB, MD5-derived key, IV embedded in the stream).

The same internal research note's second research point develops an ML-based detector for Geneva-style automated censorship-evasion traffic; simple flow-level features (flow size, max packet size, RST/SYN/FIN flag counts, forward init-window bytes, inter-arrival timing) achieve near-perfect (ROC-AUC ~1.00) classification of Geneva-generated evasion traffic against CICIDS2017 and MAWI backbone background traffic using decision trees, LightGBM, XGBoost and random forest, with abnormal flow size (~150 bytes vs. 1000-30000 bytes typical) identified as the single most discriminative feature.

An internal MESA Lab research note directly measures and compares China's ('CN') HTTP censorship middlebox against Russia, India and an unlabeled 'HZ' system, plus open-source Snort2/Snort3/Suricata: China is characterized as inspecting Host- and keyword-based triggers (example trigger given: a request containing the parameter 'q=ultrasurf') across ALL ports rather than just 80/443, responding with a triple RST or an extra RST+ACK; an 8-technique HTTP-request-mangling evasion comparison table credits China's middlebox as vulnerable only to request-line whitespace insertion and HTTP-version tampering, fewer categories than the other three systems tested.

MESA Lab group-meeting notes record parallel R&D on a whitelist-filtering module and a project to fingerprint cloud-hosted circumvention/proxy infrastructure at the IP-block (not single-IP) level, explicitly modeled on 2017/2019 academic 'Bulletproof-hosting IP block' research; the notes also mention local packet captures that found Psiphon IPs, the domain types/ratios Psiphon uses, and active-probing behavior with candidate detection countermeasures.

An internal experiment using BurpSuite as a MITM proxy tests injecting a forged QUIC ServerHello carrying a connection-close frame ahead of the real server response, to make the client abandon its QUIC handshake; the author separately proposes recording every site known to support QUIC and simply blocking plain TCP connections to those sites, on the theory that this indirectly forces QUIC off since a censor cannot otherwise tell in advance which TCP flow would have upgraded to QUIC.

A recurring Chinese-language daily '出入口整体流量监测报告' (Entry/Exit Overall Traffic Monitoring Report), sampled here from June 2022 through Feb 2024, tracks national-gateway-scale traffic (peak 1.1 Tbps, 5.62 PB/day in one instance; top apps by volume include Bytedance, Tencent, Kuaishou, Alibaba, Baidu). The 2024-01-16 instance explicitly discloses that of 34 total ingress/egress links (2.68 Tbps aggregate capacity), the monitoring system actually taps only 2 links (200 Gbps) — 7.46% of total link capacity — meaning the reported traffic figures reflect partial-link sampling, not full-link coverage.

A recurring weekly '[Xinjiang Unicom/Xinjiang Mobile] Traffic Analysis Report' (新疆联通/移动流量分析报告), produced by a 'Carrier Front-End Analysis Team' (运营商前端分析团队), spans Feb-Jul 2023 in this batch. It reports each carrier's total/access bandwidth (Xinjiang Unicom: 1.88 Tbps total, 880 Gbps access; Xinjiang Mobile: 4.4 Tbps total, 1 Tbps access) and per-app server-IP/location/traffic breakdowns for 31 named foreign platforms including Telegram, WhatsApp, Twitter, Facebook, Discord, Snapchat, Gmail and YouTube, alongside domestic-app sections — direct evidence of an ongoing, carrier-integrated domestic monitoring program for China's Xinjiang region.

A live tsg_master engine config file exposes a [RESET] section with concrete TCP-RST-injection parameters (NUM=1, SEED1=65535, SEED2=13, FLAGS=20, DIR=3, REMEDY=0), a [TRAFFIC_MIRROR] section confirming mirror-tap deployment (NIC_NAME="eth_vf_mirr"), a [MAAT] section wiring tsg_master directly to MAAT's subscriber-ID tables (TSG_OBJ_SUBSCRIBER_ID/TSG_DYN_SUBSCRIBER_IP), and a device tag "BeiJing-XXG" confirming this specific instance is a domestic Beijing deployment. A plaintext Kafka SASL credential (SASL_PASSWD="galaxy2019") is also exposed, and "galaxy" recurs as an internal project codename elsewhere in this batch (docker service path /home/galaxy, APP_BRIDGE_NAME).

TSG automatically generates recurring weekly "SNI Report of Overseas APP" and companion "Server IP and Location of Overseas APP" reports at what is almost certainly a China-national (not export-customer) scale — single weekly runs process from ~5.7 trillion to over 135 billion rows and up to ~775TB/week — breaking down QUIC.SNI/SSL.SNI/HTTP.Host traffic per named blocked-in-China platform (YouTube, Facebook, Google, Twitter, Instagram, Telegram, WhatsApp, Netflix, BBC, Viber, Line, Snapchat, Gmail, HBO, and more), down to individual CDN edge hostnames (e.g. specific scontent-*.fbcdn.net and rr*---sn-*.googlevideo.com nodes ranked by bytes). The report series recurs weekly from at least Feb 2023 through Mar 2024.

A dedicated internal "运营商前端分析团队" (Carrier Front-end Analysis Team) produces weekly, carrier-specific traffic-analysis reports explicitly titled "新疆移动流量分析报告" (Xinjiang Mobile Traffic Analysis Report) and "新疆联通流量分析报告" (Xinjiang Unicom Traffic Analysis Report), with instances dated from at least July 2022 through March 2024. One instance (Xinjiang Mobile, 2023-05-15) reports total carrier bandwidth of 4.4Tbps (1Tbps access bandwidth), 27.34PB of weekly throughput, 123 distinct identified application-layer protocols, and a section (4.1, pages 17+) explicitly tracking server IP/location for 28 named overseas apps (BBC, Discord, ESPN, Facebook, Gmail, Google, Hulu, Instagram, Netflix, Reddit, Skype, Telegram, Twitter, Uber, WhatsApp, Wikipedia, YouTube, Zoom, etc.).

The Xinjiang Mobile carrier traffic report (2023-05-15) states in its own QUIC-domain-ranking section that Xinjiang's intra-provincial traffic has begun carrying QUIC/HTTP3 (UDP-based) traffic that poses "a huge challenge" to the traditional parallel/out-of-band ("并联") traffic-access blocking method, and that effectively gatekeeping ("GK") UDP/QUIC traffic requires switching to an inline/in-path ("串联") blocking architecture — a direct internal admission that (as of mid-2023, in this province) the standard mirror-tap deployment could not reliably block QUIC.

An internal MESA Lab research survey, '规避工具探测调研' (Circumvention Tool Probing Survey), compiles academic active-probing techniques against Shadowsocks (Frolov, Beznazwy, Cheng/ACER), OpenVPN (Xue et al., USENIX'22 best paper -- RST-threshold fingerprinting), Tor bridges/pluggable transports (Ensafi, Tschantz, Dunna -- cataloguing the GFW's 5 known probe types: TLS/Tor/obfs2/obfs3/SoftEther), and mimicry proxies (StegoTorus fake-HTTP, CensorSpoofer fake-SIP), stating its purpose is 'to evaluate research value and feasibility of application in real projects' -- i.e. assessing which published GFW-active-probing research is worth operationalizing.

An internal module spec describes a proxy for authenticated/authorized users to reach overseas ('境外') services: it extracts the true destination domain from the TLS ClientHello SNI, resolves it via a normal public DNS resolver, forwards traffic (L4) to the real IP over a 'dedicated network,' rate-limits by client IP, and dynamically picks the lower-latency of two dedicated-network paths -- a 'VPN leased line' and a 'covert network' (隐蔽网络). Non-SNI TLS connections to the proxy are immediately closed (FIN), and the deployment does not yet support HTTP/3/QUIC.

An internal security-research presentation surveys published CDN-abuse techniques relevant to censorship evasion -- 'Domain Borrowing' (Black Hat Asia '21) and 'Domain Shadowing' (USENIX Security '21, explicitly labeled by the presenter as a 'new-type censorship-evasion technique,' 新型审查绕过技术) -- both exploiting CDNs' failure to verify accelerated-domain or origin ownership so that traffic with SNI==Host==a high-reputation domain reaches an attacker- or circumvention-controlled origin, and closes with concrete CDN-hardening recommendations (verify domain/origin ownership, set a distinct Host header on origin fetch, reject default-site requests with 403).

A 2018 MESA Lab monthly report describes work on the "GPS"/"先导" (Pioneer) active-probing projects: adding IPv6 scanning support and simultaneous 3-domain scanning to MAAT, alongside active-probing experiments (nslookup/dig/nmap) and root-DNS-server BGP-anycast measurement -- indicating MAAT's rule engine is paired with an active network-scanning subsystem, not purely passive/inline matching.

An internal 'MAAT Configuration Description Manual (String)' fully documents MAAT's rule-compilation model: per-field string matches (substring/prefix/suffix/exact/regex/AND-of-substrings/offset-anchored substrings) grouped into up to 8 AND/NOT clauses per compiled rule (conjunctive normal form), each carrying an action code (0=block, 1=monitor-only, 2=whitelist), blacklist and logging flags, and a floating-point execution-order field for safe rule reordering, plus the C scanning API (Maat_full_scan_string) and the file/JSON formats used to push rule updates to production.

A 2017 monthly report from an IIE CAS/MESA researcher mentions 'magellan,' noting that its 'Level 2' (二级) uses a plugin-mounting model similar to sapp's, while the author was writing a 'T2 plugin' and hand-crafting MAAT config files for unit testing -- indicating 'magellan' is a separate, plugin-based traffic-processing platform related to but distinct from sapp. Flagged as a new taxonomy candidate; not tagged with any existing product ID since none fits.

A 2020 MESA Lab monthly report describes building a sapp plugin that extracts packet-sequence features specifically "for DoH (DNS-over-HTTPS) service discovery," alongside a broader CSTNET DoH measurement-report effort and configuring a DNS-to-DoH gateway -- confirming sapp is used to fingerprint DoH traffic via statistical sequence features rather than plaintext DNS content.

MESA Lab researcher notes on an encrypted-video-identification project describe adding SSL-layer information output to more precisely trace a flow's true source/identity, and considering reinforcement learning so the identification model adapts as network conditions change, working within/around sapp's plugin limitations.

A MESA Lab monthly-report task list includes the next-step item 'design a scheme to identify forged/spoofed SNI in traffic' ([SNI判别]), alongside a separate active/passive traffic-fingerprinting project ('CAM-TEST') that extracts service banners passively and issues active host/port CGI GET probes.

A MESA Lab task tracker records the assignment "TSG: determine how many clients are behind an IP address," and a companion technical design document details the method: identify distinct TLS clients sharing one public IP using a <JA3 fingerprint, server domain, server IP> 3-tuple (JA3 alone collides across different apps), then use TLS Session Ticket reuse/lifetime sequences per identified client to detect multiple concurrent devices (i.e. NAT) behind that IP.

An internal schema doc describes an 'Unknown Protocol Identification Database': an Elasticsearch port-asset table tracking active/passive/fused protocol-type guesses and banner text per IP:port, feeding a MySQL clustering pipeline (cluster_info/cluster_task) that groups unclassified traffic by a 'fingerprint' field into named-protocol clusters -- an unsupervised discovery pipeline for identifying and naming new/unknown protocols at scale, distinct from MAAT/AppSketch's signature-matching against already-known protocols.

Internal MESA Lab reading notes dissect the USENIX 2024 paper on fingerprinting obfuscated proxies via encapsulated TLS handshakes, highlighting its protocol-agnostic packet-size-3-gram-plus-Mahalanobis-distance-over-bursts classifier, which the paper's own mid-size-ISP deployment reliably fingerprinted across shadowsocks, vmess, trojan, and vless-family configurations at false-positive rates the notes explicitly say the annotator estimates the GFW would find operationally acceptable (<0.6%). The notes flag the technique's main gaps as: no public source code, sharply reduced true-positive rate under connection multiplexing (10-30% vs. 60-80% unmultiplexed), and no evaluation against UDP/QUIC.

A MESA Lab graduation-project proposal specifies building a SAPP plugin that parses LTE GTP-C control-plane signaling to correlate each subscriber's identity to their session IP address in real time, then visualizes per-user traffic-behavior records and attempts to infer user interest/preference from the correlated data — a proposed SAPP-plugin implementation of carrier-level subscriber-to-IP correlation, distinct from the RADIUS-based correlation already documented for CyberNarrator's Pakistan deployment.

Internal MAAT engineering Q&A notes detail the rule engine's filter hierarchy: a 'region' config matches on keyword / regex / IP / extended-IP(CIDR) / numeric / file-digest / text-similarity / FQDN fields; regions roll up via AND/OR into 'group' configs; groups roll up into an 8-clause-max 'compile' config in conjunctive normal form. Rule config is pushed via a Redis single-primary/multi-replica tree, and MAAT itself is not distributed — each production front-end box runs its own single MAAT instance that receives pushed config and calls the shared rulescan library to execute the actual scan.

The same SAPP manual documents mrzcpd's inline (串联) packet-re-injection subcomponent mrtunnat, configured at /opt/mrzcpd/etc/mrtunnat.conf: use_recent_tunnel=1 allows it to inject a packet with no prior session record, and use_link_info_table=1 makes it validate outer MAC, link_id, link_dir, and inner MAC against a live link-state table at /run/mrzcpd/mrmonit.tunnat before re-injecting a censor-forged packet onto the correct physical link.

An internal SAPP platform training/reference manual (marked "Geedge Networks Confidential And Proprietary") gives SAPP's full name as "Stream Analyse Process Platform" and documents its three-tier plugin architecture (platform / protocol-parsing / business layers, each loaded via dlopen), inline and mirror deployment modes at a stated 10-40 Gbps per box, tunnel-protocol support (GRE/MPLS/IPIP/IPv6-over-IPv4/Teredo), and the MESA_kill_tcp() plugin API that forges and sends RST packets to sever a monitored TCP connection, with the manual noting it was "originally used in mirror mode to send RST packets to block a TCP connection" and auto-retries until the connection is confirmed dead.

An internal measurement-study report documents researchers live-testing the public DPYProxy TLS/SNI record-fragmentation tool against the GFW from inside China, against a control run from a German VPS. On a GFW IP-blocklisted Wikipedia IP, SNI fragmentation of any tested size (1/5/10/20 bytes) still ended in a server-side RST (though 1-5 byte fragments reached ServerHello before RST vs. 10-20 byte fragments RSTing right after ClientHello); on a non-blocklisted IP for the same domain, SNI fragmentation fully bypassed SNI-based blocking and returned a normal HTTP 200 response, matching the Germany baseline. The same report notes that testing Psiphon triggered roughly 5-10 minutes of residual censorship that also blocked other, unrelated circumvention tools from the same vantage point.

Post-defense revision instructions for the same encrypted-video-identification thesis (companion to the published LSTF/YouTube paper in this batch) show the review committee explicitly directing the candidate to delete the sponsoring project's name, weaken the chapters describing man-in-the-middle (MITM) traffic observation, replace all 8 instances of "中间人" (man-in-the-middle) with "代理" (proxy) throughout the dissertation, and downplay that YouTube specifically was the target by adding other video sites (Bilibili, Tencent Video, iQiyi) to the stated dataset description.

A weekly 涉诈APP (fraud-suspected app) disposition report for Nov 5 covers 20 apps (12 with overseas servers); alongside genuine scam-lottery domain clusters (玖富彩票) it lists mainstream, non-fraud consumer apps -- Shopee (major Southeast Asian e-commerce platform) and Trust Wallet (widely-used cryptocurrency wallet) -- each with extracted domains/IPs/API paths and a disposition of 系统处置情况：新增拦截处置 (newly added to blocking), showing the anti-fraud program blocks broadly-used legitimate commercial/financial apps under the same infrastructure and process used against actual scam operations.

A weekly operational report documents newly-added blocking rules for 25 mobile apps (18 hosted overseas, mostly on Hong Kong-region Azure/Alibaba/Tencent cloud IPs), where analysts extract each app's domains, IPs, and distinctive URL paths (e.g. '/tigase/getLastChatList', '/user/getUserMoney') and log 'system disposition: newly added blocking action' for every one; matching raw keyword-object exports using the identical URL-path style confirm these hand-extracted paths are loaded directly as live filter-list entries in production.

appsketch-works/app-test (and its fork app-test-fork) hold AppSketch signature definitions (signature.json/app.json/basic.json) for a broad app set spanning global platforms (TikTok, WeChat) and, notably, a Chinese provincial government app — 陕西社会保险 ("Shaanxi Social Insurance") — plus consumer apps (OPPO, Xiaomi, QQ, TIM, 义乌购/Yiwugou), showing AppSketch signature development covers domestic government/consumer apps, not only foreign circumvention-adjacent apps.

TSG's app-traffic classification relies on an updatable "App Sketch DB" component (uploaded as a versioned file to each deployment). A version bump at the Xinjiang Unicom province-exit + IDC site increased identified application-traffic share from 23% to 68% of total traffic within days, with ByteDance-attributed traffic alone rising from ~100TB/day to ~500TB/day identified, illustrating both the scale of traffic under classification and that classification itself is a frequently-updated, centrally-distributed database rather than a static build-time artifact.

appsketch-works/app-tiktok is a dedicated AppSketch Works repo containing a TikTok-specific app.json signature definition, directly corroborating the AppSketch "Feature Factory" product's per-app signature-authoring workflow documented elsewhere in the corpus, with TikTok confirmed as a named target app.

The AppSketch/MAAT signature system contains a systematically dated, patch-versioned catalog of FQDN-based detection signatures for dozens of individually named commercial VPN apps (e.g. V2VPN, V2Netvpn, Turbo VPN, LetsVPN, AdGuard VPN, Avira Phantom VPN, TouchVPN, FinchVPN, Opera VPN, Ultrasurf VPN, GoFly VPN), each modeled as an 'app' object in category 'networking' / subcategory 'tunnels' whose default deny_action drops the flow while sending both an ICMP-unreachable and a TCP RST to the client. At least 35 such distinct VPN-app signature objects appear in this batch alone, dated July-November 2024, with repeated 'Patch0N' revisions to the same app as its domains rotate.

A ~11,000-row categorized domain blocklist (CSV: domain, numeric category code, Chinese label) tags domains under content categories including 涉赌 (gambling-related) and 涉黄 (pornography-related), including combined multi-category rows (e.g. '涉黄;涉赌'), consistent with a keyword/content-category filter list feeding a DPI/domain-blocking rule table such as MAAT's.

TSG/CM ships with pre-built, first-class 'Learning Object' entries specifically for Freegate (Object ID 18) and Psiphon3 (Object ID 19), plus a generic 'Top Server IP' object (ID 20) -- default product features, not customer-commissioned custom signatures. The Psiphon3 object auto-learns and dynamically updates a live blocklist that reached roughly 70,000 IPs at one deployment before a database issue temporarily dropped it to ~50,000.

A MESA lab survey builds per-action (create/upload/download/share/delete/open) DNS/SNI/SSL-certificate fingerprint tables for six Chinese and enterprise cloud document-sharing platforms (Huawei WeLink, ByteDance Feishu, DingTalk's cloud drive, CAS's own "科技云盘", Shimo Docs, and WeCom), demonstrating the same systematic action-level DPI signature-extraction methodology documented elsewhere for VPN/app identification applied broadly across cloud productivity software.

A production ClickHouse query template for a TSG-family "connection_record_log" table reveals the deployed DPI collection schema: every base session record carries a subscriber-ID field alongside SSL SNI, HTTP domain/URL, client/server ASN, device ID, and internal/external/sled IP -- with subscriber ID used as the primary session identifier (falling back to client IP only when absent).

A 2024 MESA thesis proposal targets detecting "cross-border apps that illegally transmit personal information" inside encrypted traffic without decryption, by discovering app-specific tracking identifiers as <domain,parameter,value,interval> tuples and clustering flow structural similarity (Euclidean distance in a feature space) to separate device identifiers from background noise via a two-layer recognition model.

The cyber-narrator/cn-ui repo (the CyberNarrator/网络叙事者 frontend, 3123 commits across 21.08-24.11 tags) maintains dedicated deployment branches "dev-24.01-m22" (M22 = Myanmar per taxonomy) and "dev-xj-0111" (Xinjiang), confirming CyberNarrator is actively built and shipped per-deployment for both an export customer (Myanmar) and a domestic site (Xinjiang) as of 2024, and ships EN/RU/ZH localization plus per-country geojson map data (including kazakhstanLow.json, ethiopiaLow.json, myanmarLow.json) consistent with a multi-country tracking dashboard.

An internal UI-revision memo instructs changing the product's displayed name from 'NPM' to 'Cyber Narrator' and specifies an 'Entity explorer' with per-FQDN and per-IP detail pages (e.g. 'Entities/Entity explorer/Fqdn-qq.com', '.../IP-8.8.8.8'), split into 'server-side' and 'client-side' IP detail tabs, plus a planned DNS Dashboard -- confirming CyberNarrator's UI was originally built and marketed as a generic Network & Application Performance Monitoring (NPM) console before being rebranded, and detailing its entity-drilldown structure.

CyberNarrator's reporting-template repo (cyber-narrator/cn-reporter-template) generates recurring, branded per-provider and per-carrier traffic/QoS monitoring reports — including dedicated templates for ByteDance (字节跳动) and Alibaba (阿里巴巴) traffic specifically at "新疆联通" (Xinjiang Unicom) ingress/egress points, plus generic IDC domain and CDN-provider reports — showing CyberNarrator produces customer-facing traffic-monitoring deliverables tied to specific Chinese carriers and named application/service providers, a distinct third capability beyond the Psiphon3-harvesting and Pakistan subscriber-correlation uses already documented.

A weekly "新疆移动流量分析报告" (Xinjiang Mobile Traffic Analysis Report), authored by the "运营商前端分析团队" (Carrier Front-End Analysis Team), directly ties the SNI/Server-IP overseas- APP report format to the China Mobile Xinjiang branch specifically, and states the pipeline identifies 126 distinct application-layer protocols including multi-layer tunnel nesting such as STUN.DTLS and STUN.RTP.RTCP.DTLS — i.e. it decomposes and classifies nested WebRTC-style transport stacks, not just top-level TLS/QUIC.

Side-by-side internal performance comparison across Xinjiang (China Mobile carrier deployment, hostname cmcc-xj-server1-sapp-244), Fujian (domestic), and Ethiopia (E21) explicitly references the same 'app_sketch_maat' diagnostic log format at all three sites, confirming the identical AppSketch app-fingerprinting stack is used for domestic Xinjiang surveillance and for the exported Ethiopia deployment.

TSG's TLS ClientHello parser (MESA_Platform/ssl GitLab component) explicitly parses the ec_point_format extension from ClientHello, confirming deep TLS extension-level fingerprinting beyond simple SNI extraction.

A monthly report on an internal, formally structured "网络深度处理项目" (Deep Network Processing Project) lists two active work streams with front-end-integrated deliverables (experimental evaluation reports, technical summary reports, work summary reports, test cases): (1) tunnel/protocol identification for L2TP, PPTP, SSLVPN, IPSec, OpenVPN, plus separately Shadowsocks (SS) and Tor protocol identification; and (2) "加密流量破解" (encrypted-traffic cracking), covering MITM attacks against SSH/RDP/HTTPS connections and certificate public-key cracking spanning 9 distinct RSA and ECC cracking algorithms.

A system-design document specifies a "DNS diversion subsystem" built as a DNS53/DoH forwarder that filters queries against a configurable per-domain rule table and, on a match, rewrites the response to point at an operator-designated proxy IP -- with every resolution and rewrite event logged to a separate "reputation supervision subsystem" via dedicated Kafka topics, and an admin API for adding/querying which domains are configured for interception.

An internal MESA-authored analysis report, "域名请求实时分类校验和用户信誉计算分析报告" (Real-time Domain-Request Classification Verification and User Reputation Calculation Analysis Report), surveys academic domain-reputation/DGA/DNS-tunnel-detection literature and then proposes a production design combining real-time domain classification with a per-user "reputation score" built from static attributes (IP geolocation/ISP, OS/browser fingerprint) and dynamic behavior (DNS request patterns), explicitly framed as enabling finer-grained, per-user management/control policy rather than uniform per-domain blocking.

An exported keyword/domain filter-list object contains 48,874 rows of domain-blocking entries, with each domain listed twice as both an exact-match '$domain' pattern and a wildcard '*.domain' subdomain pattern, demonstrating the scale of a single production domain-blocklist object within the platform.

A 2024 CAS/IIE master's mid-term thesis report, "面向DPI中间件的探测行为识别关键技术研究" (Key Technologies for Identifying Probing Behavior Targeting DPI Middleboxes), builds and evaluates a system that detects and fingerprints active-measurement traffic from OONI, Censored Planet, and GFWatch/GFWeb (via their server-contact patterns, distinct-domain-count thresholds, and response-timing signatures — e.g. flagging a probing srcIP once it queries ≥500-2000 distinct domains at one dstIP), and separately trains a graph-neural-network classifier on raw packet bytes to detect Geneva/SymTCP-style automated censorship-evasion probes, explicitly framed as reducing the DPI middlebox's exposure of its own characteristics to circumvention researchers.

The durain/durain_doc deployment-documentation repo (2019-2020, flume-druid traffic pipeline for MESA's "durain" traffic-processing subsystem) includes a document titled "广东项目-流量统计状态-流量处理子系统-MESA.docx" ("Guangdong Project — traffic-statistics status — traffic-processing subsystem — MESA"), naming Guangdong province as a domestic deployment site in addition to the Xinjiang/Jiangsu/Fujian sites already documented in this corpus's taxonomy notes.

A 7,391-line IP-to-company mapping list for Zhangzhou, Fujian province (e.g. "漳州科能电器有限公司 :211.138.141.40") — a real-name registration table binding assigned static IPs on a regional ISP to specific registered businesses — confirms this deployment's data holdings include subscriber/ customer-identity correlation at the corporate-entity level for the Fujian domestic deployment named in the taxonomy notes.

sapp's own production config file (instance_name "sapp_v4.2") includes a commented-out example value for extract_linkdir_from_mac_in_mirror_mode explicitly labeled "for Xj example" (Xinjiang), directly tying this sapp instance's config template to a Xinjiang deployment at the source-config level; the file also documents inline/mirror/transparent deployment modes and packet re-injection options (sys_route, vxlan_by_inline_device, raw_ethernet_single/multi_gateway).

The same change document's post-deploy validation step explicitly checks that "spoofed packets and RST packets" are generated normally with no volume anomaly as routine production behavior, and the release separately adds a feature to retain full email body content (not just metadata) on business-user request, running on Kylin Linux Advanced Server V10.

An internal "business log loading interface" spec enumerates the platform's full censorship/surveillance taxonomy as three parallel log streams (管控/blocking, 监测/monitoring, and 一般/general) each covering the same roughly 13 categories -- IP blacklist, DNS spoofing, URL, website, specific-certificate, webpage-keyword, email-keyword, FTP-keyword, search-term, email, VPN, instant-messaging, and social-app -- fed via HTTP POST/Avro to a "front-end big data platform," with source/destination geolocation fields explicitly keyed to a carrier-supplied "疆外" (outside-Xinjiang) IP-location database.

A draft Chinese national standard (GB/T XXXXX-XXXX, "网络空间测绘数据交换 格式" / cyberspace-mapping data exchange format) formally defines "VPN服务" (VPN service) and "代理服务" (proxy service) as standardized service-type classification categories alongside SSH/Telnet/DNS/SIP/RTSP and others, indicating VPN/proxy identification is being institutionalized into a national interagency data-exchange schema rather than remaining a single vendor's proprietary classifier.

An "IDC阿里服务质量监测报告" (IDC-Alibaba service-quality monitoring report, dated 2022-09-28) generated by the same reporting pipeline lists "Freegate" — a well-known anti-censorship circumvention tool — as a distinctly tracked top-application bucket at 9.05%-31.85% of measured traffic share across different report dates, alongside ordinary entries like Sina, Tencent, and alicdn.com, showing Freegate usage is monitored as a named, quantified category at the IDC/backbone-link level, not just at edge appliances.

Multiple domestic IDC traffic-monitoring reports rank "Freegate" (a well-known GFW-circumvention tool) as a distinct, named top-10 application by traffic volume alongside Bytedance/Tencent/Alibaba/Baidu, with peak 18.92 Gbps and average 5.9 Gbps in one 2022-07-07 report -- confirming Freegate has its own dedicated app-ID classifier tracked at carrier-comparable traffic scale, not merely a low-volume/rare signature.

A domestic Fujian-province deployment was asked by the customer to parse and store call and SMS signaling data (via GTP-C) into the site's ClickHouse-backed OLAP store, extending the existing GTP-C signaling table structure. This domestic (mainland China) request is distinct from the Pakistan RADIUS-correlation deployment, indicating the underlying signaling-ingestion capability is deployed and requested across more than one customer context.

A flume-interceptor project explicitly built for a "Fujian GTP-C project" (福建gtpc项目) converts HTTP/Avro traffic into GTP-C (mobile-carrier control-plane protocol) format for production use ("线上flume拦截器配置" = online flume interceptor configuration), indicating the domestic Fujian TSG deployment ingests carrier signaling-plane data alongside conventional DPI traffic logs.

A MESA Lab thesis/report states that ESNI/ECH protocol-identification technology, based on TLS extension field type numbers, "has already been applied in actual projects," and lists the researcher's own project participation as "G1系统 - ESNI、ECH加密协议识别" (Feb-Aug 2023) and "G1系统 - QUIC协议旁路ZD" (Feb-Nov 2023, QUIC bypass/blocking), plus a separately implemented "DNS主动探测模块" (DNS active-probing module, marked 已实现/already implemented). "G1" also appears independently as a named legacy system in the Maat/Transformer DPI header (PROTO_VPN comment: "G1历史遗留"), corroborating it as a real internal system name, not a typo.

A Postman API collection titled '银河api' (Galaxy API) documents production query endpoints against the tsg_galaxy analytics backend, including dedicated 'radius日志标准查询' / 'raduis日志clickhouse查询' (RADIUS log queries) and 'Traffic Top Intercept Policies By Hits/Bandwidth' endpoints -- showing RADIUS-based subscriber correlation and interception-policy analytics are standard, generally-available query features of TSG's management API rather than a one-off built solely for the Pakistan deployment.

The same 'tsg_galaxy_v3.session_record' schema carries explicit TLS-interception status fields per session -- proxy_pinning_status, proxy_intercept_status, proxy_passthrough_reason, proxy_cert_verify, proxy_intercept_error, proxy_client_side_version, proxy_server_side_version -- confirming that certificate-pinning detection and MITM intercept/bypass outcomes (matching the 'certstore' product's Trusted/Untrusted/Dynamic-Bypass model) are logged at per-session analytics granularity across the whole platform, not just flagged transiently at the gateway.

TSG's central ClickHouse analytics schema ('tsg_galaxy_v3', deployed on cluster 'ck_cluster') defines a 'session_record' table where every logged session carries subscriber_id, imei, imsi, phone_number, and apn fields alongside client/server geolocation and ASN -- showing that per-session subscriber-identity correlation is a built-in, standard field of TSG's core traffic-log schema (used for ordinary session_record, not a bespoke table), not an add-on limited to the already-documented Pakistan CyberNarrator deployment.

A production TSG maat.conf shows the MAAT rule-matching engine running four parallel instances (STATIC, DYNAMIC, APP_SIGNATURE_MAAT, CAPTURE); the APP_SIGNATURE_MAAT instance is explicitly configured against app_sketch_tableinfo.conf / app_sketch_maat.json -- directly confirming MAAT is the execution engine underlying the AppSketch signature system -- and is tagged with an ACCEPT_TAGS datacenter value 'xjlhs', indicating this specific instance is scoped to a Xinjiang deployment.

Weekly Xinjiang Mobile carrier-side traffic analysis reports (2022-2023) state in plain internal language that HTTP/3 (QUIC-over-UDP) traffic 'poses a major challenge' to the traditional parallel/mirror (并联) traffic-access blocking method, and that UDP traffic requires an inline/serial (串联) blocking deployment to 'effectively' block it -- a direct admission that passive mirror-tap deployments (the apparent default) cannot reliably block QUIC-based traffic, only inline in-path deployments can.

The same MESA lab measurement catalogs which raw-HTTP-request perturbations bypass each censor's DPI middleware; against China's GFW, request-line whitespace insertion and HTTP-version-number corruption (triggering the origin server's HTTP/1.0 fallback) both succeeded, and were in fact the only two techniques (of eight tested) that bypassed all four measured censors (China, Russia, "HZ", India) simultaneously.

A MESA lab measurement of national censorship middleware (China, Russia, an unnamed "HZ" censor, and India) finds China's GFW performs both Host-header-based and keyword-based filtering across ALL ports, not just HTTP/HTTPS 80/443, and blocks matching connections with 3x injected RST packets or an additional RST,ACK -- a broader and more aggressive posture than the other three censors measured, none of which monitor all ports.

A hands-on MESA lab experiment testing TLS-record/TCP fragmentation (via the DPYProxy tool, replicating the public "Circumventing the GFW with TLS Record Fragmentation" technique) against live GFW found SNI fragmentation reliably bypasses GFW's SNI-based blocking of a non-blocklisted wikipedia.org IP, but has zero effect on GFW's separate IP blocklist: for an already-blocklisted IP, every fragment size tested still failed, with GFW tearing down the connection via <RST,ACK> immediately after ClientHello for larger fragments, or after the server's Hello for very small (1-5 byte) fragments.

An internal thesis/project spec assigns development of SAPP-platform plugins to parse the GTP-C signaling protocol (LTE S11 interface), extract session TEID plus subscriber IMSI/MSISDN/IMEI/TMSI, and build a real-time ID-IP correlation mapping between the mobile signaling plane and data plane, explicitly to support multi-dimensional behavioral, location/trajectory, and interest-preference analysis of individual or grouped mobile subscribers -- to be delivered as working SAPP plugins plus a thesis and short paper.

Two exported IP/CIDR filter-list objects (762 and 5,631 rows respectively, each spanning all ports 0-65535) consist almost entirely of recognizable DigitalOcean (138.68.x, 143.198.x, 159.89.x, 164.90.x, 188.226.128.0/17, etc.) and OVH SAS (51.15.x, 51.83.x, 54.36.x) cloud-hosting CIDR ranges respectively, indicating the platform blocks entire commercial VPS/cloud-hosting provider address space wholesale rather than only individually-identified circumvention-server IPs.

TSG ships a built-in offensive "active defense" (主动防御) module named houyi (后羿), built on the sapp/marsio/mrzcpd stack, that performs spoofed-source-IP network-layer flood attacks, DNS/NTP/Memcached reflection-amplification attacks, and application-layer (HTTP/HTTPS) CC floods against a configured target. Spoofed source IPs are drawn from named CIDR-range "profiles" (e.g. 10.1.1.0/24), and policy is distributed via Redis and issued either through an interface called "安天" (Antiy) or by directly calling a "毕方" (Bifang) API. Deployment is via Ansible from git.mesalab.cn/tsg/houyi-deploy, packaged as RPMs installed under /opt/houyi and as sapp plugins under /home/mesasoft/sapp_run/plug.

Recurring named '出入口服务提供商监测报告' (egress/ingress service-provider monitoring reports) track link-level bandwidth and quality specifically for Alibaba, Bytedance, and Tencent as the domestic cloud/CDN 'egress service providers' whose cross-border links the platform monitors, at aggregate scales of roughly 1.2-2.7 Tbps across 22-34 links per provider, produced on a recurring (weekly-to-monthly) cadence from mid-2022 through at least early 2024.

At least 33 additional recurring reports in this batch ("IDC阿里服务质量监测报告" / IDC Alibaba Service-Quality Monitoring Report, "IDC字节跳动服务质量监测报告" / IDC ByteDance Service-Quality Monitoring Report, and "IDC整体流量监测报告" / IDC Overall Traffic Monitoring Report, plus further variant-named "出入口" ingress/egress reports not individually cited here) span 2022-06 through 2024-02 and show monitoring deployed inline/mirrored at major domestic hyperscaler IDC interconnects — 10 to 22 links, 1 to 1.21 Tbps of aggregate bandwidth — for both Alibaba and ByteDance specifically, indicating the deployment footprint extends beyond telecom carriers (Xinjiang Mobile/Unicom) to major domestic cloud/CDN providers' peering links.

TSG's FQDN-based blocklist matching handles Internationalized Domain Names (Punycode/'xn--' prefixed non-ASCII domains), including automatic transcoding between Unicode and Punycode forms during policy sync between deployment sites -- confirmed via a bug where inconsistent validation of Unicode-vs-Punycode-entered domains broke policy sync between two Fujian sites.

A MESA lab thesis proposal for an "IPv6 user reputation" system explicitly includes circumvention-tool usage (frequency of VPN, Tor, and proxy use) as a first-tier risk-behavior indicator in its scoring rubric -- alongside categorized "harmful site" visit indicators (porn/infringement/terrorism/gambling/arms/drugs) -- and states the author has already built an IP-reputation model and knowledge base for a named national security project.

A "精管流量初步分析报告" (2021-07-26) documents a live paired-sapp TLS-interception testbed: sapp instance A captures raw ciphertext via mrzcpd/PAG while sapp instance B ingests plaintext from a third-party decryption platform over a Unix domain socket. The report measures decryption latency (mean 1.82ms), completeness (only 44% of connections flagged decryptable via an SSL/TLS ClientHello-based "user legitimacy" check were actually decrypted, and 88% of eligible users), and confirms RST-based blocking triggered from the decrypted side reaches the client in a median ~0.5ms and successfully blocked live access to Facebook, Wikipedia, Twitter, the New York Times, and Google (BBC was the one tested site that evaded blocking). The decrypted side also resolves each session to a persistent per-user ID via the ciphertext side's four-tuple lookup.

A ~6,000-line undifferentiated URL classification/whitelist dataset in the leak includes the URL 'https://raw.githubusercontent.com/getlantern/lantern' placed directly adjacent to known GFW-circumvention and Google-mirror sites (pac.itzmx.com, www.guge.xxx, g.alexyang.me, www.meiguge.com), suggesting Lantern's own GitHub source repository is catalogued within a circumvention-tools/mirror-site cluster of this URL database rather than filed as an ordinary developer/tech reference.

A September 2023 IIE/CAS-authored test report for a "流量汇接处理子系统" (Traffic Aggregation Processing Subsystem, built on the sapp/durain_master_maat stack) confirms the system is architected to ingest and process a combined 27Gbps of raw traffic from two aggregation points simultaneously: a general "互联网汇聚口" (Internet aggregation port) and a "政务外网汇聚口" (Government Extranet aggregation port) — i.e. the same DPI processing pipeline documented for public-internet censorship is also deployed against China's internal government-network traffic.

The same traffic-aggregation-subsystem test report documents two function points beyond blocking/filtering: "通联关系获取" (real-time contact/communication-relationship acquisition, verified via a live Grafana log of contact data) and "特定目标获取" (specific-target acquisition), the latter implemented as a per-IP watchlist config file (IP_PORT.json) under the sapp instance's durain_master_maat directory that the platform auto-loads at startup to flag and tag traffic to/from specified target IPs.

An internal Q&A on the MAAT rule engine's C API confirms sapp is MAAT's calling business system (maintained by a separate team from MAAT/rulescan), that MAAT's incremental-rule loading works by watching a config directory for the highest-indexed new file (with a separate "config line" pipeline compiling user-facing JSON rules into MAAT's matchable binary format), and specifies deployment hardware requirements for a single MAAT node: CentOS 7, 256GB+ RAM, 2TB+ disk, 48-logical-core Intel Xeon E5.

Internal MAAT engineering specification (v3.1.20, MESA Lab, revision history spanning 2014-2021) documents the config schema underlying sapp's rule-matching engine: per-rule action types (0=block/阻断, 1=monitor/监测, 2=whitelist/白名单), string/regex/IP/numeric/digest match types, and a geographic+ISP "tag" targeting system that lets the identical rule set be selectively activated per city district and carrier (e.g. Beijing/Chaoyang + China Telecom vs. Shanghai/Pudong), enabling narrowly-scoped rule rollout/testing before wider deployment.

The Transformer_master.h header (part of the Maat/sapp DPI framework, dated 2023-05-04) defines a region-keyed DNS response-forgery subsystem (MSG_OPT_DNS_CHEAT_TYPE/RCODE/STRATEGY/RECORD/TTL, DNS_FAKE_INFO/DNS_FAKE_IP tables, TF_get_dns_response_strategy_id(user_region)) used specifically by the block ("FD") action path, plus a dedicated function to classify whether a detected L7 protocol is a VPN (TF_is_L7_vpn_prot), and native extraction of TLS JA3/JA3S client and server fingerprints.

A November 2024 monthly report references a "代理项目" (proxy project) in which the author completed development/testing of a MAAT rule-matching program specifically "on the proxy" and assisted a deployment referred to by the short name "峰源" — thin on detail, but suggestive that MAAT-based rule matching is being applied to proxy traffic/infrastructure outside sapp's standard inline pipeline.

A MAAT/rulescan crash-debugging log shows the engine's getCfgId() lookup called with domain=".twitter.com", table_id=12, type="SNI", confirming MAAT performs SNI-field domain matching against a configured blocklist table (table_id 12 = SSL/SNI domain tables DF_SSL_REGION/DJ_SSL_REGION; table_id 22 = HTTP URL tables DF_HTTP_URL/DJ_HTTP_URL seen in the same crash series), and that the underlying librulescan.so string-scan library is prone to native crashes (SIGABRT) under real traffic.

A June 2024 MESA Lab internal survey ("针对审查系统的科学研究及探测技术调研报告") explicitly states its purpose is to catalog academic/public censorship-measurement and circumvention research (OONI, Augur, Satellite, GFWatch, Citizen Lab, CensorBib, FOCI/IMC/NDSS/CCS/USENIX Security papers) in order to find and patch GFW/censorship-system vulnerabilities before outside researchers exploit them. It systematically covers circumvention protocols/tools (Shadowsocks, VMess, Trojan, decoy routing, Parrot-style mimicry, CovertCast, Slitheen++, ESNI/ECH, uTLS) and notes GFW blocked ESNI (not ECH) since July 2020, plus historical TLS-fingerprint blocking of meek by a Cyberoam firewall (2016).

The leak includes saved copies of external research directly relevant to circumvention detection: a Chinese-Academy-of-Sciences paper (FS-Net) proposing an end-to-end recurrent-neural-network model for encrypted traffic classification (99.14% TPR / 0.05% FPR across 18 applications), and a 2008 Shanghai Jiao Tong University paper reverse-engineering UltraSurf's client via dynamic disassembly to recover its proxy protocol, encryption scheme, and network topology -- indicating MESA Lab/Geedge researchers maintain a working reference library spanning both ML-based traffic classification methodology and reverse-engineering methodology for circumvention client software, rather than relying solely on in-house techniques.

A vendor pitch deck from Baidu Smart Cloud's crowdsourced data-labeling service ("百度众测标注"), evidently reviewed by MESA Lab as a candidate vendor, offers "intelligent network security monitoring annotation" including public-opinion analysis and image/text recognition detection for pornographic, terrorist, violent, and politically-sensitive ("涉政") content, with throughput and accuracy figures (e.g. 3M images/day at 99%+ accuracy for image classification).

A MESA-affiliated researcher's experiment log documents live testing of Psiphon and a TLS-fragmentation SNI-evasion tool (DPYProxy) against the real Great Firewall from inside mainland China. Fragmenting the TLS ClientHello/TCP stream into very small (1-5 byte) segments bypassed GFW SNI-based blocking of a non-blocklisted Wikipedia IP, while larger fragments (10-20 bytes) did not; a separately IP-blocklisted Wikipedia IP still failed regardless of fragmentation. Testing Psiphon also appeared to trigger a ~5-10 minute window in which the researcher's own unrelated circumvention tool stopped working.

A raw production SSL/TLS session log from sapp's monitoring pipeline (timestamps dated 2021-08-23, client IPs in domestic Chinese carrier ranges) shows the per-connection logging schema includes dedicated fields for a captured certificate chain (INDIVIDUAL_CERT_FILE, MIDDLE_CERT_FILE, ROOT_CERT_FILE, CHAIN_CERT_FILE) and for any injected packet (INJECTED_PKT_FILE), alongside SNI and TLS version -- confirming sapp's live SNI-logging and MITM-cert-capture instrumentation was operating against real user traffic to services including huobi.com, steamcommunity.com, and dropbox.com.

An internal system-design document for a "Web Fingerprint" module specifies a mirrored-traffic system that identifies specific web pages a monitored individual visits over encrypted connections (the worked example given is a specific politically-related YouTube channel homepage) and specific search-engine keywords typed into Google search (the worked example target keyword given is "FLG", i.e. Falun Gong), with accuracy targets of >=90% page-identification precision and >=95% keyword recall, feeding a downstream "reputation" scoring module. A companion Python implementation with a real "dataset_24_youtube_ fingerprints.csv" dataset performs the YouTube-page fingerprinting using picture-count and request-size-sequence features, and is explicitly scoped in its file path to a "特定开放通道" (a specific open/circumvention channel).

The yydns attack-script sequence includes a numbered module '12-16 (target_GZ)' bundling fpdns_client/fpdns_server binaries with a topology diagram -- the same fpdns_server tool (a custom recursive DNS server with CNAME/NS-chain handling, from modikai/fpdns_server) reused here against a target labeled GZ, tentatively Guangzhou -- evidence the tool is used in operational test/attack scenarios, not just as a standalone utility.

A MESA Lab research report systematically surveys the entire refraction-networking / decoy-routing lineage -- Curveball, Telex, Cirripede, TapDance, Rebound, Slitheen, Waterfall, Conjure, MultiFlow, SiegeBreaker, Gossip, Slitheen++ -- and for each assesses concrete traffic-identifiability weaknesses (TLS ClientHello tagging patterns, TCP-ISN covert registration, timing side-channels, up/down traffic-volume asymmetry) as a groundwork threat assessment, explicitly noting the analysis is still 'on paper' pending packet-capture validation against real deployments.

A MESA Lab student research report catalogs the GFW's known Shadowsocks-detection methodology (passive detection via first-packet length/entropy; active probing triggered after as few as 13 legitimate client connections, typically within seconds of the first legitimate connection) alongside six published ML-based Shadowsocks traffic-classification techniques (a packet-size-image CNN at >98% accuracy, random-forest on flow/host/DNS-behavior features, PCA-Pearson feature selection), compiled as apparent background research for in-house detection work.

An internal MITM-attack training/research presentation demonstrates a live keyword-filtering test through a trusted-root-CA MITM proxy (mitmproxy) against HTTPS traffic to scholar.google.com: after installing the MITM root certificate on the client, searches containing a prohibited keyword (drugs, 毒品) fail to load while normal searches succeed, in both forward-proxy (via an Aliyun VPS relaying through the circumvention tool Clash) and transparent-proxy configurations. The same deck describes a separate built tool, "video_server," that MITM-intercepts and downloads WeChat Channels (微信视频号) video content, and covers SSH/RDP MITM techniques (including the SSH Terrapin attack) more broadly.

A December 2022 MESA Lab student monthly report (advisor 周舟) describes a live mid-term project review demo merging HTTPS, RDP, and SSH man-in-the-middle interception onto a single VM with unified start/stop scripting, alongside work on an internal "SSFY" standard/ specification document, SSL-strip measurement against the Alexa top-50 domains, and directed reading on detecting proxy traffic via nested TLS handshakes and on residential proxies as an active research topic.

'mrzcpd' is a real TSG-OS internal service/component (config path /opt/tsg/mrzcpd/etc/mrglobal.conf, tunable poll_wait_throttle_usleep_threshold) involved in packet-drop remediation on Fujian's Quanzhou Unicom site — likely a core packet-processing daemon given the tuning parameter's nature.

Internal engineering doc describes "整形平台" (internally versioned as "Nirvana" — GitLab repos reshape/nirvana_client and reshape/nirvana_platform), a Kafka/Redis-backed, fully-async C/S platform sitting downstream of sapp that performs cross-session, cross-link correlation to reconstruct complete file content, VoIP audio, and session metadata. Its explicit "单向流对准" (single-direction flow alignment) feature reunites the client-to-server and server-to-client halves of one session when they were captured separately (e.g. asymmetric routing, or a passive mirror tap seeing only one direction).

An internal structured-logging spec for a traffic-processing system ("一部和广东项目", i.e. Department-1 and Guangdong project) defines JSON log schemas pushed to a central data bus, including full mail capture (SMTP/POP3/IMAP with EML and attachment file dumps), HTTP request/response body dumps, FTP body dumps, connection records tagged with an app-identification label (PROTO_ID/APP_ID/OS_ID/BS_ID/WEB_ID/BEHAV_ID), and per-session SSL/TLS capture that stores full server AND client certificate fields (issuer, subject, SAN, validity dates, cipher suites) alongside SNI.

handingkang/ohmydns2 is a CoreDNS-fork DNS server built by a MESA Lab/IIE engineer ([email protected]) that bundles a "prober" active-probing plugin, a "v64dns" module, and an "atk" plugin with dedicated branches (atk_DDoS, atk_DDoS_resolver, atk_qp) implementing DNS response amplification and an attempted DNS injection/tampering feature ("注入篡改功能实现尝试"). This combines active DNS probing with resolver-based amplification/attack tooling in one codebase.

TSG's firewall 'Deny' security-policy action is confirmed implemented via three interchangeable mechanisms: TCP RST injection, forged HTTP 404 response-page injection, and DNS-redirect. Confirmed via commits to MESA_Platform/sapp and tsg/tsg-os-buildimage GitLab repos (git.mesalab.cn).

TSG has a named application label "Psiphon-Server-APP" used in its Application-identification/Deny policy engine. A confirmed bug: non-DNS UDP/53 traffic was misclassified by the base protocol-identification plugin as DNS, which suppressed the Deny action even though the session was correctly labeled Psiphon-Server-APP in the security event log — i.e. a competing protocol classifier's (mis)classification silently overrode the intended enforcement action.

Jiangsu domestic deployment streams filtered TSG session-record log fields to a third-party contractor via Kafka-to-Kafka integration ('Real-Time Log Streaming'), at the request of a Nanjing telecom regulatory bureau (南京管局), with the third party also given a Hive table-creation schema for their own ingestion pipeline.

A performance bug at a domestic Xinjiang test site (25-70Gbps) traced packet-processing lock contention to a plugin named "tsg_vulpes" calling an ONNX Runtime model for real-time "encrypted voice recognition" on live traffic; disabling this ML classifier resolved packet loss, indicating it's an optional, performance-costly add-on.

TSG retains full per-session traffic logs (not just blocking events) at national-center scale via ClickHouse, aggregated from provincial sub-centers via ETL; log volume was large enough (~25% daily growth from one sub-center optimization alone) to require dedicated IO-reduction engineering (secondary indexed sub-tables, disabling several sub-table sync views), confirming pervasive session-level traffic logging/retention is a standing capability independent of, and broader than, active blocking.

A TSG deployment was rolled out to Jiangsu's Yangzhou "anti-fraud" project in March 2024, explicitly timed to complete before China's "Two Sessions" political meetings, with dedicated (non-shared) OLAP hardware.

Fujian's domestic anti-fraud TSG deployment must pass China's MLPS compliance testing, requiring hardware-token (Ukey) login from vendor "数盾科技" (Shudun Technology). Xinjiang's 5G project is slated for the same treatment via a different vendor.

TSG's application-fingerprinting engine matches 'FlyVPN' via a combination of IP-address and FQDN/port feature objects (each independently versioned/timestamped); a false-positive bug investigation confirms the live traffic-classification component is called 'sapp' and that restarting it is a standard troubleshooting step for signature drift.

A burst of UDP traffic at a Xinjiang site (Bole-IGW -- Bole is a Xinjiang city, matching gfw.report's identification of Xinjiang as a domestic TSG deployment region) hitting monitor policies drove all packet-processing-core CPU to >99%, exhausting DPDK mbuf buffers and triggering cascading container restarts across ~10 NPB (Network Packet Broker) devices.

At the Quanzhou Unicom (Fujian) TSG-OS site, under CPU/traffic pressure TSG's 'overload protection' causes packets to reach SAPP capture but never reach the firewall enforcement stage, producing a confirmed policy bypass ("穿透"). The operational fix disabled policy_sketch, traffic_sketch, overload_protection, duplicate-packet filters, and the SSL_CERT/SSL_JA3/HTTP_GZIP/DNS decoders to reduce CPU load, i.e. detection/enforcement is explicitly traded away to preserve throughput at peak load.

TSG's DNS Redirect firewall action has two modes — "hijack" (constructs and sends a spoofed DNS response, dropping the real request) and "replace" (only modifies the DNS response in transit) — with correct mode depending on inline vs. mirror/passive deployment; a Fujian domestic site (mirror-mode, request-only visibility) hit a bug where the default mode silently had no effect.

TSG maintains a traffic-volume-ranked "Top SNI" / "Top Server IP" allowlist (Galaxy component, learned from live traffic, capped at top ~2000 SNIs / ~40000 server IPs per Nacos config) that is checked before a VPN/circumvention-tool deny policy (including a Psiphon3-specific policy) is enforced. Confirmed empirically: Psiphon3 client traffic whose destination SNI was in the Top SNI list passed through undenied, while traffic to the same client IPs with an SNI not yet in the list was blocked. A 2022-06 incident over-blocked TikTok/BBC/CNN/NYTimes because their SNIs were not yet in the learned allowlist at the time.

TSG deployed at a Xinjiang site could not reliably block QQ via HOST/SNI matching due to excessive payload-based config, so Geedge added a dedicated OICQ (QQ's underlying protocol) L7 identification capability in the app_proto_identify plugin, extracting LPI-library classification results for WeChat and OICQ as first-class 'App identification' output, released in the 22.08 TSG version.

A custom rule combining SSL certificate field conditions to block Bilibili had no actual blocking effect despite matching sessions appearing correctly in session records — a gap between detection/logging and enforcement for this rule type.

In late 2022 a Geedge customer ("E21" site) explicitly requested a nationwide (全国范围) deny policy against Psiphon3 and ten other commercial VPN products (ExpressVPN, NordVPN, Surfshark, Ultrasurf, iTop VPN, Hotspot Shield, ProtonVPN, CyberGhost, TurboVPN, TunnelBear). Geedge split feature-extraction work between its engineering and QA teams, packaged signatures as importable appjson files, and tracked per-product blocking effectiveness.

TSG at Quanzhou Telecom (Fujian, domestic) runs "sip"/"fw_voip" plugins logging call-detail-record fields (caller, callee, User-Agent) specifically for SIP INVITE/BYE (call setup/teardown), by design excluding SIP MESSAGE/REGISTER traffic.

Fujian's anti-fraud "big screen" dashboard treats circumvention-tool use as a first-class flagged category alongside fraud: warning reasons include "visited a fraud-linked site, used an accelerator" and "new user of AiJiaSu" (a named accelerator app), each tied to the individual's phone number and refreshed ~every minute.

TSG's RST-injection blocking pipeline is architecturally split: mrzcpd (packet-mirror/capture agent) batches packets (config sz_buffer, packets-per-forward) before handing them to sapp (the inspection/policy engine) for match-and-RST. Under certain carrier/traffic conditions this batching introduced a 5-20ms delay between the real SYN and sapp's RST, letting the blocked connection's data through before the RST arrived -- a confirmed, reproducible bypass ('穿透') on specific Fujian ISP links, fixed only by setting sz_buffer to 0 (no batching).

The Fujian (domestic China) deployment uses a punycode/IDN-aware keyword-filtering policy object named '中文涉诈域名' (Chinese fraud-related domains) with wildcard item matching; a bug ticket shows the policy engine failing to match an IDN punycode domain correctly against this object, revealing the underlying components: a 'verify-policy' microservice, and libraries 'libmaatframe' and 'librulescan' handling rule evaluation.

Fujian Unicom (福建联通), coordinating with the domestic customer referred to internally as "工联院", requested TSG perform HTTP-host-based redirect blocking (to a Fujian anti-fraud police portal) instead of relying on Unicom's own 303-redirect infrastructure, because TSG's RST-based block executed faster and pre-empted it. TSG at the time only supported URL-based redirect, not host-based, when the malicious URL path was empty.

As of TSG v23.07, FQDN matching supports left-anchored prefix/wildcard matching (e.g. 'voice-group-80x-api.*'), added specifically so a Fujian domestic deployment could detect domains with a fixed subdomain prefix but rotating remainder. Earlier versions only supported exact FQDN match.

Confirms SAPP is deployed directly on Xinjiang China Telecom (XJ-CTCC) infrastructure -- explicit domestic carrier-level deployment, corroborating the taxonomy's cn/Xinjiang entry with a specific named carrier.

In Fujian's Quanzhou China Mobile 5G deployment (2023-04), sapp crashed repeatedly with the DTLS inspection plugin enabled; disabling sip/dtls/fw_dtls/fw_voip plugins stopped it. Root cause: DTLS parsing layer on an old, buggy version, with a full rewrite planned for v22.06 and DTLS inspection told to stay off meanwhile.

SAPP evicts per-flow blocking state after a configurable TCP stream timeout (platform default 30s); a client that waits past that window before retrying a blocked connection bypasses the block entirely, confirmed reproducible over repeated tests before the timeout was manually extended. Separately, SAPP only emits a session log record when a flow exceeds both a packet-count and a payload-byte-count threshold (default: >3 packets AND >5 bytes TCP payload) -- flows below that are never logged at all.

At China Unicom's request (stated purpose: investigating a new type of telecom fraud), TSG's Xinjiang NPM deployment added VOIP and GOIP protocol identification, producing traffic reports (call counts, top IPs, top accounts, top user-agents) for the carrier.

Extensive engineering effort to extend TSG's built-in 'APP Sketch DB' fingerprint database with signatures for major domestic Chinese apps (Douyin, Kuaishou, Mango TV, JD, Tencent Cloud, etc.), primarily via SSL SNI matching, with iterative per-feature test/fail/patch cycles against specific in-app actions (e.g. certain Douyin menu items stayed unblocked after the main signature succeeded).

Reveals internal architecture of TSG's traffic classification engine: the 'sapp' process (binary at /opt/tsg/sapp/sapp, version sapp-4.2.90) uses a packet-I/O layer called 'marsio', a custom app-identification plugin 'app_sketch_local' (identify_app_by_tcp_payload / identify_app_by_user_define_attributes), and an embedded LuaJIT ('libelua') for user-defined protocol signatures (e.g. custom Modbus detection) — concurrent LUA script loading crashes the classification worker.

Confirms a TSG-X/TSG-OS (v22.11) deployment at "新疆联通IDC" (Xinjiang Unicom IDC, a specific China Unicom data center), part of a domestic "XJ-NPM" project; core traffic-processing components are named "mrzcpd" and "sapp," both required to start successfully for the appliance to function.

The galaxy/deployment/online-config repo — the central field/site configuration store — maintains per-customer git branches named E21 (Ethiopia), P19 and P19-POC (Pakistan), and XJ (Xinjiang), each tracking dated "现场配置" (field configuration) commits pinned to specific TSG software versions (e.g. TSG 22.02, 21.11), directly corroborating the E21/P19/XJ site codenames already established in taxonomy and confirming ongoing, versioned field deployments as recently as 2023-07 (a "P19 23.07 online-config" branch commit).

An August 2024 internal MESA Lab survey evaluates nDPI, Suricata, and Tranalyzer2 as candidate open-source DPI engines, scoring each explicitly on DPDK integration support ("dpdk集成") alongside protocol-detection and custom-protocol-extension capability — corroborating that DPDK compatibility is a hard selection criterion when picking/extending third-party DPI code, consistent with sapp's DPDK-based Marsio packet-I/O layer.

Domestic (Xinjiang-linked) systematic blocking-capability testing covers a broad swath of ordinary consumer apps well beyond circumvention tools -- named test targets in this single 50-app batch include a Xinjiang police app (新疆公安) and Xinjiang government-affairs app (新疆政务) tested in the same numbered sequence as banking, e-commerce, gaming, and video apps -- indicating the AppSketch pipeline's scope is general internet-content control capability, not solely anti-circumvention.

Weekly TSG 'SNI Report of Overseas APP' and 'Server IP and Location of Overseas APP' reports show continuous SNI/server-IP-and-geolocation classification, at national ISP/IDC scale (up to ~447 Gbps average / ~1 Tbps peak, hundreds of billions of sessions per week), of a fixed watchlist of foreign platforms including Youtube, Facebook, Google, Twitter, Instagram, Telegram, Whatsapp, Viber, Line, Messenger, Snapchat, Gmail, HBO, Netflix, BBC, Discord, ESPN, Hulu, Bigo, and Canvas -- establishing that TSG's core function includes always-on, large-scale identification and cataloguing of exactly the class of foreign communication/circumvention-adjacent platforms that are typical censorship targets, independent of any single export customer.

NTC_HTTP_COLLECT ('http_url_discovery', in the codebase since at least 2014-2018 per version tags) passively harvests every HTTP request URL and Referer header seen in monitored TCP traffic and streams each hit (with source/destination IP:port, transport proto, extracted domain, capture-node IP, and found_time) to Kafka topic 'AIM'. A companion filter list (http_url_filter.conf) suppresses roughly 100 file-type suffixes — not just static assets like .jpg/.css/.js but also office, archive, and executable extensions (.doc/.docx/.pdf/.zip/.rar/.exe/.dll) — from this particular URL-discovery feed, consistent with those downloads instead being routed to a separate full-object capture pipeline (see the ObjectScanner finding from this same batch).

TSG's T1 traffic-engine plugin framework (NTC_APP_PLUG, NTC_IP_COMM) tags every classified flow with a composite app-identification label (PROTO_ID/APP_ID/OS_ID/BS_ID-browser/WEB_ID/BEHAV_ID) drawn from a shared per-stream 'dpkt' classification struct, and streams it via Kafka/local log for every session. A disabled (#if 0) code path in NTC_APP_PLUG shows this exact label being matched against the MAAT rule engine (Maat_full_scan_string) to trigger MESA_kill_tcp (RST-based termination) when a block rule fires; NTC_IP_COMM separately logs a live 'stream_killed_flag' via an 'after_kill_switch' option, confirming the TCP-kill/track-after-kill mechanism is real in production even though this particular scan-and-kill call site is currently compiled out.

A generic RADIUS/AAA-sniffing traffic-engine plugin (NTC_RADIUS_PLUG, default SERVICE_ID 0xA2) parses live RADIUS Access/Accounting packets off the wire and extracts User-Name, Calling-Station-ID (the subscriber's phone number), Called-Station-ID, Framed-IP-Address, NAS-IP, Acct-Session-Id and related attributes, tags each record with a global stream-trace ID, and streams it to Kafka topic 'RADIUS-RECORD-LOG'. This is a concrete source-code-level match for the carrier RADIUS/AAA-ingestion mechanism the taxonomy attributes to the CyberNarrator subscriber-identity-correlation component (Pakistan deployment, Jazz/Zong/Ufone/Telenor), though this particular file is generic/unbranded rather than explicitly named CyberNarrator.

NTC_SSL_COLLECT passively parses every TLS handshake in monitored traffic and streams the SNI, hex-encoded client and server cipher-suite lists (a JA3/JA3S-equivalent fingerprint), and full leaf-certificate fields (serial number, algorithm, issuer/subject CN, org, and country, validity window, and optionally the complete SAN list) to Kafka topic 'ntc_ssl_collect_log' for every TLS session, tagged with the same PROTO_ID/APP_ID/OS_ID/BS_ID/WEB_ID/BEHAV_ID classification label used across the T1 plugin family.

ObjectScanner is a Kafka-driven pipeline that consumes 'NTC-COLLECT-HTTP-DOC-LOG' and 'NTC-COLLECT-HTTP-EXE-LOG' events (documents and executables observed transiting monitored HTTP traffic), fetches the full file body for each hit from a 'TANGO_CACHE' object store (via a MinIO-oriented fetch-thread pool), and scans the complete file with the Antiy AVL SDK malware-detection engine, publishing malware_id/malware_name/classification/family/variant hits to Kafka topic 'NTC-HTTP-OBJSCAN-RESULT'. This shows the DPI platform doesn't just log metadata about document/executable downloads (per the NTC_HTTP_COLLECT extension filter list) — it retrieves and fully content-scans the actual file bytes for every such download crossing a tapped link.

A T2-tier business plugin (T2_HTTP_DIG_BIZ) reassembles full HTTP request and response bodies (including gzip-decompressed content) out of monitored sessions and hands them to an internal 'digapis_detector' engine that classifies traffic into vulnerability/attack categories, logging hits to an Elasticsearch index ('aiids_tcp_', doc_type 'vulnerability') on an internal ES cluster reached with a hardcoded admin credential. A companion Python script bundled in the same archive ('high_menace_zhilan_exp.py', i.e. roughly 'high-risk ... exploit') is a working proof-of-concept that logs into a DVWA test target and repeatedly uploads a base64-encoded PHP webshell to the uploads directory to get remote command execution — consistent with being used to exercise/validate the digapis vulnerability detector against a known file-upload RCE class rather than for censorship per se.

A patent draft (applicant not present in the extracted text, but topically and methodologically identical to MESA Lab's SAPP audio/video-identification plugin work in the same corpus) describes a content-level encrypted-video identification system: an SNI-triggered flow classifier groups downlink ACK-aligned packets into 'chunks', converts the chunk-size sequence into a long/short word-frequency signature, and matches it in O(1) against a fingerprint database built by actively crawling target sites through a MITM proxy. Tested on 1,000 YouTube videos captured from 5 locations, it reaches 96.19% accuracy needing only 6 online chunks at 3.33us per match, 90x+ faster than three prior published methods it benchmarks against.

An internal protocol-ID lookup table (103 entries) used by a DPI pipeline includes a dedicated "TORCONTROL" identifier alongside ANYCONNECT (Cisco VPN), PPTP, and RADIUS — confirming Tor control-port traffic and multiple commercial VPN/tunnel protocols are each assigned a distinct, first-class detection category rather than being lumped into a generic "encrypted/unknown" bucket.

A MESA Lab monthly report records a researcher completing Psiphon DGA (domain generation algorithm) domain detection work, packaging the domain-detection code into a library and uploading it to the internal mesalab code repository, alongside drafting a patent disclosure the same month.

The same student's prior (October 2022) monthly report documents an Alibaba-Cloud-hosted full-IPv4 scan that found 5.5 million hosts with an open RDP port (3389), performed as part of thesis research into improving RDP man-in-the-middle detection methodology.

An internal Geedge/MESA research report titled '关于Refraction Networking的调研报告' surveys all three generations of decoy-routing/refraction-networking circumvention systems (Curveball, Telex, Cirripede, TapDance, Rebound, Slitheen, Conjure, Waterfall, MultiFlow, SiegeBreaker, Gossip, Slitheen++), summarizing each system's tagging mechanism, deployment status, and citing published academic traffic-analysis attacks against each -- including explicit note that TapDance is used inside Psiphon, V2Ray, and Trojan -- indicating this adversary actively tracks decoy-routing research as a candidate detection target rather than treating it as a solved/ignored threat.

A MESA lab traffic-fingerprinting dossier builds per-application DNS/SNI/TLS-certificate signature databases for remote-desktop software (Oray's "Sunlogin" and TeamViewer), cataloguing their control-plane domains (e.g. slapi.oray.net, rc10-fc02.oray.com, sunlogin.oray.com) and documenting a proprietary UDP/3000 "DIS" signaling protocol used by Sunlogin for device discovery.

A multi-week investigation on Fujian Mobile's network found TSG's RST-injection blocking intermittently failed to reach the client even on a correctly-matched policy, traced to carrier-side loss/delay on the injected-RST path and TCP port-reuse/SYN-retransmission edge cases at one mobile site, with RST send rates up to 40,000-80,000/s during the anomaly.

MESA Lab engineering logs (2020) describe development and TSG-environment testing of a SAPP plugin that identifies encrypted audio/video traffic and distinguishes on-demand from live streams. The workflow uses Fiddler (a TLS MITM proxy) to decrypt traffic client-side and auto-label training data for the underlying ML model, and required a dlopen() workaround to load libpython.so for the model at runtime.

SAPP's packet-capture configuration parameter (capdatamodlel) documents up to 16 capture-driver modes including libpcap, PF_RING, and DPDK, plus a Geedge-proprietary "marsio" mode (value 12) built by MESA on top of DPDK, whose driver-specific configuration is explicitly stated to live at /opt/mrzcpd/etc -- confirming, from SAPP's own configuration documentation, the marsio-mrzcpd relationship already inferred elsewhere in the corpus.

A 2020 MESA lab work log documents active development of a SAPP plugin for in-line identification of encrypted audio/video traffic: the feature-extraction module is complete while the model-prediction module remains in progress, and the developer notes the training dataset is still class-imbalanced and is researching semi-supervised methods to address it.

TSG's DPI signature engine is organized around named internal components confirmed by config paths and error logs: SAPP (installed at /home/mesasoft/sapp_run or /opt/tsg/sapp), MAAT (config at .../tsgconf/maat.conf, tied to a Redis-backed APP_SIG_SESSION_ATTRIBUTE_STRING table), and App-SketchDB (a versioned, centrally-maintained app-identification signature database pulled periodically by field deployments). One deployment's provincial gateway alone had 1,667 TCP/UDP first-packet payload signature entries active (396 at the IDC site), confirming payload-prefix matching as a live, large-scale detection method, including custom byte-prefix entries for DingTalk and WeChat.

SAPP's documented API for business-layer plugins exposes explicit active-interference primitives as first-class, plugin-callable platform functions: MESA_kill_tcp (constructs and sends a correctly-sequenced TCP RST to forcibly terminate the current flow), MESA_kill_tcp_synack (sends a forged SYN/ACK in response to a client's SYN before the real server can respond, preventing the connection from ever completing), and MESA_inject_pkt (injects arbitrary application-layer payload into the live client/server exchange, addressed using the current flow's four-tuple and tunnel-encapsulation info).

An internal Geedge Networks wiki page (marked "Geedge Networks Confidential And Proprietary") confirms SAPP's full name as "Stream Analyse Process Platform" -- a DPI-based network-security development platform analogous to NGFW/IDS/IPS/UTM engines -- describes its three-tier plugin architecture (platform / protocol-parsing / business-layer .so plugins loaded via dlopen in that order), and traces its lineage through four generations since 2005 (start -> papp -> sappv3 -> sappv4, the last dating to 2019 and still the actively developed branch).

The official SAPP platform manual ("Geedge Networks Confidential And Proprietary") documents an optional signature_enabled config flag that stamps sapp-injected TCP RST packets with a detectable pattern in the ip_id/ip_ttl/tcp_win fields so operators can later verify, via a Wireshark plugin or standalone tool, whether a given RST originated from a sapp instance -- the manual explicitly notes 100% recall but not guaranteed 100% precision. The manual separately documents that sapp supports three distinct wire-injection topologies (sys_route, vxlan_by_inline_device, raw_ethernet_single_gateway) and that its tcpdump_mesa debug tool has a dedicated "inject" packet class covering both TCP RST and forged DNS replies.

An hourly interface-throughput log from a live sapp v4.2 instance (App label "sapp_v4.2") shows sustained aggregate traffic of roughly 15-20 Gbps across two bonded NICs (ens3f0/ens3f1) with zero recorded packet drops (RxDrops/TxDrops = 0.00) over a multi-day window in April 2024, i.e. full-line-rate, drop-free DPI inspection sustained at that scale.

A 2021 MESA meeting note on an "encrypted video stream content identification" experiment records collecting Tencent Video traffic through SAPP, a SAPP bug where retransmitted packets are not counted during packet processing, and next steps to study YouTube's video transmission patterns and circumvention/router-VPN techniques -- explicitly framed as choosing collection targets "from a regulatory/censorship standpoint, favoring sites with weaker self-censorship."

An internal SAPP performance-optimization log documents production testing on the "XJ" (Xinjiang) site carrying 100,000+ ("10W+") active configuration/rule entries, running on domestic Hygon (海光) CPU servers, and reports roughly 30-40% CPU-usage reduction (from ~13% to ~8% at 10 Gbps) achieved through memory-allocator, Bloom-filter duplicate-packet detection, and packet-polling-loop optimizations.

Internal 'SAT项目' meeting notes and a progress-report slide describe a new mobile-subscriber-correlation system being built by reusing the existing TSG UI ('NTC or TSG'), whose core open technical problem is reconciling GTP mobile-signaling data with RADIUS billing records to identify a user from IP address alone when no TEID is available in 4G networks; the work is tied to a filed patent, '一种应用服务分类识别方法及系统' (a method and system for application service classification and identification).

A MESA lab engineering project codenamed "SAT" builds a user-station identification module on top of TSG, using the MAAT rule-file format for its front-end/back-end policy (PZ) interface, and ingests LTE mobile-network-element traffic (S1-U interface -- SGW/PGW/eNodeB/MME, captured via a simulated Docker SDR environment) to write subscriber-station status into a "TSG-Radius" table.

A MESA Lab monthly work report (research group under Fangyu Xing / 方滨兴) states the researcher completed a study of active probing against Shadowsocks and produced an initial reproduction of probe generation targeting historical Shadowsocks server versions, alongside two finished commercial-VPN analysis reports, with further probe-generation work and a connection between state fuzzing and active probing planned as next steps.

A 2020 internal hardware requirements spec ('深串系统需求文档' / 'Shenchuan [deep-serial-tap] system requirements', v1.2, authored by '北京恒光研发部') for a project named '信工所深串接项目' (an Institute of Information Engineering, Chinese Academy of Sciences project) describes an ATCA-chassis inline traffic-tap appliance -- S3200 switch boards plus RTM20XG POS line cards plus 9 x86 processing blades -- that serially intercepts 100GE/40GE/10G/2.5G POS links, filters 60%% of traffic to dedicated 'business X86' boards via domain rules or 'deep DPI' rules, and fails open through an optical bypass protector (OLP) on hardware fault. This is a previously undocumented internal hardware codename ('深串'/Shenchuan) distinct from the named products already in the taxonomy.

A recurring 'IP标签（石河子）报告' (IP Tag (Shihezi) Report) shows a monitoring deployment specific to Shihezi, a Xinjiang Production and Construction Corps city, tracking both IDC links (22 links, 1.21Tbps total / 15 links, 1.14Tbps actively connected) and separate 出入口 egress links (26 links, 2.08Tbps) for the same site and date -- a specific domestic site identity more granular than the general 'Xinjiang' label already in the taxonomy.

At least 67 files in this batch (31 "SNI Report of Overseas APP" + 36 "Server IP and Location of Overseas APP") are automated weekly TSG reports, generated 2023-01 through 2024-03, each processing hundreds of billions to over a trillion log rows and breaking down PB-scale traffic (peaks over 500 Gbps observed) by SNI/domain for ~20-30 named foreign platforms per report (Netflix, YouTube, Facebook, Google, Twitter/X, Instagram, Telegram, WhatsApp, Viber, Signal-adjacent messaging apps, Snapchat, Reddit, Quora, Pinterest, Tinder, Uber, Wikipedia, Zoom, HBO, Gmail, Line, Messenger, etc.), confirming a continuously-operated, nation-scale SNI-based traffic categorization and server-IP/geolocation pipeline for foreign services, not a one-off capability.

For a domestic Fujian deployment, Geedge validated SNI-wildcard blocking (*.sohucs.com, *.sns.sohu.com) as technically effective against a specific Chinese social app ('Huyou'), but rejected it for production because the domain is shared with a third-party SDK platform and would cause false-positive blocking of unrelated services -- falling back to destination server-IP blocking, deployed inline via TCP RST injection.

An internal MESA Lab research survey dedicated to Snowflake reviews five external papers on fingerprinting/blocking Snowflake and WebRTC-based transports, including a 2023 CSCWD paper that fingerprints Snowflake's broker-contact requests (disguised as HTTPS) via packet size, direction, timing, and network speed to distinguish them from ordinary web requests, and a 2020 paper claiming 100% identification of Snowflake DTLS handshakes against Facebook Messenger/Hangouts/ Discord WebRTC traffic in a closed-world test — annotated throughout with the MESA reviewer's own critical commentary on each method's weaknesses (e.g. sensitivity to user geography/network, only tested at host/LAN vantage points rather than backbone).

A MESA lab monthly report describes coordinating TSG installation/deployment and a traffic-replay test environment (capture/parse/match module testing) for a project codenamed "TF", alongside separately deploying a "主动防御" (active defense) program from an internal git repo with distinct "flooding" and "reflection" modules that were functionally tested.

A captured 'getcatlist' API response enumerates an 83-category licensed URL-classification taxonomy (BrightCloud/Webroot-style category names and IDs) that includes a dedicated 'Proxy Avoidance and Anonymizers' category (catgroup 'Security') alongside categories like 'Government' and 'Hacking' -- showing the platform layers a licensed third-party URL-reputation feed on top of AppSketch's custom signatures specifically to catch circumvention/anonymizer traffic by category rather than only by named signature.

TSG's SSL decoder could not parse TLCP (China's national TLS variant) SNI as of v24.02, classifying such flows as generic BASE traffic and defeating server-name blocking; TLCP parsing was added in v24.08/24.09 per a tracked MESA_Platform/ssl commit.

Peer-review correspondence on the companion PhD thesis ('Tor隐藏服务溯源管控关键技术研究', same MESA Lab body of work as the AlterCell report) documents a third technique -- a descriptor-cache-overflow-based denial-of-service that drove a target hidden service's accessibility down by 90% in real Tor network testing at low, sustained cost -- and shows a reviewer explicitly flagging the thesis for undisclosed state-security sensitivity and instructing the author to replace the original '管控' (state control/management) framing with the more academic 'denial of service' term, while the thesis's own stated motivation is '维护国家网络安全和社会稳定' (safeguarding national cybersecurity and social stability).

Internal TSG project chat logs show engineers tasked with determining how many distinct clients sit behind a single client IP for the TSG project, starting with User-Agent field analysis and researching offline WHOIS/domain-registration databases as a supplementary signal -- i.e., detecting shared-connection/NAT'd usage (including likely VPN gateways) is an explicit TSG feature requirement.

A MESA Lab monthly report describes functional testing of a "TSG DoH proxy" (TSG DoH代理) covering availability, HTTP version support, server-side behavior, and HTTP header fields, with results posted to the internal Confluence wiki (docs.mesalab.cn), under a project labeled XDC. The same reporting period covers a separate autoencoder-based DoH-traffic-detection paper with an "improved active-verification method" for discovering additional DoH resolvers.

TSG supports importing carrier-provided eNB (cell tower) IP-to-location mapping tables into its 'IP Library' so that mobile-network session/security logs can be annotated with the subscriber's approximate physical location (down to street/base-station granularity) for 4G traffic; deployed for Fujian's domestic mobile-network monitoring.

A ClickHouse SQL query against table tsg_galaxy_v3.session_record_local implements a heuristic for flagging likely proxy/circumvention-tool usage: within 5-second windows, it flags any client IP that connects to 30+ distinct server IPs on high ports (>=10000) with small, tightly-bounded packet counts (6-15 sent, 4-15 received) where the session's application-layer protocol is unclassified (app_transition = 'unknown'). "tsg_galaxy_v3" indicates a named TSG data-warehouse/analytics layer distinct from the sapp/maat real-time inspection path.

A recurring TSG dashboard panel titled "各省份流量速率" (per-province traffic rate) breaks domestic traffic down by Chinese province; across these four report exports alone the provinces named include Xinjiang, Shaanxi, Shandong, Jiangsu, Anhui, Henan, Guangdong, Gansu, Zhejiang, Fujian, Ningxia, Qinghai, Hebei, Shanxi, Beijing, Hubei, Hunan, Chongqing, Sichuan, Nei Mongol, Jilin, Heilongjiang, and Liaoning — a far wider domestic footprint than the three provinces (Xinjiang, Jiangsu, Fujian) previously documented in this corpus's taxonomy notes.

TSG ships a dedicated 'OAM' (Operations, Administration and Management) subsystem with its own versioned install/deploy guide (v0.6, changelog entries since 2020-01-15) and CLI user guide (v0.83); a package install command confirms the runtime path '/opt/tsg/sapp/' and package naming 'tsg-traffic-engine-vsys-1', extending the sapp/Kubernetes deployment details already established in the taxonomy with the specific RPM packaging and OAM management-plane details.

Dozens of weekly "Tiangou Secure Gateway" auto-generated reports ("SNI Report of Overseas APP" / "Server IP and Location of Overseas APP") in this batch break out per-application SNI and server-IP/geolocation tables for Facebook, YouTube, Twitter, Instagram, Telegram, WhatsApp, Viber, Snapchat, Signal-adjacent messaging apps, and others, at up to 828 TB/week and 12+ Tbps peak processed traffic -- direct operational evidence of continuous, automated, per-app SNI-based classification of outbound "overseas app" traffic at production scale.

TSG runs a recurring, fully-automated weekly analytics job -- literally titled 'Tiangou Secure Gateway SNI Report of Overseas APP' and a companion 'Tiangou Secure Gateway Server IP and Location of Overseas APP' report -- that processes roughly 300 billion to 10 trillion traffic rows per week and produces per-platform SNI and server-IP/location breakdowns (Top10/Top50) for YouTube, Facebook, Google, Twitter, Instagram, Telegram, WhatsApp, Viber, Line, Messenger, Snapchat, Gmail, HBO, Netflix, Discord, BBC, Bigo, ESPN, and Hulu, plus a dedicated Top-100 SNI table for QUIC-protocol traffic.

An internal field-mapping schema for TLS/SSL session logging (cross-referenced against multiple internal system versions, one explicitly labeled "tsg") shows JA3 and JA3S TLS ClientHello/ServerHello fingerprint hashes are captured as standard logged fields alongside SNI, negotiated cipher suites, and the full server and mutual-TLS client certificate chains (issuer, subject, serial, validity window, raw public key).

A MESA lab engineer's monthly report lists "TSG project: webroot library-table label mapping" as completed work, indicating TSG maintains a "webroot" reputation/category database with an active label-mapping process as part of its classification pipeline.

A confidential ("内部资料 注意保密") 2020 MESA architecture-group report catalogs infrastructure recon (ICP registration, whois, DNS, FOFA scans, TLS-cert lookups) and packet-capture/SNI fingerprinting for seven video-conferencing services -- DingTalk, Zoom, Feishu/Lark, 科技云会, Teambition, Slack, and WebEx -- including specific SNI values observed for Zoom's China CDN deployment (e.g. cn01www3.zoom.com.cn, zoomawscn5281151165zc.zoom.com.cn).

A confidentiality-marked ("内部资料 注意保密", 架构组/Architecture Group) MESA Lab research report systematically profiles 11 video-conferencing/collaboration platforms (DingTalk, Zoom, Feishu/Lark, WeCom, Tencent Meeting, WebEx, Huawei WeLink, Slack, Teambition, 科技云会, 小鱼易连) with SNI lists, TLS certificate fingerprints, DNS/whois infrastructure, and an explicit "passive traffic analysis feasibility" (被动流量分析可行性) verdict per app — direct precursor engineering work for per-app DPI detection signatures.

Geedge runs an ongoing, weekly-cadence feature-extraction and blocking program against a customer-curated list of at least 282 named commercial VPN/circumvention apps (including Fly VPN, Secure VPN, NotVPN, letsVPN, VPN Hero, BeastVPN, Cafe VPN, Blockless VPN, BlackVPN, FinchVPN, Cisco Secure Client/ocserv, DelightVPN, NordVPN), plus separate systematic testing of 400+ non-VPN apps. The methodology extracts destination server-IP lists (hundreds to thousands of IPs per app) and app-specific FQDNs, tests each in staging for false positives before deploying, and for at least one target stood up their own clone of the target VPN server software to capture and analyze its real protocol handshake.

Internal fingerprinting research report builds SNI/TLS/certificate profiles and a repeatable packet-capture methodology (separately labeled login/logout/ping/remote-desktop/ssh activity captures, split by TCP vs. UDP) for Sunlogin (向日葵/Oray), TeamViewer, and OpenVPN — explicit precursor engineering work for building per-app/per-protocol DPI detection signatures, including for OpenVPN over both its TCP and UDP transport modes.

An internal MESA Lab survey of VPN/circumvention tools explicitly names Lantern alongside Psiphon as tools whose domain-fronting "can effectively resist detection," and separately reports a measurement result of 39,284 distinct "concealment" (circumvention/proxy) IPs accessed a cumulative 140 million times in one week, spanning 78 identified hidden services/platforms, with the top 10 including Psiphon3 VPN, Xvpn, Thunder VPN, generic Residential Proxy, Secure Android VPN, Proxymaster VPN, Tomato VPN, Foxyproxy VPN, Torch VPN, and Bunny [VPN].

Two versions of an academic active-probing VPN-server-detection paper ("VPNChecker"/"VPNSniffer", WWW'24) held in this corpus specifically profile Psiphon3: Psiphon3 servers account for the single largest share (6.64%) of labeled VPN servers in the authors' ISP dataset, most respond to an OpenVPN probe by silently timing out rather than returning the standard OpenVPN response (a "probe-resistant" behavior the paper explicitly attributes to Psiphon3), and Psiphon3 servers share a small number of characteristic "Probing Port Combinations" (e.g. {443,53,22}, {443,554,22}) across the vendor's fleet that the paper's graph-based classifier uses to link servers together.

Session-log exports from a Beijing test/demo TSG device ("XXG-TSG-BJ") show live "Deny" enforcement actions (security_rule_list "Deny_VPNHero", "deny_TowerVPN") against traffic the app-ID engine classified with nested app chains "VPNHero" and "OPENVPN.TowerVPN.Psiphon Provider.Psiphon-Server" -- i.e. TowerVPN is specifically tagged internally as riding on Psiphon infrastructure, and both it and VPNHero are actively blocked, not just logged, on this device.

An internal talk deconstructing MESA Lab's own WWW2024 paper "Identifying VPN Servers through Graph-Represented Behaviors" (VPNTracker) confirms it was built on the group's own internal production log data ("组内数据"), and details its core active-probing feature: "Stealth Ports" (TCP ports observed open in passive traffic that refuse/ignore active probes) combined with vendor-specific patterns in the error responses VPN servers return to out-of-protocol active probes (e.g. a DNS query sent to the port), fed into a graph neural network over client-IP/server-IP/port relationships; framed explicitly as anti-geo-fraud tooling against services like ChatGPT, Netflix, and NetEase Cloud Music.

TSG produces recurring monthly per-application traffic breakdown reports for a Xinjiang deployment, splitting generic protocol buckets (bmff/http2/mpegts) down to specific apps (Kuaishou, Douyin, JD, Vivo services), delivered to the customer.

A weekly '新疆联通流量分析报告' (Xinjiang Unicom Traffic Analysis Report), one of a recurring carrier-specific series also produced for Xinjiang Mobile, shows the same TSG 'overseas APP' server-IP-and-location tracking (BBC, Bigo, Canvas, Discord, ESPN, Facebook, Gmail, etc.) plus domestic APP rankings and QUIC-domain rankings, produced specifically at the China Unicom carrier level within Xinjiang -- direct evidence that TSG's national-scale overseas-app monitoring capability is also deployed and reported at individual-carrier granularity in a specific, named domestic region under heavy surveillance.

Recurring weekly '新疆移动流量分析报告' / '新疆联通流量分析报告' (Xinjiang Mobile / Xinjiang Unicom traffic analysis reports) document a domestic monitoring deployment covering China Mobile Xinjiang (total capacity 4.4Tbps, ~1Tbps actively monitored, observed peak 1275.49Gbps) and China Unicom Xinjiang, breaking traffic into intra-Xinjiang, domestic, and overseas flows and reproducing the same per-foreign-platform (YouTube/Google/Facebook/Twitter/Instagram/Telegram/WhatsApp/etc.) server-IP breakdown used in the national TSG SNI reports, at a carrier-and-province-specific granularity.

Weekly "新疆移动流量分析报告" (Xinjiang Mobile Traffic Analysis Report) and "新疆联通流量分析报告" (Xinjiang Unicom Traffic Analysis Report) documents, produced by an internal "运营商前端分析团队" (Carrier Frontend Analysis Team) and spanning January-July 2023, give carrier-level domestic deployment scale for Xinjiang: China Mobile Xinjiang alone reports 4.4 Tbps total bandwidth / 1 Tbps access bandwidth, with weekly throughput up to 22.73 PB and rate peaks over 580 Gbps. Both reports include a dedicated "国外APP应用概况" (foreign app overview) section enumerating server IP/location for ~29 named foreign platforms (BBC, Discord, Facebook, Gmail, Google, Instagram, Netflix, Reddit, Skype, Telegram, Twitter, Whatsapp, Youtube, Zoom, etc.) alongside domestic app traffic, directly corroborating the taxonomy's Xinjiang domestic-deployment note at the level of two named carriers with concrete recurring cadence.

Weekly '运营商前端分析团队' (carrier frontend analysis team) reports for Xinjiang Mobile (4.4 Tbps total bandwidth, 1 Tbps access bandwidth, 28.86 PB/week throughput) and Xinjiang Unicom (1.88 Tbps total, 880 Gbps access, 12.88 PB/week) break out domestic-vs-cross-border traffic ratios (e.g. Xinjiang-internal-to-overseas traffic 0.83 PB / 2.88% of total for Mobile) and rank the same roughly 30 international platforms (Facebook, YouTube, Telegram, WhatsApp, etc.) seen in TSG's app-classification reports, confirming named carrier-level, multi-Tbps domestic deployments in Xinjiang that specifically distinguish cross-border flows.

Weekly "XX联通/移动流量分析报告" (Xinjiang Unicom / Xinjiang Mobile Traffic Analysis Reports) explicitly name the carrier and report total provisioned bandwidth (Unicom 1.88 Tbps total / 880 Gbps access; Mobile 4.4 Tbps total / 1 Tbps access) with weekly throughput up to 44.26 PB and domestic vs. cross-border traffic ratios broken out per day, confirming Xinjiang-wide, carrier-level DPI deployment at multi-terabit scale across both major carriers.

The galaxy-offline-service monthly-reporting tool generates region-specific traffic statistics for Shihezi (石河子), a city in Xinjiang, broken out by carrier network type (4G/5G/fixed-line) and application protocol (HTTP/SSL/QUIC), confirming a domestic Xinjiang deployment produces granular, protocol-segmented traffic analytics.

China's Xinjiang mobile-network deployment layers an unnamed third-party DPI engine (distinct from TSG's own app-ID) for app classification; when it misidentifies short-video CDN traffic (Douyin/Kuaishou domains) as 'Unknown', Geedge's on-site fix was configuring custom SNI-based app signatures directly in TSG rather than waiting on the third-party vendor.

A dedicated log-ETL pipeline repository named 'xj-log-etl' ('xj' = Xinjiang, per the taxonomy's domestic-deployment notes) lives under the TSG/Galaxy OLAP namespace, indicating a Xinjiang-specific instance of TSG's big-data log-processing pipeline distinct from the generic platform code, corroborating a named domestic (China) TSG deployment location.

A document framed as a patent disclosure ("本发明", "the present invention") describes building a YouTube video-fingerprint database by collecting 1,000 videos across 10 categories from 5 collection sites, pairing MITM-decrypted plaintext video-chunk info (via mitmproxy) with the corresponding encrypted flow captured via tshark, yielding a dataset of 1,000 video fingerprints and 2,493 encrypted video flows; the authors then analyze fingerprint continuity in streamed (non-downloaded) encrypted flows, finding 698 of 2,493 flows (~28%) show missing or duplicated chunks against the fingerprint database.

A MESA Lab repo (shihaoyue/yy_deploy_script) contains an organized suite of active attack tooling specifically targeting encrypted DNS: DoH/DoT downgrade attacks, DoH/DoT DDoS including a CVE-2024-4487 (HTTP/2 Rapid Reset) exploit script, IPv6 DNS response spoofing/injection (fakedns6 using forged-source-address "saddns"), a DNSSEC-downgrade proxy, DNSSEC-DDoS tooling, and an active DNS-fingerprinting probe pair (fpdns_client/fpdns_server under a folder named "TargetGZ"). This is direct evidence of GFW-adjacent R&D that specifically attacks the encrypted-DNS protocols (DoH/DoT) circumvention tools often rely on for resolver privacy.