Findings

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 MESA Lab monthly report describes a 'web-proxy' engineering task that modified the open-source Ultraviolet web-proxy project to add keyword- and specific-URL-blocking, alongside deployment work (certificate issuance, redirect handling) and a document listing which sites the proxy is permitted to relay; the purpose (internal filtered access vs. a broader capability) is not stated in this excerpt.

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.

Sample MAAT rule-table exports (maat_cfg1, dated 2018-06-16/07-10: APP_DOMAIN, APP_POLICY, LIMIT_DOMAIN) show the on-disk schema for MAAT app/domain policy tables — numeric region/group/domain IDs, an app-name field, numeric match flags, and a KEY=VALUE;KEY=VALUE region string carrying APP_ID/DOMAIN_ID — with every sample row using the identical app-name string 'circuitiOS'. The tiny, sequential-ID row count (1-2 entries per table) suggests this is likely test/demo fixture data rather than a live production ruleset, but the repeated app-name string is worth flagging for correlation against known iOS circumvention clients.

pangu_valve.conf explicitly binds the 'PanguValve' traffic-control daemon (阀门, ASMIS_PROC_NAME=Pangu/PanguValve) to the Astana, Kazakhstan (K18) site — REMOTE_DIR=ASTANA and a MAAT_EFFECTIVE_RANGE tag of location=Astana — and configures it to receive live rule updates from a MAAT Redis backend rather than static files, tying this enforcement component directly to a real-time MAAT rule-dispatch pipeline at a named export deployment.

pg_valve_deal.cpp / pg_valve_main.cpp source shows the 'valve' (pangu_valve) component implements a MAAT-fed, hierarchical (region/group -> dataset -> domain-ID) rule-dispatch engine: each incoming rule line carries a keyword field plus expr_type/match_method/is_hexbin matching flags, an ADD/DEL action, and a percentage-based 'Droprate' throttle parsed out of a semicolon-delimited region string (DOMAIN_ID=...;config_id=...;Droprate=...) — i.e. a keyword/domain-based engine that can partially throttle traffic, not just binary-block it.

The same T1/NTC node config (ntcconf/t1conf/main.conf, K18/Astana/Kazakhtelecom) exposes concrete DPI enforcement toggles: a SYNACK_OR_RST switch and SEND_INJECT_PKT flag governing active TCP-response/packet-injection behavior; ASN- and IP-based blocklists (ASN_MAAT, IPD_DYN_MAAT, IPD_STATIC_MAAT) refreshed from MAAT/Redis on a 1-second effect interval; a dynamic blacklist with a 180s timeout; explicit protocol-blocking switches for BitTorrent (DHT/uTP) and eMule (Kad); and TLS metadata harvesting including certificate SAN fields (NTC_SSL_COLLECT, collect_san_sw=1) streamed to a Kafka topic.

The T1/NTC (text-content DPI) node's wired-config manifest (main.conf, dated 2019-01-30) sets REMOTE_DIR=ASTANA/KAZAKHTELECOM/, directly naming Kazakhtelecom — Kazakhstan's dominant state-linked telecom operator — as the carrier context for this K18 deployment. The NTC_MAAT module's EFFECTIVE_FLAG further scopes rules to {location: Astana, isp: Tanstelecom}, naming a second Kazakhstani ISP (Transtelecom) tied to the same deployment.

The tango/adc_hardware repo ([email protected], 2019-2021) contains a dedicated "K18 演示环境交换板配置" (K18 demo-environment switch board config) commit and a nezha_monitor_K18/ directory of NEZHA monitoring dashboards/alert rules for "ADC" hardware. This is direct evidence that Geedge's ADC compute-board hardware line (documented elsewhere as used for the Pakistan/WMS-UTR site) is also deployed for the K18 (Kazakhstan) site.

An 'ADC Hardware Installation and Configuration Guide' (v21.11) describes a modular chassis (Switch Sled, CPU Sled) matching taxonomy's Pakistan/WMS-UTR 'ADC hardware' reference, confirming ADC is a distinct deployed hardware line -- not just a site nickname -- with its own installation documentation separate from the TSG-X/TSG-7400 line.

Beyond VPN/circumvention tools, the same exported signature format is used at large scale for ordinary consumer apps — e.g. a Bank of Communications ('jiaotongyinhang') signature matches four exact-match DNS query names (download1.bankcomm.com, mobile.95559.com.cn, mbank.95559.com.cn, monitor.bankcomm.cn), and other entries (huolala, qidiandushu, zhihu) use the newer dns.qname/ssl.sni/http.host/quic.sni four-vector pattern per app. A companion artifact (70707a230d7d) is a flat list of thousands of specific URL paths (not just domains) spanning news, e-commerce, government-adjacent, and international press sites — consistent with the fqdn_category_list field seen in TSG's session-log schema, i.e. this is categorization/classification reference data, not solely a VPN blocklist.

Exported AppSketch/MAAT signature-object JSON shows named per-VPN detection rules combining multiple independent vectors: CyberGhost's WireGuard variant is matched by a hex UDP-payload pattern (04000000*), destination port 1337, and ip.proto=17 together (signature cyberghostvpn_wireguard); Windscribe's OpenVPN control channel is matched by two offset-anchored hex byte patterns plus an exact 86-byte payload length (windscribevpn_openvpn_payload); and ExpressVPN is matched independently via a literal JA3 hash (ssl.analysis.ja3), FQDN strings (expressapisv2.com, www.expressvpn.works), and a large enumerated IP list (700+ individual ip.dst entries observed before the 200KB text-extraction cutoff).

A dedicated AppSketch/MAAT signature object named 'Psiphon-Volunteer-IP' (signature_id 4054) blocklists specific IPv4/IPv6 CIDR ranges by ip.dst regardless of port (192.122.190.0/24, 2001:48a8:687f:1::/64, 141.219.0.0/16, and more), i.e. Geedge maintains infrastructure-level blocking of known Psiphon volunteer-hosted proxy server ranges rather than relying solely on app/protocol fingerprinting.

A signature object dated 2024-10-28 and named 'VPN servers in Russia' (fqdn variant signature_id 6217, IP variant 6216) blocklists specific FQDNs (api.tap2free.net, vpnlocal.app) and a companion IP-address object, showing Geedge curates geography-scoped VPN-infrastructure collections by country rather than only per-app-brand signatures — i.e. any server identified as VPN infrastructure hosted in a given country can be swept into a blocklist independent of which client app uses it.

An internal ops runbook for setting up Nginx basic-auth on a deployed service gives the literal filesystem path /home/ceiec/bifang/nginx/htpasswd (and the corresponding docker volume mapping), directly tying the 'Bifang' policy-management API identified in the TSG OAM CLI guide to infrastructure branded/organized under 'ceiec' — consistent with this corpus's identification of CEIEC (China National Electronics Import & Export Corp) as an export intermediary for Geedge/TSG deployments.

A 'Druid Historical Data Migration' runbook directs uploading a migration folder to /data/ceiec/ on HDFS server 10.4.61.78, then migrating Apache Druid tables named 'application_protocol_stat' and 'security_rule_hits' from old to new tables — further corroborating a CEIEC-branded analytics/HDFS deployment backing TSG's DPI rule-hit and per-app-protocol statistics pipeline (the same kind of data that feeds the traffic-overview and carrier-analysis reports found elsewhere in this batch).

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.

An exported IP-blocklist object with the literal header format 'IP[Single||/CIDR||-Range]#[Port]' and 5,511 entries, each a single IP with port range 0-65535 (i.e. full-IP block regardless of port), includes 185.220.101.77 — an address in the 185.220.101.0/24 block long associated with Tor exit-relay operators — suggesting at least part of this object targets Tor exit infrastructure by IP rather than by protocol fingerprint.

A second raw, unlabeled IP list (13,786 entries, no header/context) contains dense runs of adjacent addresses within a small number of /24-ish blocks (e.g. multiple 146.66.209.x and 102.129.227.x addresses), a pattern consistent with enumerating a hosting/VPS provider's allocated ranges rather than random targets. Format (flat one-IP-per-line) matches the kind of raw export MAAT's IP-rule policy objects are built from, but this file lacks the labeling seen in 788a452cfa86, so its specific purpose/target list is not independently confirmed from this artifact alone.

A recurring weekly 'Tiangou Secure Gateway — Server IP and Location of Overview' report, spanning Jan 2023 through Jan 2024 in this batch alone, tracks per-app top server IPs/geolocations/bytes for named foreign platforms (Instagram, Netflix, Reddit, Skype, Pinterest, Quora, Line, Likee, Medium, Pandora). Top consumer-side IP rows consistently resolve to Kazakhstan cities (Almaty, Pavlodar, Nur-Sultan/Astana), matching the K18 site codename. Processed-row counts grow roughly 10x over the year (889B rows/week in Jan 2023 to 9.4T rows/week in Jan 2024), and one instance reports Total Bytes Transferred of 14.66 PB and an average of 218.34 Gbps for a single week.

An internal runbook for 'Sentinel EMS' (a third-party HASP hardware/software licensing system) describes generating per-deployment license files (C2V request -> V2C license) and explicitly states the resulting V2C content is cut at the <hasp_info> node and placed into a 'bifang-api service license file template' — i.e. TSG/Bifang feature entitlement per customer site is gated by a Sentinel HASP license file, not compiled in statically, meaning specific capabilities can be selectively enabled/disabled per contract.

In the same live TSG capture, rows show ssl_ech_flag=1 recorded for real observed TLS sessions (to connect-api.guardianapp.com) alongside a populated ssl_ja3_hash and an intact ssl_sni value, and the session was still denied by name-based rule Deny_Brave. This confirms the DPI engine parses and logs the TLS ClientHello ECH extension as a distinct per-session flag in production/test traffic, i.e. ECH usage is visible to the gateway even though SNI in this particular capture was not itself encrypted from the classifier's point of view.

An internal SQL query cookbook targets a ClickHouse-style database 'tsg_galaxy_v3.session_record' with example top-10 breakdowns by common_l4_protocol, common_client_ip, common_server_ip, common_app_id, common_app_label, http_domain, and — notably — common_subscriber_id, plus filtered variants (e.g. by http_domain LIKE '%baidu.com%' or by a specific client IP) using a 1-in-10 sampling trick (cityHash64(common_recv_time) % 10 = 0). This names the internal analytics database and confirms subscriber-level session records are a standard, first-class query dimension, not an edge case.

The 'TSG OAM CLI User Guide' (v0.81) and companion 'TSG MIB Specification' describe the TSG-X hardware as four CPU sleds (MCN) plus one switch sled (MXN) running a CentOS-based command shell (tsg_policy, tsg_policy_object, tsg_record, tsg_show, tsg_diagnose), reachable via SSH, where policy queries/enable/disable and policy-object import/export are proxied through an internal 'Bifang API'. The tsg_show command has a dedicated --intercept flag documented as showing 'interceptable and blocked traffic information', confirming interception/blocking status is a first-class, directly queryable operational state on the device.

Raw TSG session_record CSV exports (header row `recv_time,log_id,decoded_as,session_id,...`) show a ~224-column per-session logging schema that goes far beyond blocking metadata: subscriber_id/imei/imsi/apn/phone_number identity fields, full DNS query/response, HTTP with a cleartext mail_password field for mail protocols, TLS JA3/JA3S hashes, cert issuer/subject, ESNI/ECH flags, SIP/RTP VoIP metadata, SSH hassh fingerprints, RDP client details, and cryptocurrency-mining (stratum) protocol detection. This is a general-purpose deep-inspection/logging pipeline, not a narrow blocklist filter.

Live TSG session logs from an internal test/QA gateway (device_id 9800165603191146 / 21426003, data_center label XXG-TSG-BJ) show real sessions from named commercial VPN apps — AlohaBrowserLite, BeePassVPN, BravePrivateVPN (WireGuard), Proton VPN, Turbo VPN, CyberGhost, BetternetVPN, SuperUnlimitedVPN, TrustzoneVPN and VPNHero — each matched to a dedicated per-app security rule (e.g. Deny_Brave, Deny_BeePassvpn, deny_Super Unlimited VPN) and given security_action=Deny. One row's app_transition field records a layered classification chain 'Psiphon Provider' -> ... -> 'BravePrivateVPN' for a single session, indicating the engine attempts nested/tunnel-in-tunnel protocol identification, not just single-label app ID.

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.

An internal TSG 3.0 upgrade runbook specifies deployment directory conventions literally namespaced to "ceiec" (/data/ceiec, /home/ceiec, and a service-backup path /data/ceiec/update/0908/组件名称), alongside TSG-generic paths (/home/tsg3.0-volumes/, docker-compose services renamed from /home/test to /home/galaxy, a Nacos service-config registry, and a note that version 21.09 needs Kafka authentication integrated) — corroborating CEIEC as an actual deployment-branding identifier in TSG's own ops tooling, not just a contracting-paperwork name.

A Sentinel HASP software-license XML file names "CEIEC" as the licensed organization (type "Evaluation"), with the license's embedded HASP feature blob (v2c field) containing readable product-SKU strings "TSG-Web-Sketch-DB- Subscription", "TSG-App-Sketch-DB-Subscription", "TSG-App-Sketch-Engine", "TSG-App-Sketch", "TSG-WANNAT", "TSG-Proxy", and "TSG-CM" — direct primary- source evidence of a CEIEC-licensed TSG deployment naming the specific licensed product modules. This does not by itself identify which end customer/country CEIEC was reselling to for this particular license.

A custom Prometheus-backed infrastructure-monitoring platform (MySQL schema dumped from source "nz-prometheus", schema "nz-temp", dated 2020-10-16) has its sys_area reference table seeded with exactly the five Kazakhstan cities named in the K18 site-codename entry — Aktau, Almaty, Nur-Sultan (the pre-2022 name for Astana), Karaganda, and Zhezkazgan — and a companion live alert-message dump (dated Nov 2020) shows real "endpoint down" P2 alerts tagged Data center: Nur-Sultan / Aktau, Project: ADC, across modules named MXN-NODE and MCN0-3-NODE/SRV, pushing the earliest confirmed evidence of the K18 Kazakhstan deployment back to at least October-November 2020.

A MAAT/AppSketch signature literally named "Psiphon-Server-IP" blocks by destination IP against a list of 1,300+ IPs (the extracted text is truncated at ~200KB so the true list is likely larger, consistent with the taxonomy's cybernarrator/vpn-thwarting note of ~70-73K harvested Psiphon IPs), directly corroborating that the CyberNarrator/vpn-thwarting Psiphon3 IP-harvesting pipeline feeds its output straight into a production MAAT/AppSketch blocking signature.

The TSG System Installation Manual (dated 2021-05-28) documents a three-component architecture — ADC (distributed cluster, policy enforcement/traffic processing), OLAP (log analytics, standalone or cluster mode), and CM ("Central Management", the policy UI) — with policy pushed from CM to ADC devices and ADC-generated logs aggregated via Kafka for OLAP analysis. Baseline per-node hardware requirements are 24+ CPU cores, 32GB+ RAM, 2TB disk, 1Gbps NIC, on CentOS 7.4.

The same 224-column TSG per-session log schema carries a full TLS- interception field set — proxy_pinning_status, proxy_intercept_status, proxy_passthrough_reason, proxy_cert_verify, proxy_intercept_error, sc_rsp_raw and sc_rsp_decrypted (raw vs. decrypted server response content) — plus ssl_esni_flag and ssl_ech_flag (explicit ECH/ESNI-usage flags), ssl_ja3_hash/ssl_ja3s_hash, and ssh_hassh (SSH client fingerprinting), confirming certstore-style MITM interception, ECH/ESNI detection, and TLS/SSH fingerprinting are all first-class fields logged on every session, not experimental add-ons.

TSG's core per-session log schema (a 224-column CSV export, four near- identical copies in this batch) includes subscriber-identity fields — subscriber_id, imei, imsi, apn, and phone_number — directly alongside the standard 5-tuple/app-classification fields in the *same* record, meaning every inspected session is natively correlated to a subscriber identity by design, not as a bolted-on side system.

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.

MAAT/AppSketch signatures "turbovpn_udp_payload1"/"turbovpn_udp_payload2" detect Turbo VPN by matching a literal hex-encoded ASCII string in the UDP payload — keyword "$747572626f76706e0a00" decodes to the plaintext bytes "turbovpn\n\x00" — plus a second offset-anchored byte pattern, meaning Turbo VPN's own protocol handshake leaks a recognizable, unencrypted magic string that the DPI engine matches directly rather than needing any statistical or behavioral analysis.

MAAT/AppSketch signatures "hotspotvpn_ja3" and "ultrasurfvpn_update_behavior" identify Hotspot VPN and Ultrasurf specifically via static JA3 TLS ClientHello hashes (e.g. f49621211538d12435b8498f195d0c31 for Hotspot VPN; 706ea0b1920182287146b195ad4279a6 and 1f0d8bb4fab11dc335dec2e69da0c36e for Ultrasurf), in Ultrasurf's case combined with an AND-condition on a set of legitimate-looking cover domains (skype.com, msn.com, microsoft update domains) — showing the DPI engine defeats Ultrasurf's domain-mimicry cover by fingerprinting the underlying TLS stack instead of trusting the SNI/host.

The batch contains 200+ individual MAAT/AppSketch signature JSON files, most defining FQDN- and/or destination-IP-based blocking rules for a single named commercial/consumer VPN app each (LetsVPN, TurboVPN, QuarkVPN, PandaVPN, StarkVPNReloaded, VPNTurkey, BitdefenderVPN, SnapVPN, SuperSpeedVPNProxy, SuperUnlimitedVPN, CafeVPN, and dozens more), each carrying a build date — the dated files span June 2024 through November 2024 — showing a large, actively and continuously maintained per-app VPN signature catalog rather than a static blocklist.

A MAAT/AppSketch signature named "WARP on CF Edge" identifies Cloudflare WARP by matching destination IP against Cloudflare's published WARP anycast CIDR ranges (both IPv4, e.g. 162.159.192.0/24, and IPv6, e.g. 2606:4700:d0::/48) AND IP protocol UDP (ip.proto=17), while explicitly excluding destination port 443 (not_flag on a dstport=443 condition) — implying a separate rule is needed to catch WARP traffic that uses port 443.

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 design doc for a DNS/proxy gateway hosted at a public IIE-branded DoH endpoint (iie-public-doh.com) force-resolves the domains of ~40 target websites to a non-transparent SNI-routing proxy (which reads the ClientHello SNI without decrypting) while all other domains resolve normally; an 'open target resource discovery' module actively crawls each target site with a headless Chrome driver to map its dependent resource domains and assess their domestic-vs-overseas availability, feeding the allow-list.

A 2023 master's thesis from the Institute of Information Engineering, Chinese Academy of Sciences (MESA Lab's parent institute) develops an online encrypted-video-stream title identification method using response-time distribution and chunk-fingerprint matching that survives CDN node switching, reporting 96.19% title-identification accuracy using only 6 observed video chunks, without decrypting traffic.

A user manual for a 'Malicious Service IPv6 Address Discovery and Assessment System' documents a sapp application-layer plugin (ipv6_domain.c) that extracts the HTTP Host header, TLS SNI, and DNS AAAA-record domain from live traffic and matches them against a malicious/blocked-domain list to resolve each hit's IPv6 address, alongside a separate active-probing pipeline (ZMapv6 + Entropy/IP-based address-space generation) used to discover IPv6 DNS resolvers and malicious-site IPv6 presence at internet scale.

MESA Lab internal debugging notes give the concrete sapp/MAAT config paths and JSON rule schema used for IP-based blocking: /home/mesasoft/sapp_run/TF_conf/TF_tableinfo.conf defines an IP_REGION_INFO table type (ip_plus) with a do_blacklist flag, matched against src/dst IP+port ranges.

Two 2023 self-test reports (one co-signed by the Institute of Information Engineering, Chinese Academy of Sciences) describe a dedicated capture appliance, hardware model MESA-NF-3100 (2U, Xeon E5-2640V4, 256GB RAM, dual XL710 10GbE NICs, 8Gbps/device and 20-27Gbps/cluster), whose mirror-capture driver is started via `systemctl start mrzpd` (mrzcpd) alongside the sapp process, feeding a downstream 'nirvana_server' component.

An internal task list shows sapp being ported to run on domestic ARM hardware (Huawei Kunpeng) as part of a 'domestic substitution' (国产化) effort, and separately being tuned for 100G commodity NICs — reaching ~30Gbps per instance in testing after swapping in the mimalloc allocator for a reported ~10x multi-threaded allocation speedup.

Geedge Networks' official 'Confidential and Proprietary' sapp developer manual documents sapp's platform-provided packet-injection API available to any business plugin: MESA_kill_tcp (crafts and sends a TCP RST matching the current flow's 4-tuple/sequence to force-terminate a TCP stream), MESA_kill_tcp_synack (sends a forged SYN/ACK in response to a client's SYN so the client cannot complete a handshake with the real server), and MESA_inject_pkt (injects arbitrary application-layer data into either side of an established flow).

A subsystem design doc describes an outbound proxy gateway for identity-authenticated users that performs IP access control, extracts the destination domain from the ClientHello SNI (without decrypting), resolves it via an overseas DNS server, and rewrites the destination IP to route traffic abroad through a 'dedicated network' — defaulting to a WireGuard VPN interface (wg0) and falling back to a 'covert network line' via a SOCKS5 proxy when the VPN line's bandwidth cap is exceeded.

A thesis-project assignment for hidden-service (VPN/Proxy/Tor) identification via heterogeneous graph neural networks on flow logs sources its one day of training data from a database explicitly named 'tsg_galaxy_p19' — tying the internal TSG naming convention to the taxonomy's P19/WMS-UTR Pakistan site codename — accessed over an internal 'Information Harbor' (信息港) VPN, with ground-truth hidden-service IP labels supplied by the commercial IP-intelligence service spur.us.

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.

An internal app-fingerprint engineering document (identical content filed under two separate artifact ids) catalogs precise per-action (login/create/upload/ download/share/delete) DNS, SNI, and certificate-CN signatures for identifying use of specific cloud-collaboration apps from traffic alone, covering foreign platforms Zoom and Office365 alongside domestic apps (Huawei WeLink, Feishu, DingTalk, WeCom, Shimo Docs, CSTCloud drive), using tools like myssl.com for active certificate/IP verification of each signature.

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.

A MySQL dump of a TSG admin-panel dictionary table (sys_dict) contains an 804-row "出入口应用程序列表" (Ingress/Egress Application List) enumerating classifiable applications by internal code name, including explicitly named VPN/circumvention tools wireguard, hotspot_shield, windscribe, expressvpn, browsec_vpn, skyvpn, barracuda_vpn, anonytun_vpn, and others -- i.e. a master admin-facing catalog of apps (including VPN protocols/brands) available as classification/policy targets across the platform.

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.

The appsketch-works/device-api ("env-api") repo implements a REST/WebSocket-controlled Android device farm -- ADB shell control, droidVNC-NG remote display, APK install/run via Ansible-style "playbooks", and per-app-package tcpdump capture (with a dedicated fix to filter captured traffic by package name) -- matching the technical infrastructure implied by AppSketch Works' "Feature Factory" role of extracting app/VPN signatures from real device traffic.

AppSketch Works' asw-controller service (net.geedge.asw, 271 commits) implements a full automated signature-extraction pipeline: it tracks app source/releases via git (BranchController, MergeRequestController, ApplicationReleaseEntity), provisions remote/virtual Android 'Environment' instances with noVNC and terminal WebSocket access so a human operator can drive the app, captures the resulting traffic to pcap (PcapController, PcapParserThread), runs Playbook-scripted analysis integrated with Zeek and WebShark (ZeekClient, WebSharkClient), and produces versioned per-app DPI signatures (SignatureExtract.java, SignatureUtil.java -> ApplicationSignatureEntity).

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.

Commit history for the K18 (Kazakhstan) argus-ntc console reveals its concrete feature set: a scheduled "网页关键字定时器" (webpage-keyword timer/scheduler) for keyword filtering, ASN/IP block-list configuration pages, a "BGP泛收" (BGP wide-collection) page, an SSL-interception config toggle, a file-scanning results page with MALWARE TYPE/MALWARE NAME columns, app-identification entries including a WhatsApp rename, and a VoIP business-config approval workflow, with blocking actions relabeled from "阻断" (block) to "封堵(丢弃)" (interdict/drop).

At a Pakistan site (P19/MSH), Geedge identified that TCP RST-injection for a Deny action fails on asymmetric ('unidirectional') flows because the synthetic RST packet lacks GRE callid/routing context only present when both directions transit the same node. Two fixes are in progress: a dedicated third-layer packet-injection route, or a cluster-wide coordination mechanism ('SwarmKV') that syncs which policy a session matched across nodes so each node can independently inject its own side's interference packet.

Raw TSG session-log CSV exports from device group XXG-TSG-BJ (a Beijing test/demo box, security rule list labeled "Demo 0625") show live enforcement: sessions to VPN client backends are matched by app-transition signatures such as BeePassVPN_Patch01/02/04 and BetternetVPN_Patch08_20240929, tagged with security_rule_list "Deny_BeePassvpn" and security_action "Deny" — i.e. TSG identifies specific patched VPN client app builds and actively drops the session, not just logs it.

sapp's own regression-test pcap corpus (public_resources/benchmark_pcap) includes an "escape_gfw" test directory explicitly named after Intang, an academic GFW-evasion tool (TTL-difference segment injection, TCP tuple4/sequence reuse tricks), plus explicit DoH and DoT protocol samples — evidence MESA Lab tests sapp's TCP reassembly/detection logic against published circumvention research to harden against it.

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.

The 'Tsg_Galaxy_v3.0' deployment bundle ships built Flume interceptor plugins (FlumeRadiusOnOffInterceptor, FlumeSubscriberInterceptor, FlumeDynamicInterceptor) as operational binary artifacts alongside a full set of per-protocol traffic-content collectors -- DNS/FTP-doc/HTTP-doc/Mail/SSL/Telnet -- that feed ClickHouse via Flume and gohangout, confirming these RADIUS/subscriber-correlation interceptors are deployed in production as part of TSG Galaxy v3.0's full-protocol content-capture pipeline.

Geedge's shared build-environment Docker image (MESA_Platform/build-env) bakes in a binary "shelling"/packing step for TSG executables and shared libraries, configurable via a "die_at_expiration" option (self-destruct on license/time expiration) read from a config file, and a separate commit explicitly strips --debug/--memdump flags from packed production binaries.

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.

Ethiopia (E21) customer specifically tested Melon VPN and Ultrasurf against TSG; Ultrasurf's frequently-rotating IPs required an updated signature (successfully blocked after update), while Melon VPN's connection succeeded but was non-functional for other reasons (not attributed to TSG blocking).

The same author (modikai) also authored modikai/cache_prober, a single-commit repo containing dns_prober.go -- naming indicative of a DNS-resolver cache-probing/cache-snooping tool, a reconnaissance technique for inferring which domains a target resolver has recently queried.

Crash-dump stack traces reveal TSG's core packet-processing engine (sapp) architecture: a custom multi-threaded C engine using 'marsio' as the DPDK-style packet-I/O driver, a plugin system for protocol handlers (confirmed: plug/protocol/http/http.so), and a libdocumentanalyze component that actively decompresses gzip content and parses ZIP/document formats found inside HTTP bodies -- i.e. inspection goes beyond headers into reconstructed application content.

Confirms the full licensed TSG component roster deployed at Ethiopia (E21): Firewall, Digital Observer, Email Retention, Statistics Policy, Proxy, Session Record, GTP Security, AppSketch, AppSketch Engine, AppSketch DB, WebSketch, WebSketch DB. Several license terms were extended to expire 2091-12-31, indicating a multi-decade commercial commitment.

A 616-entry keyword list of URL/API paths (e.g. "index.php/index/ajaxlogin", "api/User/login", "user/signup") targets login/registration endpoints across a large number of distinct web backends, demonstrating HTTP-path-level keyword-filtering signature capability at scale; the specific target set looks oriented at domestic app/site fingerprinting (loan/gambling-adjacent path names appear) rather than confirmed circumvention-tool targeting, so attribution of intent is uncertain.

A companion recurring report family, "Tiangou Secure Gateway — Server IP and Location of Overseas APP", automatically compiles TOP10/TOP50 server-IP-and-geolocation tables per major Western platform (BBC, Discord, Facebook, Gmail, Google, Hulu, ESPN, Messenger, etc.), i.e. an automated pipeline for building IP-block target lists against specific foreign services from observed traffic, generated on a similar recurring cadence.

An internal MESA Lab research survey ("审查规避调研报告") catalogs current academic circumvention research the lab tracks as detection R&D input: Geneva/GET-out packet-mutation evasion, the WebRTC-based Protozoa tunnel, and CDN-based domain shadowing combined with domain fronting -- evidence the lab actively monitors the circumvention literature rather than working purely from first principles.

An internal TSG troubleshooting runbook ("HTTPS证书替换策略无效果") documents the certstore MITM-certificate service actively serving/validating forged certificates keyed by SNI, walking an operator through checking certstore logs for specific real-world domains including Google's update service (update.googleapis.com) and Nvidia's GFE service (services.gfe.nvidia.com), and cross-checking keyring config live via maat_redis_tool.

certstore's own commit history documents its transparent-TLS-MITM mechanics directly: it writes the client's observed SNI into the SAN field of the leaf certificate it mints on the fly, supports ECC issuance (secp192r1/secp256r1) for those forged certs, and reads its Trusted/Untrusted decryption-keyring configuration from MAAT's DECRYPTION_KEYRING table -- confirming the interception pipeline end-to-end: client SNI in, matching forged certificate out, gated by MAAT-synced keyring policy.

Geedge runs an explicit, named signature-extraction program specifically targeting circumvention tools — Freegate, Psiphon, Ultrasurf, and Tor Browser (by package name: com.golden.freegate, com.psiphon3.subscription, us.ultrasurf.mobile.ultrasurf, org.torproject.torbrowser) — across Android/iOS/Windows, with weekly signature updates, for a site internally called 'K project'.

tsg/cli-deploy is an Ansible deployment repo for "tsg-cli" host monitoring (tsg-monitor service, rsyslog forwarding) targeting named production hosts, including hosts.astana and astana_ADC_IPlist_V1.xlsx, with a commit explicitly adding "astana部署环境IP" (Astana deployment-environment IPs) and a later branch for reading ADC hardware chassis IDs into the device serial-number scheme — concrete deployment evidence for the K18 (Kazakhstan, Astana) site.

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 Geedge internal automation service (wangwei/cn-object-scheduler, package com.geedge, CnPolicySchedulerApplication with FqdnScheduler/IpScheduler) periodically pushes named VPN-service objects into TSG's blocking policy store; commit history explicitly names Psiphon3, Windscribe VPN, and Ivacy VPN server-name objects being added or corrected, and one commit changes FQDN matching from exact to substring match.

cyber-narrator/cn-web (1183 commits) is CyberNarrator's Java Spring admin web application ("cn-admin", package net.geedge), containing a "galaxy" module (GalaxyProxyController/GalaxyResolveController) used to proxy/resolve queries, a BI-style "panel" visualization subsystem, and license-gated access control (LicenseInterceptor/LicenseService) — indicating each CyberNarrator deployment is licensed per-site/customer and depends on a "galaxy" service also seen backing other MESA web tools.

The "comm_audit" (通信审计, communications audit) C++ tool ships a country-specific MaxMind GeoIP database file, db/Kazakhstan_v4.mmdb, alongside generic all_ip_info_v4.mmdb/all_ip_only_coun_v4.mmdb databases, directly tying this MESA Lab traffic-audit component to a Kazakhstan deployment (matches the K18 site codename).

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 master's thesis-in-progress supervised within this ecosystem (advisor 杨嵘, senior engineer) is explicitly tied to the national key R&D program "海量公害 网页、图片、视频流量识别技术" (massive nuisance webpage/image/video traffic identification technology) and a VoIP engineering project; it builds cross- platform (YouTube/Facebook/Bilibili) encrypted-video identification that matches a single per-video traffic fingerprint across different CDNs/resolutions/codecs via trend-similarity, fuzzy-search, and meta-learning matching, explicitly framed around detecting "非法视频" (illegal/harmful video) spread across platforms.

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 "cyberghostvpn_servername" signature detects CyberGhost VPN by matching DNS query names against a list of the provider's own predictable backend node hostnames (e.g. blade6.singapore-rack456.nodes.gen4.ninja, blade5.frankfurt-rack486.nodes.gen4.ninja), showing the censor harvests and enumerates a VPN vendor's internal infrastructure-naming convention rather than relying only on client-facing domains.

'fj-transform-api' (CyberNarrator, ticket prefix CN-) implements CallingStationID-to-IP correlation via ClickHouse (CN-927), resolving monitored network sessions to a RADIUS Calling-Station-ID (subscriber phone number) -- direct source-level confirmation of the subscriber-identity correlation capability described in the leak's CyberNarrator sales materials.

A GitLab-group repo literally named "cyber-narrator" (license-admin-api) implements a dedicated license-administration API for the CyberNarrator product using HASP hardware-dongle licensing (HaspUtil.java, HaspStatusEnum.java, C2V generation), confirming CyberNarrator is packaged/licensed as a distinct commercial component with its own entitlement-check service separate from core TSG licensing.

The same GEEDGE employee handbook dates the launch of 网络叙事者 (CyberNarrator) to April 2021, and separately states the company's products serve 18 data centers and carriers worldwide processing over 20 Tbps of traffic — the first primary-source confirmation of CyberNarrator's launch date and a company-stated global deployment-scale figure.

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.

The 'fj-transform-api' service (ticket prefix CN-, matching the leak's internal 'CyberNarrator' codename) automatically pushes learned Psiphon3 server IPs as blocklist 'IP Object' entries into TSG's policy system on a recurring schedule, and separately manages 'KeywordsObject'/'KeywordsSource' entities pushed to the same TSG backend -- an automated circumvention-tool-IP-to-blocklist pipeline, adapted for TSG v24.02.

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 one-line SQL statement ("delete from pxy_exch_intermedia_cert where cert_id =219;") confirms the MITM certificate-interception service (certstore) persists its per-connection intermediate certificates in a relational database table named pxy_exch_intermedia_cert, keyed by cert_id — concrete corroboration of certstore's cert-lifecycle storage backend at the schema level.

A TSG management-UI format-reference doc enumerates every native blocklist/policy-object import type: IP (with CIDR/range and port-range), FQDN, URL, Account (email address), Subscriberid, and Keywords/HTTP-Signature (matched against User-Agent, Cookie, Set-Cookie, or Content-Type headers, with optional hex-encoded byte patterns) — confirming Subscriberid is a first-class, directly importable policy-matching key alongside network-layer identifiers.

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.

An internal reference JSON enumerates known commercial VPN protocol/port/cipher combinations (L2TP:500 UDP, IKEv2 with remote-id "vpn.ipvanish.com", PPTP:1723, SSTP:443 AES-256-CBC, OpenVPN on 443/1194 UDP+TCP and additional non-standard ports like 8443, each with scramble-related fields for obfuscated variants) — functioning as a lookup table of known VPN-protocol fingerprints feeding signature development.

An update-alternatives install script for mrzcpd (path /opt/tsg/mrzcpd/...) enumerates its full binary/service set: mrzcpd, mrtools-pinfo, mrpdump (packet dump), monit_stream/monit_device/ monit_obp, mrmarch, dpdk-hugepages.py/dpdk-devbind.py (DPDK NIC binding), and systemd units including mrapm_device/mrapm_stream/mrapm_obp and mrtunnat — confirming mrzcpd is a DPDK-based packet-capture-and-injection agent with a dedicated tunnel/NAT offload component (mrtunnat).

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.

A session-log export identifies "botim" VoIP/VPN app traffic over UDP to Cloudflare anycast IP 162.159.192.9, alongside separately-logged traffic to "engage.cloudflareclient.com" (Cloudflare WARP's registration endpoint) on port 2408 (WARP/MASQUE), from client IP ranges consistent with an African mobile carrier — indicating the app-ID pipeline distinguishes Botim's own protocol from generic Cloudflare WARP tunneling on the same destination infrastructure.

Direct dated evidence (July 2023) that the Ethiopia (E21) customer actively toggles application-level blocking as a live policy lever: lifting the block on YouTube plus four other apps caused a documented traffic surge and device alerts at the BOL-IGW site.

Real TSG session logs from device "XXG-TSG-BJ" (Beijing) show live production blocking of named commercial VPN apps by app-signature: 206 of 213 sampled sessions carry security_action "deny_quarkVPN01" against app field "quarkVPN0622.quarkVPN0619" (destination IPs in Germany, Russia, US, Australia, Bangladesh); a second log from the same device shows security_action "Deny_BeePassvpn" against app-identified BeePass VPN traffic.

A raw TSG session-log export shows the full production log schema: per-flow fields include subscriber_id, imei, imsi, phone_number and apn alongside ssl_ja3_hash/ja3s_hash, ssl_esni_flag, ssl_ech_flag, quic_sni, dtls_ja3_fingerprint, and proxy_pinning_status/proxy_intercept_status/ proxy_cert_verify fields for the MITM proxy path. This confirms TSG's session logging natively joins network-flow identity to subscriber identity and captures TLS fingerprint/ESNI-ECH state and MITM-interception outcome in the same record.

TSG implements heuristic tunnel-protocol detection distinguishing Teredo (IPv6-over-UDP, default port 3544) from GTP tunneling based on UDP payload inspection, used to decide 'innermost' session attribution for firewall matching.

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 single AppSketch/MAAT-format signature bundle for "JumpJump VPN" (app_id 15172, characteristics "evasive,widely-used,tunnels-other-apps", deny_action method "drop") defines six independent detection surrogates: FQDN lists (including specific CloudFront distribution hostnames and *.cloudfront.net + a fixed 517-byte first-packet-length side channel), a hex-encoded HTTP tunnel payload signature, an HTTP "getNodes" API-path signature, and an HTTP/2-connection-preface byte pattern ("PRI * HTTP/2.0...SM") used to fingerprint the app's TLS-disguised tunnel.

A master AppSketch-format signature file mixes hundreds of domestic-app identification rules (iQiyi, JD.com, Tencent, Xiaomi Store, China Construction Bank, China Merchants Bank, Postal Savings Bank, Baidu Netdisk, government tax/medical portals) with foreign-VPN detection rules (BeePassVPN, BetternetVPN, BigMamaVPN, BravePrivateVPN, JumpJumpVPN, QuarkVPN, SecureVPN, VPNHero, VPNLite, VPNTurkey, etc.) inside the same rule framework and file, confirming VPN/ circumvention-tool detection is built on the identical general-purpose app-ID engine used for ordinary commercial app traffic classification, not a separate subsystem.

An internal risk memo, "Signal审查规避模式阻断风险说明" (Signal circumvention-mode blocking risk explanation), documents that after the operator pushed a "Deny Signal APP" policy, users with Signal's censorship-circumvention (domain fronting via Google infrastructure) enabled could still send messages/files; packet capture showed the fronted traffic used Google SNIs (clients3/4.google.com, inbox.google.com, android.clients.google.com, www.google.com), and the team built a targeted FQDN+JA3+payload signature specifically to block this fronted traffic while flagging a residual risk of false-positive blocking of legitimate Google services.

A 69-entry all-port IP blocklist ("/32#0-65535", i.e. block every port on the exact address) targets specific IPs on Cloudflare (104.16.x/104.18.x/104.21.x), Microsoft Azure (13.x/20.x/40.x/ 52.x/65.52.x), and Alibaba/Tencent-adjacent cloud ranges (47.x, 8.210.x) — i.e. individually pinpointed IP-level blocking against specific hosts on major CDN/cloud infrastructure rather than blanket ASN blocking, consistent with targeting specific circumvention-service endpoints hosted on shared cloud IP space without collateral-blocking the whole provider.

"realtime_protection" (EnderByEndera/realtime_protection) is a Spring Boot "指挥系统" (command-and-control system) that generates dynamic/static blocking rules and DDoS-mitigation commands as tasks dispatched to multiple field sites ("局点"), tracking per-site command status, whitelist hits, and full command history — architecture consistent with centralized, auditable enforcement-command dispatch across TSG deployments rather than a single-site tool.

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.

Recurring automated "Tiangou Secure Gateway — SNI Report of Overseas APP" documents (weekly, multiple recurrences across 2023-2024) enumerate every distinct QUIC.SNI/SSL.SNI/HTTP.Host value observed per major foreign platform (Netflix, WhatsApp, Telegram, Twitter, YouTube, Signal- adjacent services, etc.) with packet/byte counts, processing runs at up to ~6.3 trillion rows per report. QUIC SNI is tracked as a distinct column from TLS SNI, showing the pipeline separately fingerprints HTTP/3 traffic.

The qiuyuqi/diamondv repo ("DoH探测系统搭建教程" -- "DoH detection system setup tutorial") implements a multi-round active-probing pipeline that performs recursive-DNS/nameserver-side discovery of candidate resolver IPs nationwide, fetches and analyzes their TLS certificates, classifies them by ISP/province, and visualizes results on China/world maps across at least four probing rounds -- an internet-wide active-probing system for discovering DNS-over-HTTPS-capable servers.

The zhuyujia/diamondv repo (branch "DoH_Scan") documents at least four rounds of systematic DoH-resolver and recursive-DNS-server discovery scans by IIE/MESA-Lab-affiliated researchers, with a companion DNS-probing tool (modikai/dtool: cache/rdns/record probers) and a commit explicitly labeled "upload corresponding egress servers", indicating the same effort also catalogs discovered egress/exit-node infrastructure alongside DNS-resolver reconnaissance.

The "diamondv" project runs active internet-wide scans for DoH-capable and recursive DNS servers (dedicated DoH_Scan and rdns_scan branches) and separately catalogs IPv6 addresses discovered via authoritative NS queries, indicating MESA Lab actively maps encrypted-DNS and IPv6 DNS infrastructure.

The galaxy/tsg_olap/dll-multipoint-aggregation repo defines a Flume-based multi-site log-aggregation pipeline with five parallel categories -- "active_defence", "connection" (call-detail/通联日志), "proxy", "security", and "radius" -- the last explicitly ingesting RADIUS data, corroborating that the CyberNarrator subscriber-correlation capability's RADIUS feed sits inside this broader TSG OLAP log-aggregation architecture rather than as a standalone system.

Acceptance-test cases for an unnamed internal system show it curates 10,000+ DNS rules tracked for 30+ days each, runs hourly business-anomaly detection and bot-vs-human traffic classification per flagged domain (target accuracy/recall ≥80-95%), and maintains a resulting "abnormal IP" blocklist database of 2,000+ entries — an automated domain/IP flagging pipeline structurally similar to (but not confirmed identical to) the taxonomy's CyberNarrator blocklist-building pattern.

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.

A MESA Lab research project (wujiating/fingerprinting) builds a DoH (DNS-over-HTTPS) traffic fingerprinting pipeline: captured pcaps of DoH sessions from Chrome/Firefox/Edge on Windows10/Ubuntu, packet-timing/size feature extraction via tsfresh, and an n-gram classifier — ML-based traffic analysis to identify DoH usage and likely client browser/OS from traffic shape alone.

A 2020 MESA Lab monthly report describes building an encrypted-DNS gateway device and a self-hosted DoH server that was wired directly into a live "TSG platform WAN net interface", alongside a passive DoH-service-discovery pipeline that found 39 new DoH-serving domains in a single day of backbone ("科技网") traffic; a related note documents actively probing known DoH-serving IPs' upstream resolvers via a proxy network across 196 countries to check which still function.

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 MESA Lab domain-classification tool (zhangshuo1/domain-classification) maintains curated domain lists under category labels including "porn" and "business", plus CDN and URL domain lists, for feeding into content-category-based filtering decisions.

The tsg/dp_telemetry_app repo is a data-plane telemetry agent that loads MAAT-sourced rules (maat.c/maat.h, etc/dp_telemetry_rules.json) including BPF filter expressions, and on a match exports full packet captures (pcapng) plus MessagePack-encoded session telemetry over Kafka -- i.e. a MAAT policy match can trigger targeted, per-session raw packet capture, not just a pass/block decision.

An internal "DPI Benchmark" methodology document names the three production components underlying TSG's DPI stack and proposes benchmarking each against open-source equivalents: Marsio (DPDK-based packet I/O) for receive/transmit, Sapp ("网络安全开发平台", a high-speed traffic-processing platform) for protocol parsing and flow-table management, and Maat (Hyperscan-class signature engine with Redis-based multi-machine config sync) for pattern scanning.

An IIE CAS thesis revision memo shows a student's research was retitled from "measuring evasion attacks against censorship middleboxes" to "evasion-attack traffic generation for DPI middleware" after committee feedback that "censorship middlebox" was too sensitive a term; the work builds evasion-generation tooling (citing Geneva's genetic-algorithm and SymTCP/Alembic's symbolic-execution approaches to TCP state desync) and explicitly tests it against "a specific country's DPI middleware" plus open-source DPI/NIDS, then derives defensive recommendations from the vulnerabilities it discovers.

A 2024 MESA-team-supervised MS thesis ("面向DPI中间件的探测行为检测关键技术研究") builds detection of both measurement-oriented and evasion-oriented probing directed AT DPI middleboxes, using source-IP statistical features, with the stated goal of reducing the middlebox's resource consumption/exposure of characteristics under such probing and preventing DPI-middlebox function failure -- i.e., defensive hardening against exactly the class of academic censorship-measurement and evasion-search techniques (Censored Planet/GFWatch-style probing, Geneva-style automated evasion discovery) cataloged in this lab's own literature survey (see 2026-mesa-censorship-research-survey-f8c349).

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.

TSG's blocking of YouTube/Facebook/Twitter/Tencent at Ethiopia's IGW nodes fails for a large fraction of sessions because those sessions structurally never traverse the inspection point — quantified per-site traffic-completeness rates ranged from 0% to 40% (vs. ~100% completeness at the upstream PE node), with roughly half of sampled YouTube/Facebook sessions missing entirely from IGW-side logs. Root cause was traffic-splitting/mirroring architecture, not a detection failure of the DPI engine itself.

Ethiopia's INSA (Information Network Security Agency, the state cybersecurity/intelligence body) is named as the end-customer/oversight authority for the E21 TSG deployment — Geedge staff prepared formal incident reports specifically for INSA leadership after operators publicly complained about failed YouTube/Twitter blocking.

Under peak traffic (~700K logs/sec vs. normal ~450K/sec), Ethiopia's TSG deployment's log-aggregation pipeline (Kafka/Flink) dropped roughly 30% of session logs due to load imbalance across nodes, meaning session visibility during traffic peaks is measurably incomplete, independent of the detection engine's accuracy.

A certificate-issuance repo (luwenpeng/certificate, commit "TSG-8365 为TSG/Nezha界面的服务端签发证书" = "issue server-side certs for the TSG/Nezha interface") contains config, CSR, key, and crt files explicitly named "-for-e21" (ca-root-for-e21.conf, tsg-entity-for-e21.crt, nezha-entity-for-e21.key), confirming an internally-issued PKI hierarchy used for encrypted communication between TSG and its "Nezha" management-web-interface components at a site tagged E21 (Ethiopia).

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.

The same sapp.toml exposes the RST-injection engine's tunable parameters directly: [stream.tcp.inject.rst] sets auto_remedy=1, number=1 (RST packets per kill), signature_enabled=1, and two numeric seeds (signature_seed1=65535, signature_seed2=13) that presumably drive an identifying pattern embedded in the injected RST packets themselves — i.e. the operator's synthetic RSTs are deliberately marked with a configurable signature, not raw/generic resets.

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.

A harvested JSON dataset matches Windscribe VPN's own internal server-list API format exactly (dns_hostname on windscribe.com, node hostnames on whiskergalaxy.com, WireGuard public keys per node, OpenVPN x509 certificate names, and per-node latency-probe ping_host URLs) — i.e. a commercial VPN provider's full server infrastructure (IPs, WireGuard pubkeys, ping/latency endpoints) has been scraped/harvested wholesale, the same pattern documented for the CyberNarrator/ vpn-thwarting Psiphon3 pipeline but applied to a different provider (Windscribe).

The "ADC Hardware Installation and Configuration Guide" (v21.10) documents Geedge's own carrier-grade appliance: model ADC-L404 with hot-swappable fan/PSU/CPU-sled/switch-sled chassis modules, installed via ONIE and running TSG-OS, managed through an MCN0/MCN1-3 control-node cluster architecture. This is the physical hardware product underlying TSG deployments, including the "ADC hardware" referenced in the WMS-UTR/P19 Pakistan site codename notes.

The same ADC/TSG-OS installation guide's built-in factory acceptance test ("tsg-diagnose-oneshot") enumerates the product's certified MITM/content-manipulation actions as standard, tested features of every deployment: SSL interception with expired/self-signed/untrusted-root cert handling, and both SSL and HTTP proxy policies supporting redirect, block, replace, hijack, and insert actions, plus DNS request handling with drop and A/AAAA redirect (including TTL-range variants). This is vendor self-documentation, not inferred behavior.

The same MESA team overview describes a global "cyberspace mapping" active-reconnaissance platform built on rented distributed cloud nodes worldwide as a rotating probe/proxy pool (unreachable nodes replaced on an ongoing basis), plus an AI-driven (OCR + image recognition) UI-automation framework that can drive Android/iOS apps and web systems from natural-language test scripts for large-scale automated probing and data collection.

A June 2021 internal report measures a live in-network TLS-interception pilot: one sapp instance ingests raw ciphertext via mrzcpd while a second ingests plaintext from a "third-party decryption platform" over a Unix domain socket, and one hour of production traffic on a live front-end (10.187.0.2) shows the decryption platform successfully produced plaintext for 4.85% of raw traffic bytes and 7.4% of all port-443 TCP connections, with an average end-to-end decrypt latency of 1741ms (median 460ms, up to 6000ms) between first ciphertext byte and the resulting plaintext HTTP GET.

sapp's plugin API exposes explicit enforcement primitives -- MESA_kill_tcp()/MESA_rst_tcp() to inject a single RST, and MESA_set_stream_opt() with MSO_TCP_RST_REMEDY/MSO_DROP_STREAM to make RST-injection or packet-dropping persist for the remaining lifetime of a flow -- with a global sapp.toml auto_remedy toggle and a per-stream option controlling whether a lone RST is reinforced repeatedly for as long as the flow keeps sending data.

In sapp's inline deployment mode, packet injection is handled by a driver pair (mrzcpd + mrtunnat, an mrzcpd sub-component not previously catalogued) that must reconstruct per-link tunnel state (cached in /run/mrzcpd/mrmonit.tunnat) before forging a packet in the correct direction; the internal troubleshooting guide documents that injection silently fails for GTP/MPLS/GRE-tunneled flows when the reverse-direction tunnel identifier has never been observed on that link, an explicit "asymmetric address layer" edge case.

An internal "sapp" developer guide (marked "Geedge Networks Confidential And Proprietary") documents that MESA's core DPI/traffic-processing platform has gone through four generations since roughly 2005 -- start -> papp -> sappv3 -> sappv4 -- with sappv4 (introduced 2019) now the sole actively maintained branch, while some sappv3 deployments still run unless a critical bug forces an upgrade.

sapp's internal architecture guide documents three deployment topologies (mirror/passive-tap, inline, dual-arm transparent) and four distinct methods for injecting blocking packets back onto the wire, including a MAC-in-MAC scheme that extracts device/link IDs from mirrored traffic's source MAC field to route an injected packet to the correct physically separate inline device over VXLAN when multiple injection points exist.

A MESA Lab Go tool (modikai/edns_svcb_https) measures EDNS, SVCB, and HTTPS DNS record support across a top-1M domain list and a set of DNS servers — record types that carry Encrypted ClientHello (ECH) configuration, suggesting reconnaissance ahead of possible ECH-aware blocking.

An internal MESA literature-review report surveys published GFW-evasion research the team is tracking -- including Geneva-style TCB desynchronization, application-layer field-mutation evasion, CDN-based Domain Fronting/CacheBrowser/CDNReaper/Domain Shadowing/DfDs, and traffic-mimicry tools including the WebRTC-parasitizing tool Protozoa and the TLS-mimicking Trojan protocol -- indicating these specific circumvention technique families are on MESA's active R&D radar.

A production feature spec ("加密协议JG") requires detection-and-control capability for QUIC, ESNI, and ECH, with a per-connection log field c_encrypt_type explicitly distinguishing ClientHello encryption (0=unencrypted, 1=ESNI, 2=ECH) and a DF_QUIC_REGION rule table matching QUIC by SNI. The system computes a per-rule "CT" (穿透/penetration) rate from paired mirror-vs-functional RST-packet logs (TF-RST-LOG / TF-MIRROR-RST-LOG) to grade each block rule's effectiveness, and runs continuous active-verification probes against its own rules, deliberately varying the probe 4-tuple each run "to ensure it doesn't hit the blacklist" so the verification traffic itself reaches the target.

A TSG "device_group" tag configuration enumerates 30+ Ethiopian deployment sites far beyond the previously-known E21 site list, including many new city/PE (provider-edge) codes (Ambo, Nekemte, Yeka, Arada, Jijiga, Dessie, Mekele, Debre Markos, Gondar, Hawasa, Sodo, Jimma, plus GGSN nodes at Microwave/Kirkos/Nefas Silk) alongside the already-documented sites (Bole, Shashamane, Bahir Dar, Dire Dawa, Legehar, Old Airport, Nefas Silk). Two entries are explicitly labeled "Safaricom Kaliti IGW" (KLT-IGW) and "Safaricom STEP HQ IGW" (STQ-IGW), directly confirming the Safaricom Ethiopia customer identity for the E21 deployment from primary device configuration rather than inference.

A TSG device-group tag list for the Ethiopia deployment enumerates far more IGW/PE sites than previously catalogued, including Bole-IGW, Shashamane-IGW, Microwave-IGW, and Bahir Dar-IGW gateway nodes plus PE sites at Legehar, Old Airport, Nefas Silk, Ambo, Dire Dawa, Nekemte, Kirkos, Yeka, Arada, Jijiga, Dessie, Mekele, Debre Markos, Gondar, Hawasa, and Sodo, and explicitly labels two nodes 'Safaricom Kaliti IGW' and 'Safaricom STEP HQ IGW', directly tying the deployment to carrier Safaricom Ethiopia; a companion site runbook for a link migration at the Bahir Dar-IGW node shows live CLI admin sessions against hardware identified as '9000-SMBIO-P01R01-1'.

A published MESA Lab / IIE-CAS paper ("ExitSniffer", CCIS-2021) and two filed patents describe a tool that actively builds 2-hop Tor circuits through every exit relay to decoy websites and diffs the decoy's observed source IP against the relay's public consensus IP to expose non-public "hidden node" infrastructure behind Tor exits (96% coverage of all exits in about 50 seconds), plus a complementary passive method -- a government-funded ("国家信息安全项目") controlled Tor relay that logs real predecessor-hop IPs -- that found hidden nodes behind 71 of 6,850 tracked routing nodes; the same research program's dataset separately logs 10,412,582 real anonymous-user access records against 1,627,920 distinct clearnet domains visited through Tor.

Production network-topology docs for the Astana and Almaty (Kazakhstan / K18) sites show a live decrypted-traffic forwarding pipeline between an ADC front-end and an ASEM front-end over a direct fiber link, plus a distinct 'IP Spoofing' business function and dedicated static/dynamic proxy interception business lines, and a certificate-management endpoint (port 9991) — confirming operational TLS interception (MITM) infrastructure in production, not just lab capability, at both K18 sites.

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.

An internal porting/test report documents migrating sapp and marsio (its DPDK-based packet-I/O layer) onto domestic Huawei Kunpeng ARM64 hardware (华鲲振宇 TG225 B1, dual KP920-5250 CPUs, 1TB RAM) running the Kylin (麒麟) domestic Linux distribution, using Huawei's Devkit source-migration scanning tool and DPDK 20.11.3 with hugepage/vfio-pci NIC binding, functionally validated via tcpreplay packet-injection tests.

An internal encrypted-DNS research report outlines a DoH-server discovery methodology combining public-list lookups, TLS-certificate-based active probing, and an ML-based hybrid active+passive detection method, feeding a global-vs-domestic-network DoH deployment mapping exercise that concludes with a "管控" (control/blocking) recommendations section; the extracted text preserves only section headers/outline, not the underlying methodological detail or numeric findings.

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.

handingkang/fakedns6 implements DNS response spoofing over IPv6, with source under a "ucr.edu" path and a "saddns" binary referencing the academic SAD DNS (Side-channel AttackeD DNS) cache-poisoning technique — evidence MESA Lab is testing/porting the SAD DNS off-path cache-poisoning attack for IPv6, extending classic DNS injection beyond IPv4.

A MESA Lab repo (handingkang/fakedns6-v2) implements an off-path DNS cache-poisoning tool built on the academic SADDNS2.0 side-channel attack (file path under ucr.edu/SADDNS2.0, GuessSeed.go plus a C guessSeed4.c), and a later commit explicitly removes "attack.sh"-related descriptions from the README -- consistent with an internally adapted DNS-spoofing/injection tool rather than a pure, undeployed academic replication.

A Flink-based "FileChunkCombiner" pipeline in the TSG OLAP stack (galaxy/tsg_olap/file-chunk-combiner) reassembles file chunks parsed from proxy and session metadata (ParseProxyFileMetaFlatMapFunction, ParseSessionFileMetaFlatMapFunction) captured off monitored traffic, then persists whole reconstructed files to HBase and object storage (an "HosSink" and an OSS sink), confirming TSG performs full file-content extraction and durable storage from intercepted sessions, not just flow/metadata logging.

The AV/frag_monitor tool (headers AV_kill_connection.h + Maat_rule.h/Maat_command.h, i.e. a MAAT-integrated flow classifier with active connection-termination capability) ships per-deployment JSON templates including frag_monitor_k_online.json — explicitly defaulted to "K project" per a 2018-12 commit, matching taxonomy's K18/Kazakhstan site codename — plus a dedicated frag_monitor_k_online_youtube.json template and a "zhongxin" (中信)-named template, indicating per-target (YouTube) and per-site blocking profiles built on top of an active kill-connection primitive.

MESA Lab's internal "tcp_burst" traffic-replay tool (common_tools/tcp_burst, a fork of tcpreplay) bundles fragroute — a well-known IDS/DPI-evasion toolkit implementing TCP/IP fragmentation, segment reordering, chaffing, duplication, and delay — and integrates its replay path with the marsio packet-I/O framework also used by sapp, indicating fragroute-style evasion techniques are used internally to test TSG/sapp's DPI robustness against fragmentation- and reordering-based evasion.

The AV/frag_rssb tool performs fragment reassembly of intercepted network streams to extract audio/video and VoIP content (source files frag_av.c, frag_voip.c, "sip_send_survey_log SIP to RTP"), with "sifter" pattern templates specifically for YouTube, Tudou, DASH, HLS and OSMF media streams. Config files main_k.conf/frag_reassembly_k.conf and a K_PROJECT build macro indicate a customer-specific build variant labeled "K" (consistent with the K18/Kazakhstan site codename convention used elsewhere in this corpus).

A 616-row keyword/URL-path signature list targets login/register/wallet/loan API endpoints (e.g. /api/User/login, /api/Qianbao/tixian [wallet-withdraw], /api/Order/loanuse) characteristic of scam-loan and phishing apps, demonstrating the same URL-path keyword-filtering rule format used for censorship targets is applied to a distinct fraud-detection ruleset -- direct primary evidence of the keyword-filtering rule format itself.

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.

TSG's DNS enforcement plugin (tango/fw_dns_plug, packaged with tsg_master) implements DNS response spoofing as its DENY action, sending forged/deceptive DNS answers, with differentiated behavior for mirror (passive-tap) vs inline deployments: mirror mode only spoofs a response to the request, while inline mode drops the real answer and injects a forged one.

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.

A log-stream double-write Flink program (galaxy/tsg_olap/log-stream-doublewrite) was purpose-built and repeatedly updated for "P19" -- the internal codename for the Pakistan (WMS-UTR) TSG deployment -- replicating TSG session-record logs to a secondary sink, evidencing dedicated engineering investment in the Pakistan customer's log pipeline distinct from the base product.

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.

A Kazakhstan-specific push service (galaxy/K18/galaxy-push-service) tracks per-geographic-area protocol blocking (AreaBlockProtocol, BlockingArea, EventsBlock domain classes) and pushes Top-N blocking analytics on a schedule, indicating K18's blocking is administered and reported at sub-national (area) granularity rather than applied uniformly nationwide.

The Galaxy query-gateway platform's (galaxy/platform/galaxy-qgw-service) statistics/policy-metrics schema had a JA4 fingerprint field added (ticket TSG-23812), confirming TSG's analytics/policy layer captures JA4 -- a modern client TLS/QUIC fingerprint -- as a first-class, queryable field platform-wide, beyond legacy JA3.

Galaxy's platform-wide ClickHouse schema includes subscriber_id, RADIUS on/off, and RADIUS record-log fields as core session-log attributes (not a site-specific add-on), and a companion ArangoDB "knowledge" graph module (SubscriberIdProviderImpl / SubscriberIdPath) resolves subscriber-identity paths, while the platform's schema/API layer separately added KMS/Vault-backed decryption support for fields marked "encrypted, sensitive" -- showing subscriber-identity correlation and its at-rest encryption handling are built into the core multi-tenant analytics platform rather than bolted on per deployment.

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.

The Galaxy Trouble Shooting API's versioned Postman test-collection repo added a Kazakhstan-specific test environment file ("kz_postman.postman_environment.json") in the v20.11-rc3 release, with a commit message "add kz enviroment" dated 2020-12-19 -- direct engineering evidence that Kazakhstan (K18) was an active customer/test target for this platform API by December 2020, earlier than other dated evidence for the K18 relationship elsewhere in this corpus.

The Galaxy big-data cluster deployment automation (ZhangJianlong/galaxy-auto-deploy-cluster) provisions Flink streaming jobs for an 'ACTIVE-DEFENCE-EVENT' log stream, a 'DOS-DETECTION-APPLICATION', and a GTP-C record stream (template name truncated 'GTPC-RE...' in the tree listing) alongside ClickHouse/Druid/Kafka/HBase, confirming the analytics platform ingests mobile-core-network GTP-C signaling in addition to DDoS-detection and active-defense event streams.

The same TSG QA framework exercises live HTTP/HTTPS content-manipulation proxy actions -- redirect, replace, hijack, insert, and edit_element -- including a documented test case that adds a rule to replace "china"-related content in live Google search results, giving a concrete real-world target example for the platform's live content-injection/rewriting capability.

TSG's QA automation framework (dongxiaoyan/gap_tsg_api) documents the policy engine's app-blocking action taxonomy (default/Drop/RateLimit/Tamper, with "rst" later renamed "reset") and records that, as of a 2022 test-suite update, the circumvention tools Psiphon ("赛风") and Freegate ("自由门") were only supported under a RateLimit (throttle) deny action rather than a hard Drop, while dozens of other apps (WeChat, Telegram, WhatsApp, Tor, WireGuard, TachyonVPN, Instagram, Facebook, etc.) had named test coverage across Allow/Deny/Monitor actions.

The gap_tsg_api QA repo includes commits submitting an Android install package and Android/iOS test scripts for an app labeled "E21VPN" -- E21 being the established internal site codename for the Ethiopia TSG deployment -- indicating Ethiopia-specific VPN-app test targets were built into the same automated policy-validation pipeline used for TSG's general app-blocking QA (which in the same commit already covered ExpressVPN, HotspotShield, NordVPN, Surfshark, ProtonVPN, iTopVPN).

TSG's blocking-policy validation API treats subscriber-identity fields (IMSI, phone number, APN, subscriber/sub ID) as first-class policy match/verification conditions rather than downstream-analytics-only fields, and the same QA suite includes test coverage for carrier-network tunneling and mobile-core protocols (GRE, GTP-C, SIP), indicating the DPI/policy engine is deployed inline within mobile-carrier network cores, not just fixed-line ISP links.

dongxiaoyan/gap_tsg_ui is a Robot-Framework QA automation suite for the TSG admin UI that validates a "Hijack Files" feature using uploaded test payloads of type .apk, .exe, .gif, .html, .jpeg, .png and .svg — confirming the live product can serve/substitute arbitrary file types, including Android APKs and Windows executables, as part of an intercepted-connection hijack action — alongside test cases for GTP-C records (mobile-core signaling) and first-class "subscriber_ids" and "mobile_identites" policy objects.

A static/dependency-scan report of 'source-code.zip' shows TSG-UI's actual source tree lives under path 'Bifang/TSG-UI', with the Vue frontend and Spring backend both referencing the same 'tsg-bifang' MariaDB database and a Java package namespace 'com.nis.tsg.{controller,service,dao}' -- confirming 'Bifang' is TSG-UI's internal codename/product, built under an internal group's 'nis' Java package root distinct from the mesalab.* namespace used elsewhere in the MESA_Platform monorepo.

Two independent internal ops documents (a Bifang deployment manual and a Druid historical-data-migration runbook) hard-code the literal directory name 'ceiec' into TSG infrastructure paths (mariadb_home_path: /home/ceiec/mariadb; HDFS target /data/ceiec/) -- infrastructure-level corroboration, beyond the previously-documented export-channel notes, that CEIEC (China National Electronics Import & Export Corp) is embedded operationally in Geedge/MESA's own deployment tooling, not just named in contract paperwork.

A TSG/sapp signature bundle dated 2024-06-17 defines a single 'Express VPN_Patch01' application (app_id 15190) matched by three independently OR'd signature layers -- an FQDN blocklist (expressvpn.com and ~7 domain variants), a destination-IP blocklist of roughly 150 addresses, and a raw UDP payload byte-pattern match anchored by offset/depth against ExpressVPN's Lightway protocol handshake bytes -- tied to an explicit enforcement action of dropping matched traffic.

A customer technical Q&A document specifies capacity requirements for a front-end traffic-shunting device sitting ahead of TSG: rule capacity above 10,000 masked/wildcard rules and above 1,000,000 exact-match rules, distributed across multiple X86 boards by rule-category (>16 categories), a rule-load speed above 100,000 rules/second, and sub-1ms rule-effective time, supporting IP/port-based drop, forward, mirror, and loopback actions on innermost addresses under nested MPLS/VLAN/IPv4-v6 encapsulation.

Geedge Networks' own new-hire onboarding deck (积至（海南）信息技术有限公司/Geedge Networks Ltd, Hainan) describes its product evolution 'from NGFW to next-generation security' as explicitly built on 'service chaining, active DPI, and man-in-the-middle' ('服务链、主动DPI、中间人') technologies, and states TSG competes 'in the international market' ('TSG在国际市场') -- company self-description confirming active DPI and MITM interception are core, deliberately marketed capabilities of the exported TSG product, not incidental features.

A raw keyword/domain blocklist export (1,052 rows) includes wildcard/suffix-matched entries such as '*.gfwu.cn', '$gfwu.cn', '*mxstsg.com', and '*90tsg.com' alongside apparently unrelated commercial domains -- a concrete instance of the keyword-filter-list format used to feed TSG's matching engine, though this excerpt alone does not establish the list's overall purpose (anti-fraud vs. political/content blocking).

A recurring weekly 'Tiangou Secure Gateway / Server IP and Location of Overseas APP' report series tracks per-app server-IP geolocation for Instagram, Snapchat, Telegram, and Likee traffic, with entries repeatedly geolocated to Almaty, Pavlodar, and Nur-Sultan, Kazakhstan across late 2023-early 2024 -- consistent with (though not conclusive proof of on its own, given ambiguity over whether the geolocated IPs are CDN edge nodes or another artifact) an operating Kazakhstan TSG deployment continuously monitoring named social/messaging platforms.

An internal 'Data Platform Cluster Deployment Document' (数据平台集群部署文档) for the Galaxy component (Hadoop/HBase/Kafka/Storm/Zookeeper stack, package galaxy_component_install) explicitly names a 'KZ项目' (KZ Project) with its own pre-prepared regional config directory 'config-KZ' and a per-site config file 'component-NUR.conf', and instructs deployers to set the host timezone to Asia/Almaty -- direct internal confirmation of a Kazakhstan deployment matching the leak's K18 codename.

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.

A 2020 static-analysis report of a bundled archive 'Galaxy+Nezha+TSG-UI+Bifang.zip' enumerates Java source paths under 'com.mesalab.*' spanning knowledge-management (KnowledgeController), a network-monitoring controller (NetworkMonitorController), a query-gateway module (qgw, with JobAdminHttpSource/QuerySubmitInterceptor), and Druid/HBase/Calcite storage utilities -- directly tying the MESA_Platform monorepo's package namespace to four named internal components (Galaxy, Nezha, TSG-UI, Bifang) bundled and reviewed together as one release artifact.

The TSG session_record schema in use at the Myanmar (YGN-MYTEL) deployment includes, in the same per-session record, both TLS-interception status fields (proxy_pinning_status, proxy_intercept_status, proxy_cert_verify, proxy_passthrough_reason, proxy_intercept_error) and individual-subscriber-identity fields (subscriber_id, imei, imsi, apn, phone_number) -- confirming MITM/certificate-interception capability and per-person subscriber correlation are built into the same live logging pipeline at an actual export site, not just described separately in marketing/config material.

Raw TSG session_record export logs dated Nov 2024, tagged device_group 'YGN-MYTEL' (Yangon, Mytel), directly corroborate the leak's M22=Myanmar/Mytel/Yangon site-codename mapping with live production data: individual SSL sessions are classified by app as 'Hotspot Shield VPN' (destination get.adobe.com, likely a fronting/CDN endpoint) and allowed under a named whitelist rule 'whitelist_102024', geolocated client-side as Myanmar.Yangon.Yangon.

The same Bifang deployment manual configures an 'api' service Kafka consumer on topic 'PXY-EXCH-INTERMEDIA-CERT' (consumer group 'tsg-consumer-cert') -- an explicit proxy/intermediate-certificate exchange channel, i.e. infrastructure-level evidence of how TLS-interception certificates are distributed/synced across the TSG cluster, consistent with the certstore product's described per-connection certificate-profile system.

The Bifang (TSG-UI) automated-deployment manual configures a dedicated 'subid' microservice that consumes a Kafka topic literally named 'RADIUS-RECORD-LOG' under consumer group 'mapping-subid-ip' -- an operational pipeline that ingests carrier RADIUS accounting records specifically to map subscriber identity to IP address in near-real-time -- concrete infrastructure-level detail for the subscriber-identity-correlation capability elsewhere associated with the CyberNarrator/vpn-thwarting component.

Beyond ExpressVPN, TSG/sapp's signature pipeline maintains individually dated, continuously-updated detection rules (IP, FQDN, and in some cases WireGuard-specific payload signatures) for dozens of distinct named commercial VPN products spanning mid- through late-2024 -- including FlyVPN, VPNHero, RapidVPN, JourneyVPN, quarkVPN, AwardVPN, VPNLite, AdGuardVPN, WolfVPN, DelightVPN, VPNlat, VPNBrazil, NotVPN, VPNTurkey, jumpjumpVPN, BetternetVPN (with a dedicated WireGuard variant), TurboVPN, Psiphon 3, CyberGhost (WireGuard-specific), NordVPN, VPN Unlimited, and SuperUnlimitedVPN -- indicating a long-tail, actively-maintained blocklist covering niche/regional VPN apps, not just a handful of major providers.

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.

GEEDGE's own employee handbook gives a corporate timeline confirming: the company (中电积至(海南)信息技术有限公司 / Geedge Networks Ltd., founded July 2018 in Hainan) signed a strategic cooperation agreement with China National Electronics Import & Export Corp (中国电子进出口总公司 / CEIEC) in December 2018; obtained foreign-trade operating rights in May 2019; won an international competitive bid for its flagship TSG product against Canadian and Israeli competitors in June 2019; and completed phase-2/3 acceptance and delivery of an unnamed overseas project in January 2021.

Geedge Networks' 2023 new-hire onboarding deck gives a corporate timeline: TSG's first international market win (with a codename "Nezha" launching the same month) in September 2018, "网络叙事者" (CyberNarrator) launching November 2020, a "South Asia" country project landing August 2021 (overseas market expansion), and Geedge winning a bid as overall solution provider for an "East Africa" country project in May 2022 — timing and regions consistent with this corpus's existing Pakistan (WMS-UTR/P19) and Ethiopia (E21) site attributions, though the deck itself does not name the countries.

Geedge's internal company timeline dates the launch of 网络叙事者 (CyberNarrator) to November 2020, and states the company won a 'South Asian country' project in May 2021 (consistent with Pakistan/WMS-UTR) and, as overall solution provider, an 'East Africa country' project in May 2022 (consistent with Ethiopia/HDM) -- corroborating the export timeline for those two customers from the company's own materials rather than site-side evidence alone.

The same operations manual's troubleshooting section confirms the blocking system operationally injects forged RST and "spoofed" (欺骗) packets onto mirrored/passive-tap links via network devices — validated by test-injecting a packet via tcpreplay to an external VPS and confirming arrival with tcpdump — runs the sapp process under supervisor scripts with live status/config-version files (TF_maat.status, RESTART.log), and distinguishes a national "GF" system from separate provincial-gateway ("省口") deployments when localizing which egress point a given block should have taken effect at.

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 repo literally named "gfw_test" (single commit, author handle "MDK"/modikai) contains a single Go program named injection_probe.go -- naming strongly indicative of an internal tool for testing GFW-style packet-injection or active-probing behavior, though the extracted material available here is repo/file-tree metadata only, not the source itself.

'AppSketch Works' (internal Chinese name: 特征工厂, 'Feature Factory') is a formal, dedicated internal product -- not an ad hoc script -- for managing extraction, verification, and distribution of app/VPN blocking signatures ('APP Sketch DB') across all TSG deployments including export customers.

An internal "网站/应用资源测绘" (website/app resource-mapping) presentation describes active EDNS-Client-Subnet DNS probing from many simulated geographic vantage points to map Google's and Facebook's global service-IP distribution by country/province, a mobile-app pipeline combining UI automation with MITM-proxy/ SSL-pinning-bypass to extract button-to-URL mappings from decrypted app traffic, and a "网站指纹审查" section that explicitly documents domain fronting as an effective evasion of its own DNS/SNI/Host-based website-fingerprint detection, alongside literature-based behavioral/ML website-fingerprinting intended to survive the QUIC/ECH/DoH transition.

An internal research writeup ("研究点二：基于GRU神经网络的共享接入IP检测技术") builds a GRU/CNN model over sequences of TLS JA3/SNI/session-ticket and HTTP cookie fingerprints, trained on 6 days / 155GB of mirrored traffic captured from an internal gateway named "华严网关" (Huayan Gateway), to determine whether a single source IP represents one device or several devices sharing that IP (e.g. behind a NAT/proxy), reporting precision 0.844 / recall 0.874 / F1 0.859.

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.

TSG's tsg_olap log-completion-schema Flink ETL job enriches raw session logs with subscriber-identifying context by joining flows against GTP-C (mobile-core control-plane signaling) and RADIUS accounting relations (GtpCRelation.java, RadiusRelation.java, backed by HBase), caching upstream/downstream GTP-C TEIDs specifically to complete one-directional flows with subscriber info, gated by a VSYS (multi-tenant) dimension.

A MESA thesis proposal ("移动互联网信令数据关联分析方法研究") builds a SAPP platform plugin that parses LTE GTP-C control-plane signaling (S11 interface) to extract session/TEID identifiers and correlate them with user-plane IP sessions, explicitly to resolve subscriber identity that is otherwise unavailable because "the data plane and signaling plane are separated" in mobile networks. A later revision of the same proposal confirms the parser and the ID-to-IP correlation logic are both implemented as SAPP plugins.

A TSG-OLAP Storm topology (galaxy/tsg_olap/relationship-gtpc-user, class GtpRelation.java) builds a live correlation table between GTP-C (mobile-carrier GPRS tunneling control-plane) tunnel identifiers/TEIDs and user sessions, streaming from Kafka into HBase — a mobile-network subscriber-correlation capability structurally analogous to the RADIUS-based correlation already documented under CyberNarrator's Pakistan deployment, but implemented as a general-purpose TSG-OLAP component rather than a single named/branded product.

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.

A repo named "active-defense/houyi-deploy" is an Ansible playbook that installs a component called "houyi" (后羿) alongside sapp and a "wire-graft" packet-injection module (matching the taxonomy's marsio "wired_graft" plugin); the bundled RPMs/scripts include standalone binaries named tcp_syn_flood, udp_dns_flood, and a DNS-reflection-amplification script (reflect_dns.sh), indicating this TSG-adjacent platform includes offensive flooding/DDoS capability, not just passive blocking.

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.

A CAS-institute thesis on differentiating human vs. automated ("machine") network behavior deploys an HTTP/SSL key-field extraction and app-identification system at a live network gateway (mirrored traffic) built on a modified nDPI (extended to recognize 108 application-layer protocols) plus a custom rule-scan module whose region/group/compile config hierarchy and terminology closely parallel MAAT's separately-documented architecture, suggesting shared lineage between this academic prototype and MAAT's production rule engine.

At a 'WMS-UTR' project deployment, Huawei DPI equipment operating alongside Geedge TSG at sites abbreviated TWA/PCAP/MSH independently applies a SIP-protocol Deny policy with IP allowlisting -- confirming TSG is deployed in a multi-vendor stack alongside Huawei DPI hardware at the same customer site, not as the sole detection layer.

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.

Recurring "entry/exit overall traffic monitoring" (出入口整体流量监测报告) and per-provider "IDC quality monitoring" reports show China domestic gateway links running at up to 1.68 Tbps aggregate (24 links) with per-app (Bytedance, Tencent, Kuaishou, Alibaba, Baidu, Apple, Netease, Pinduoduo, Xiaomi, bilibili) traffic-share, TCP-handshake-latency, and packet-loss-rate breakdowns generated on a routine (near-daily/weekly) automated cadence — dozens of these reports recur across the corpus at different dates.

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.

Two IIE graduate-research repos (cuiyiming/gradproj, a 2019-2020 master's thesis project citing NDSS'17 TLS-interception-measurement and TLS-client-identification papers; daxiaoxu/xmr_bsexpr2, a 2022 project with GRU-based sequence classifiers over TCP/DNS flow JSON and deleted docs on TLS1.3 and Tencent's proprietary MMTLS protocol) document the ML feature-engineering methodology (TLS certificate length, handshake message sequences, JA3-style statistics, Markov-chain packet-size/timing models, GRU sequence models) that plausibly underlies production classifiers (e.g. stellar's later JA4/JA4S support, MESA_sts's randomness checks).

TSG's "IP Learning" subsystem (wanglihui/ip-learning-graph, ArangoDB + Spark/Java) builds a Subscriber-IP-FQDN correlation graph (vertices Subscriber/Ip/Fqdn; relationships LocateSubscriber2Ip, LocateFqdn2Ip, VisitIp2Fqdn) fed by RADIUS session-activity data, and its commit history documents a dedicated "tsg kz" (Kazakhstan) build, directly tying this subscriber-identity correlation infrastructure to the K18 Kazakhstan deployment.

The BaiyangLi/IPLocator repo, a fork of the open-source libmaxminddb library, ships purpose-built db/v4/Kazakhstan_v4.mmdb and db/v6/Kazakhstan_v6.mmdb databases alongside generic all-IP databases, indicating a Kazakhstan-specific IP geolocation database was built for internal tooling -- consistent with the K18/Kazakhstan deployment documented elsewhere in this corpus.

The IPReuse/mctrl repo implements an "IP reuse" (IP复用) NAT-policy controller managing SNAT/DNAT policy tables (DNAT_POLICY) that was refactored multiple times in January 2019 specifically to call "MAAT's new interface", tying NAT-based traffic redirection/control directly to the MAAT rule engine.

MESA Lab's IPReuse/Deploy_Env ("IP复用"/IP-reuse) test environment deploys real commercial SoftEther VPN client and server/bridge binaries alongside custom "VPN_CGI" control software, an "mgw" (媒体/多协议网关) IP location-aware gateway, and a "华丽IP复用测试环境" (Hualee IP-reuse test environment) diagram — infrastructure consistent with running actual VPN endpoints in-house to generate/label traffic for detector development, though the exact end use is not confirmed from directory metadata alone.

A 2018-2019 IIE-authored repo (IPReuse/vpn_cgi) implements a Django CGI service ("VPN_CGI") with a Redis-backed IP-statistics module (stat_ip_redis.py), built by a team explicitly named "IPReuse" — early (pre-2020) tooling for tracking/managing VPN-associated IP addresses, structurally similar in purpose to the later-documented CyberNarrator 'vpn-thwarting' IP-harvesting/blocklist pipeline, though not confirmed to be the same lineage.

The IPReuse system implements SNAT/DNAT policy tables that classify subscriber sessions by a distinct "vpn" user type (separate from sipv4/sipv6), and exposes a dedicated "VPN_CGI" interface — indicating VPN traffic is identified and handled via its own NAT/IP-reuse policy path (architecture name "Flowood") distinct from ordinary subscriber traffic, with service IDs cross-referenced against the "PanGu" (盘古) system's own documentation.

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.

The "ivacyvpn_udp_payload" signature detects IvacyVPN not via domain/IP but via a byte-pattern match on the UDP payload ("421f016e1648*" in hex, wildcarded) combined with an exact first-packet data length of 42 bytes -- i.e. a protocol-level handshake fingerprint independent of the app's server infrastructure, and robust to IP/domain rotation.

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.

K18_NTCS_WEB/argus-ntc is a large (4,879-file, 3,454-commit) Java/JSP web management console, GitLab-namespaced under "K18" (Kazakhstan), backed by a database literally named "argus_ntc", with UI internationalization files maintained in both Chinese and Russian. This is direct, sustained (2019+) evidence of a dedicated customer-facing management console built specifically for the Kazakhstan deployment, distinct from the generic TSG-web frontend.

The same K18-labeled platform (argus-service/maat_service) defines dedicated log tables and paired monitor/block business-rule IDs for face recognition (人脸识别, rule 0x10E/0x18E), speaker recognition (说话人识别, 0x10C/0x18C), TV-channel logo/watermark detection (台标识别, 0x10D/0x18D), and porn image/audio/video level scoring (MmPornVideoLevelLog, MmPornAudioLevelLog, MmSamplePicLog) — a biometric/media-content-classification capability distinct from conventional protocol-level DPI, with a monitor variant and a separate block variant for each rule.

The 'PanGu/DeployEnv' repository's Kazakhstan production configuration is literally named with the leak's 'K18' site codename (k18_consul_kv snapshot) and documents parallel Astana and Almaty (backup) deployments -- including a 'national proxy' decrypted-traffic-forwarding receiver, dual-site TLS certificate management, and Consul/Telegraf/Grafana service topology -- directly confirming K18 = Kazakhstan with deployment-architecture detail beyond the taxonomy's site list.

The same K18 (Kazakhstan) Galaxy-service backend defines log entities for automated multimedia content analysis -- porn-content audio/video level classification (MmPornAudioLevelLog/MmPornVideoLevelLog), face recognition (MmFaceRecognizationLog), speaker recognition (MmSpeakerRecognizationLog), and logo/watermark detection (MmLogoDetectionLog) -- indicating the exported analytics platform includes biometric and adult-content classification of intercepted media, not just protocol/keyword filtering.

The 'galaxy/K18/galaxy-service' repository -- filed under the leak's Kazakhstan 'K18' site codename -- defines backend log/report entities for OpenVPN, L2TP, IPsec, and PPTP VPN-protocol detection (NtcOpenvpnLog, NtcL2tpLog, NtcIpsecLog, NtcPptpLog) plus keyword-filtered URL logging (NtcKeywordsUrlLog), confirming VPN-protocol identification and keyword-URL filtering were part of the analytics/reporting layer customized for the Kazakhstan customer.

The internal project code 'K18' is confirmed to correspond to a Kazakhstan deployment: a customer fault report about ADC-relayed traffic to amazon.com/twitter.com references testing against 'Nur-Sultan' (Kazakhstan's capital name 2019-2022), corroborating the taxonomy assumption that Geedge's Kazakhstan customer relationship maps to the 'K'-prefixed project codes (K18, K24, etc.) seen elsewhere in this ticket set.

K18_NTCS_WEB/NTC (git.mesalab.cn) is the Java/Spring web console for Kazakhstan's (K18) National Traffic Control System. Its domain model implements per-protocol keyword filtering (App/ASN/DNS/FTP/Mail/P2P/SSL keyword configs), an HTTPS proxy-MITM object (PxyObjTrustedCaCert.java), and explicit content-manipulation templates for HTTPS Redirect and Replace (complex/IP-based) plus Hijack/Insert actions, all managed through this customer-facing K18 control panel.

Within the same K18 (Kazakhstan) NTC platform, a 2019-07-02 commit extends the HTTP manipulation policy's Hijack/Insert action with a "SubscriberID" field while the platform separately collects/reports RADIUS AAA logs (NtcCollectRadiusLog.java, NtcRadiusReport.java) — showing RADIUS-based subscriber-identity correlation tied directly to live content-injection actions in the Kazakhstan deployment, extending the previously-documented Pakistan-only "CyberNarrator" subscriber-correlation pattern to a second export market.

A repo path-labeled "K18_NTCS_WEB" (backend service "argus-service", originally developed as "maat_service") defines per-protocol raw-log and business-rule types spanning HTTP, SSL, DNS, SSH, FTP, Mail, P2P, and VoIP, and the VPN/tunnel protocols PPTP, L2TP, IPsec, and OpenVPN, plus a dedicated keyword-based URL log (NtcKeywordsUrlLog) and a RADIUS collection log (NtcCollectRadiusLog) — showing the K18 (Kazakhstan)-labeled monitoring platform logs keyword-hit URLs and carrier RADIUS data alongside full protocol-specific traffic logs.

The GitLab group itself is named "K18_NTCS_WEB" (K18 = Kazakhstan), and its "nfs" web app implements per-protocol keyword-filter configuration classes (App/FTP/Mail/P2P/SSL keyword configs), an OpenVPN IP-list config, RADIUS-based logging/reporting entities, MAAT rule-sync beans, and an explicit "IP spoofing" business feature with its own "PXY仿冒地址池" (proxy spoofed-address pool) and dedicated policy-log support -- the single strongest piece of evidence in this batch tying named keyword-filtering plus IP-spoofing capabilities directly to the Kazakhstan deployment.

A Navicat MySQL dump (source schema "nz-temp", host 192.168.40.42, dated 2020-10-16) for an internal IDC/asset-management tool ("nz-prometheus") seeds its sys_area geo table with exactly 18 Kazakhstan cities — Aktau, Aktubinsk, Almaty, Nur-Sultan, Atyrau, Karaganda, Kokshetau, Kostanay, Kyzylorda, Pavlodar, Petropavl, Semey, Shymkent, Taldykurgan, Taraz, Uralsk, Ust-Kamenogorsk, Zhezkazgan — plus a full embedded Kazakhstan provincial-boundary GeoJSON map, and no other country's entries. This substantially broadens the known K18 (Kazakhstan) deployment footprint beyond the 5 cities already in the taxonomy notes (Astana, Almaty, Karaganda, Zhezkazgan, Aktau) to essentially nationwide coverage.

The K18-labeled platform's MAAT business-rule catalog includes explicit proxy content-manipulation rule types "PXY IP替换" (proxy IP replacement/substitution) and "PXY管控文件策略" (proxy file-control policy) alongside "PXY 证书管理" (proxy certificate management), giving concrete confirmation that the certificate-based MITM proxy (PXY) module supports IP-substitution and file-policy content manipulation, not merely pass/block/log actions.

The tango/kni (Kernel Network Interface) repo shows TSG's SNI/TLS-ClientHello-based interception logic (kni_entry.cpp) receiving dedicated 2024 fixes for handling TLS ClientHello fragmented across multiple packets ("ssl chello frag") and a "chello first packet hit intercept policy" bug, on top of a long-standing (2020) "dynamic bypass" feature that replaced raw-ClientHello matching with JA3 TLS fingerprints, plus counters for SSL certificate-pinning detection.

zhanghongqing/knowledge-log is a Flink ETL pipeline that builds relationship graphs from DNS and connection logs (Ip2IpGraphProcessFunction, DnsGraphProcessFunction/DnsRelationProcessFunction) and persists them to ArangoDB (a graph database) plus ClickHouse, indicating infrastructure for graph-based flow-correlation analysis (e.g. clustering related proxy/VPN infrastructure by IP-to-IP or DNS relationships) separate from the per-packet DPI engine.

A censorship-circumvention survey presentation (English-language, apparently used for internal briefing/training on evasion techniques within this ecosystem) explicitly lists Lantern by name, alongside Snowflake, as a circumvention tool discoverable by censors via TLS ClientHello fingerprinting, citing NDSS 2019 "The Use of TLS in Censorship Circumvention," and separately catalogs active- probing techniques (port-scan plus protocol-specific probes) used to discover OpenVPN, probe-resistant proxies (obfs4/shadowsocks/OSSH/MTProto), and traditional VPN servers.

Geedge's MAAT/AppSketch signature system contains a dedicated, dated ruleset naming Lantern by product: signature_id 7312 "Lantern_fqdn_20241104" matches common.server_fqdn against the literal keyword "$lantern.io", and a companion signature_id 7240 "Lantern_ip_20241104" matches ip.dst against a static list of 1,604 individual IPv4 addresses, both dated 2024-11-04. The same signature file appears twice in the leak at two different artifact paths (identical content, not independent corroboration). Independent whois verification of all 1,604 IPs (not itself present in the leak document -- done by the extracting analyst against current registry data) found they collapse into only 38 distinct /16 ranges, of which ranges totaling 86.7% of the IPs return an explicit Oracle Corporation whois org record (netnames like OC-195, OC-260, ORACLE-4, ORACLE-MY, ORACLE-SE, OPC1); the remaining 13.3% are unattributed legacy RIPE/APNIC-ERX blocks with no other org found, consistent with the same historical-Oracle-lease pattern as the confirmed ranges. The individual IPs are a stale point-in-time snapshot given Lantern's IP rotation, but the provider concentration is the durable signal: this enumeration was effectively a sweep of Oracle Cloud Infrastructure's address space, not a list of arbitrarily-located relays.

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.

Geedge Networks maintains 'libosfp' (formerly MESA_osfp), a p0f-style passive OS/device fingerprinting library that classifies hosts from TCP SYN/SYN-ACK characteristics (ordered TCP options, a scoring database, per-OS pcap fixtures for Linux/Windows/unknown IPv4/IPv6), packaged as a shared component in the MESA/TSG framework RPM family.

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.

A 616-row "Keyword" list of URL path fragments (login/register/loan-related API endpoints such as api/Order/loanuse, api/index/jiekuang, plus generic JS/CSS resource paths) with at least one entry annotated "（暂停）" (paused), demonstrating that MAAT/AppSketch signature curation extends to URL-path-level keyword matching for a specific app category (apparent online-lending/finance apps) with an active edit/curation workflow (entries can be individually paused).

TSG's core log-enrichment pipeline (galaxy/tsg_olap/storm/log-stream-completion) has a dedicated "radius" branch with repeated "RADIUS log completion" commits, plus a generic "subid completion via HBase" feature -- indicating that resolving network sessions to a subscriber identity via RADIUS/AAA correlation is a general-purpose, platform-level capability built into the core Galaxy/TSG OLAP stack, not limited to the previously-documented Pakistan-specific CyberNarrator deployment.

TSG's AppSketch app-detection engine accepts custom Lua scripts for new signatures, feeding a client/server-role heuristic (lower port = server) for UDP policy matching; a custom OpenVPN-detection Lua script failed to trigger Deny specifically because that role-inference logic misclassified the flow's client/server sides.

yangzhiqing/lvtong is a large (1000+ file) Python pipeline that continuously scrapes/enumerates domains, IPs, and TLS certs for specific targets — including dedicated TikTok and Fox News domain-tracking modules, and pcap captures of Google/YouTube/Facebook/Twitter-adjacent (doubleclick, gstatic, ytimg) traffic — feeding a Neo4j graph DB and periodic "push domain/IP" (推送域名IP) jobs that appear to update a live blocking/monitoring target list.

Under the internal "M22" project (deployment site "YGN-MYTEL" confirms this is Myanmar, at the Mytel carrier), Geedge runs a continuous, individually-tracked signature-extraction pipeline against named commercial VPN apps (Super Unlimited VPN, NotVPN, Avira Phantom, Bitdefender VPN, Thunder VPN, Panda VPN, Mouse VPN, HaloVPN, GoFly VPN, Kiwi/Kuto/Greennet/Gulf Super/Hatunnel+ VPN, and a customer-provided list of 141 more): active probing of app refresh/connect behavior (including automated UI-driving scripts) extracts server IP/FQDN lists, separately for free vs. paid tiers and Android vs. iOS, which are then loaded as blocklist objects and validated against a false-positive ("CT"/穿透) test pass in a separate demo environment before deployment.

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 engineering docs detail MAAT's config/policy hierarchy (region/policy-unit -> group/policy-object -> compile/policy, a conjunctive-normal-form structure capped at 8 top-level groups), its Redis-backed one-master-many-replica config push ("MAAT Redis") with a rulescan fallback, and confirm MAAT runs non-distributed -- one instance per front-end traffic-scanning box -- invoked by sapp per-packet or per-stream (Maat_stream_scan_string_detail) with match-all-then-return semantics; recommended hardware is CentOS 7, 256GB RAM, 2TB disk, 48-core 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.

A 2024-05-17 MESA Lab / field-deployment engineering meeting documents MAAT's live rule-config pipeline in operational detail: a hard cap of 4096 hit results per query, incremental sequence-numbered config deltas reloaded on top of the last full snapshot, a documented "hit vacuum period" during config reload where partially-loaded rules silently fail to match, and separate JSON (test-only, small-scale) vs. Excel-tool-generated (production) config-authoring workflows.

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.

The tango/maat rule-matching engine (TSG's core signature/policy compiler behind libmaatframe.so, 1077 commits) has production test fixtures containing a rule category literally named NTC_DNS_FAKE_IP_CB ('DNS fake-IP callback'), alongside NTC_DNS_REGION and NTC_DNS_RES_STRATEGY rule types -- confirming DNS response injection/spoofing is a first-class, named rule category in MAAT's compiled rule format rather than an ad hoc side capability.

The 2019 chenguanlin/gie_server repo implements a standalone "Gram Index Engine" (GIE_server) service that links directly against libmaatframe.so and bundles Maat_rule.cpp/.h, indicating an n-gram/substring pre-indexing layer sits alongside MAAT's Hyperscan/Rulescan pattern-matching engine for DPI signature matching.

MAAT's compiled rule format includes explicit HTTP URL/request-body/response-body matching rule categories (NTC_HTTP_URL, NTC_HTTP_REQ_BODY, NTC_HTTP_RES_BODY) and email content/header matching categories (NTC_MAIL_BODY, NTC_MAIL_HDR), and its scanner backend supports two swappable regex engines -- a Hyperscan adapter (adapter_hs) and a 'Rulescan' adapter (adapter_rs) -- corroborating this corpus's existing understanding that MAAT falls back from Hyperscan to Rulescan above roughly 50K rules.

Internal Q&A notes and the libmaatframe.so MAAT_INIT_OPT header confirm MAAT's rule-matching engine is Redis-backed for config sync (MAAT_OPT_REDIS_IP/PORT/INDEX, matching taxonomy.yaml's maat_redis_tool note), supports an optional decrypt key for encrypted rule files (MAAT_OPT_DECRYPT_KEY), and accepts arbitrary JSON deployment-tag metadata via MAAT_OPT_ACCEPT_TAGS — the documented worked example tags a MAAT instance with a street-level location. A companion Q&A confirms sapp calls MAAT via Maat_stream_scan_string_detail for cross-packet (streaming) signature matching, that match rules are authored in a web front-end and pushed to field machines by a "config pipeline" (配置线) as JSON, and specifies minimum deployment hardware: CentOS 7, 256GB+ RAM, 2TB+ disk, 48-core Intel Xeon E5.

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.

The liuxueli/install-standalone-redis repo shows MAAT's Redis config-distribution backbone deployed as a 3-tier replication topology (redis-master, redis-global-slave, redis-global-slave-master) with dedicated systemd services and a MAAT_PRE_VER initialization variable, confirming Redis is provisioned specifically as MAAT's live rule-sync layer rather than as general-purpose caching.

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.

TSG ships a first-class 'Mail Monitoring and Blocking' feature (confirmed in the product's own v24.08 deployment test checklist alongside HTTP/HTTPS Blocking, DNS Redirection and Monitoring, HTTPS Decryption, and HTTPS Manipulation) that parses SMTP/POP3/IMAP sessions to extract sender/recipient addresses. Field analysis at a Pakistan site found STARTTLS opportunistic encryption accounts for roughly 25-32% of mail sessions and measurably defeats this extraction -- when STARTTLS occurs, the session is logged but mail-address fields are empty. Engineering's response is to add an explicit flag field rather than recover the addresses.

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).

A September 2023 IIE CAS test report for a "Traffic Aggregation and Processing Subsystem" documents dedicated hardware branded "MESA-NF-3100" (2U chassis, dual Xeon E5-2640v4, 256GB RAM, dual XL710 NICs) deployed at "internet convergence" and "government extranet convergence" gateway points, handling 27Gbps aggregate / 8Gbps per unit with a packet-forwarding loss rate under one-in-a-million, and exercising functional test cases explicitly named "content association analysis," "content feature learning," "targeted-object acquisition," and "application behavior auditing" alongside protocol parsing for L2TP/PPTP/IPSEC tunnels and DNS/HTTP/SMTP/POP3/IMAP/FTP.

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.

liuchang/mesa_sts packages the NIST SP800-22 statistical randomness test suite (frequency, block-frequency, cusum, discrete Fourier transform, linear complexity, longest-run-of-ones, (non)overlapping template matchings, poker, random excursions, rank, runs, serial, universal, approximate entropy) as "MESA_sts", exposed with a documented "randomlooking check" with per-test-function enable switches (branch feature-add_switch_for_randomlooking), and tested against captured WeChat voice-call (MMTLS) and Telegram MTProto (IPv4/IPv6, multiple key-negotiation variants) traffic — i.e. a production statistical-randomness classifier for identifying fully-encrypted/obfuscated protocol traffic.

An internal research document systematically profiles the domain/IP infrastructure, WHOIS/registration data, and captured traffic characteristics of three remote-access/VPN tools (Sunlogin/向日葵, TeamViewer, and OpenVPN over both TCP and UDP) as raw material for building app-identification detection signatures, following the same intro / user-scale / traffic-feature-analysis / packet-capture-and-naming structure per app -- consistent with the methodology described for Geedge's AppSketch signature-extraction pipeline.

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.

The MAAT rule-engine's native C initialization API (MAAT_INIT_OPT enum) confirms Redis-backed live config sync (MAAT_OPT_REDIS_IP/PORT/INDEX, with a cumulative-update mode), matching the taxonomy's maat_redis_tool description, and exposes a MAAT_OPT_ACCEPT_TAGS mechanism for attaching arbitrary JSON metadata tags -- the documented example tags a deployment with a specific Beijing district location and an ISP name.

The user manual for a third-party network traffic-diversion appliance (NORMA1.7.3, vendor Beijing Hengguang Information Technology Co., Ltd, used as front-end capture/splitting hardware for a backbone/metro monitoring pipeline) describes native rule-matching and drop/forward actions keyed on subscriber IMSI/SUPI within telecom signaling-plane protocols (S1AP, Diameter, GTPv0-2, NGAP, SIP), plus an automated feature that correlates signaling-plane identifiers to user-plane traffic per subscriber and actively extracts that correlation for upstream delivery -- functionally adjacent to, but a distinct vendor component from, the CyberNarrator subscriber-correlation capability.

An internal sapp platform developer manual reveals sapp's full name ("Stream Analyse Process Platform") and documents a stream.tcp.inject.signature_enabled config option that embeds an identifiable pattern into TSG/sapp-injected TCP RST packets via the ip_id, ip_ttl, and tcp_win fields, explicitly so that RST packets originating from sapp can be verified with Wireshark or a standalone tool. The same section documents the platform's default RST-injection count ("first 3, then 1" per blocked connection).

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).

AppSketch Works' asw-runner (Java, net.geedge package) is a job-execution framework that drives target apps/VMs over VNC (VncClient.java), runs Ansible-style playbooks (PlaybookYml/RunnerYml), and captures/uploads pcap files plus job state -- the concrete automation harness behind AppSketch's app/VPN signature-extraction pipeline (drive an app in a VM, capture its traffic, upload for signature generation).

The 'appsketch-works' GitLab namespace hosts a Flask-based PCAP annotation service (pcap-comment, PcapNGFormatAnalys.py) used internally for labeling/commenting captured traffic -- supporting tooling for AppSketch Works' signature-engineering ground-truth workflow.

A 2023-24 IIE repo is explicitly named and organized as current2023/evasion-detect, with a commit literally titled '规避检测' (evasion detection) -- direct evidence of an active, named internal project focused on detecting circumvention/evasion techniques, though the file content itself was not recovered in this extraction (only README churn is visible in the bundle).

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.

TSG's core Kafka log producer (galaxy/tsg_olap/tsg_galaxy_producer) defines RADIUS_RECORD_LOG as a first-class log bean alongside CONNECTION_RECORD_LOG, PROXY_EVENT_LOG, and SECURITY_EVENT_LOG -- confirming RADIUS-based subscriber data ingestion is built into TSG's general-purpose analytics pipeline, not just the Pakistan-specific CyberNarrator identity-correlation add-on.

TSG's v2.0 real-time analytics stack (Kafka to Storm to Druid to ClickHouse, galaxy/galaxy-integration, hosted at git.mesalab.cn) defines a dedicated sessionInterceptHitsLog Druid ingestion job alongside policyEventLog, per-user topUserLog/topWebsiteDomainLog/topUrlsLog reports, and RADIUS/session-record 'completion' pipelines -- showing individual blocked-session events and per-user browsing destinations are logged and aggregated together with subscriber identity in one OLAP store.

An IIE researcher's repo hswfp ('server-side fingerprinting experiment') packages written experiment steps and 'server-side fingerprinting experiment-related code' as a self-contained study, indicating active internal R&D into fingerprinting server/service implementations beyond the productized JA3/JA4 work already shipped in the SSL plugin.

Internal design docs for a "特定网站开放通道试点方案" (pilot program for an open channel to specific websites) show the MESA Lab's parent CAS institute built its own transparent/forward-proxy circumvention system to give ~3,000 staff SNI/DNS- routed access to Google and other blocked sites over a leased VPN line, requiring staff to install a MITM root certificate for HTTPS decryption and mirroring all such traffic for analysis; a higher-bandwidth "两可通道" upgrade is noted as requiring approval from China's Cyberspace Administration (网信办) because the institute "bears risk responsibility" for it.

MESA_jump_layer, extracted from sapp into a standalone shared library in 2021, parses through GTP, VXLAN, and L2TP encapsulation (plus IPv6-in-tunnel edge cases) to reach inner payloads for inspection -- confirming sapp's DPI can see through mobile-carrier (GTP) and datacenter (VXLAN) tunneling layers, not just plain IP traffic.

MAAT's URL-classification/rule-matching RESTful service (url_label_restiful, maat_table_info.conf, Maat_rule.h) is built on the shared MESA 'stream' C headers -- including stream_inject.h, stream_control.h, stream_proxy.h, and stream_rawpkt.h -- confirming packet injection, proxying, and raw-packet control are core primitives of the same low-level framework MAAT's rule engine sits on.

PanGu/ntc_app_plug is a MESA plugin (ntc_app_plug.cpp) built against a soq_master control-plane docker image that outputs inbound/outbound direction labels per flow, illustrating the modular MESA_htable-based plugin pattern used to extend sapp/PanGu traffic classification without changing the core engine.

MESA Lab built a P4 data-plane Bloom filter (p4src/bloom_filter.p4, Barefoot-Runtime bfrt_python, PTF test harness) with SYN-packet membership tests (send_exist.py/send_not_exist.py/send_syn.py) -- R&D into line-rate, switch-level set-membership matching (e.g. blocklist/existing-flow checks) independent of the sapp/MAAT software DPI path.

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.

MESA/sapp ships a Lua scripting adapter (adapter/http_adapter) with separate http_request.lua and http_response.lua entry points, giving sapp plugins a general-purpose scripting hook to inspect and rewrite HTTP requests and responses inline rather than only classify them.

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.

TSG's official automated regression-test suite (dongxiaoyan/autotest_tsg, Robot Framework) includes a dedicated case named AllFlowHTTPSIntercept-001.robot under tsg_adc, alongside tsg-bifang API/policy-object test keywords -- confirming HTTPS/TLS interception is a first-class, explicitly QA'd feature path in TSG rather than an incidental byproduct.

A 2018 IIE research repo (IPReuse/vpn_access) documents preliminary reconnaissance into commercial VPN vendors, PPTP/L2TP/SoftEther protocol internals, related open-source projects, and integrating VPN account/traffic management with FreeRADIUS -- early-stage groundwork plausibly feeding the VPN-protocol-identification work later productized as glimpse_detector/AppSketch.

An IIE 'attack script' repo (zhuyujia/yydns) contains dedicated, documented modules for injecting fake DNS-over-HTTPS and DNS-over-TLS responses (fake_DoH.py with a 'DoH数据注入' writeup, fake_DoT.py/dot_stub.py with a 'DoT数据注入' writeup) -- direct evidence of active internal research into defeating encrypted DNS transports via response injection, not just plain-DNS spoofing.

The same repo includes IPv6-specific DNS response injection/tampering attack code (folders '4_v6_注入' and '5_v6_篡改': fakedns6/attack.go) plus a custom CoreDNS fork ('ohmydns.go') carrying bespoke atk (attack) and prober (probe53/qname) plugins used for IPv6 DDoS and DNS-probing research -- a purpose-built offensive DNS toolkit distinct from the production TSG stack.

The PanGu/mesa_plug bundle (2019) shows the plugin framework's config layout with an explicit http_url_filter.conf plugin config and a dedicated ntc_bgp_plug submodule alongside asn_tableinfo.conf and IP-deny table config, confirming both URL-based content filtering and BGP-feed-driven ASN/prefix blocking are first-class, separately-configured plugins within the DPI stack (not just SNI/IP list matching).

TSG's SSL parsing plugin (MESA_Platform/ssl) explicitly detects and 'detains' TCP-fragmented TLS ClientHello packets, buffering/reassembling them before running SNI/certificate inspection (tickets TSG-16297, TSG-19861), with dedicated per-session detain-timeout metrics added in 2024 -- meaning ClientHello fragmentation is a defeated, not just untested, SNI-blocking evasion technique against this DPI engine.

The SSL plugin's own test corpus includes a pcap explicitly labeled for the E21 (Ethiopia) deployment -- test/pcap/e21/1-E21-target.com-196.188.136.150-151.101.2.187.443.pcap with a matching ssl_e21_target_result.json -- showing the TLS-parsing/JA3/ECH code is validated against real captured traffic from the Ethiopia site, tying this specific detection engine directly to the already-established E21 export deployment.

The same SSL plugin added explicit detection of the Encrypted Client Hello extension (type 0xFE0D) with test cases in June 2023, and separately implements JA3/JA3S (2020) and JA4/JA4S (2024) TLS client/server fingerprint calculation as first-class features -- so TSG-class DPI can flag 'ECH is in use' even without decrypting it, and independently fingerprints TLS stacks via JA3/JA4.

The appsketch-works/app-test-log repo's 1237-commit history is an operational log of AppSketch's signature pipeline, updating meta.json/signature.json for individually numbered, individually named apps (over 1400 by Nov 2024) spanning games, VPN/accelerator apps, banking, and government-services apps -- direct evidence of the scale and per-app cadence of Geedge's app-identification signature production.

The "galaxy" TSG-OLAP Storm deployment topology processes four parallel log streams -- CONNECTION-RECORD-LOG, RADIUS-RECORD-LOG, PROXY-POLICY-LOG and SECURITY-POLICY-LOG -- through a shared "completion" and "knowledge" pipeline (radius-account-knowledge.jar), i.e. a real-time architecture for joining RADIUS/AAA subscriber records with connection and security-policy logs, consistent with the subscriber-identity correlation capability documented for CyberNarrator.

A Storm topology in the same galaxy/tsg_olap big-data family computes real-time Top-N rankings of external/internal hosts, individual users, websites and URLs by traffic volume (UserCountBolt, WebsiteCountBolt, UrlsCountBolt, UserOutPutBolt), i.e. per-user browsing-destination leaderboards computed continuously across the monitored network.

MESA_Platform's "http" repo implements sapp's HTTP protocol-analysis engine (HTTP_Analyze.c, HTTP_Parser.c) and is directly referenced by TSG bug-tracker tickets (TSG-16812, TSG-23776, OMPUB-1170), confirming this parser ships as part of the TSG/sapp DPI pipeline rather than being a standalone tool.

Geedge maintains an internal fork of the open-source ZeroTier libzt P2P networking SDK (zhangyang/libzt) with Geedge-only commits adding an example named "wannat" and enabling LWIP_RAW/IP_FORWARD. The recurrence of "WANNAT" naming here and in MAAT's subscriber-ID-to-IP rule objects suggests a shared internal system/codename spanning the rule engine and a modified peer-to-peer tunneling library, though the exact relationship is not established from this artifact alone.

Demo configs for the MAAT rule engine define object types WANNAT_OBJ_UE_ID and WANNAT_DYN_UE_ID_IP (a dynamic mapping of subscriber/device UE ID to current IP address), showing MAAT's rule/object model has first-class support for correlating a subscriber identity to an IP address, not only FQDN/IP signature matching.

MESA_Platform's "quic" module (built and packaged as stellar-on-sapp/sapp RPMs) implements SNI/User-Agent extraction from both cleartext GQUIC (versions 23-59) and encrypted IETF QUIC RFC9000 ClientHello payloads, and supports a QUIC SNI whitelist -- i.e. the DPI pipeline decrypts/parses encrypted QUIC handshakes to recover the destination domain rather than being blocked by QUIC's encryption.

Repo modikai/rogue_ns is a single-commit Go tool explicitly committed under the message "YYDNS attack server," containing a rogue nameserver binary (rogue-ns/rogue_ns.go) plus captured resolver traffic (resolver-tcpdump-packets) -- a working DNS-injection/spoofing attack implementation rather than a defensive tool.

A Rust rewrite of Geedge's plugin/session-management framework, internally named "Stellar," binds to libmarsio for packet I/O and implements its own TCP reassembly and protocol decoders (Ethernet/IP/TCP/UDP/DNS/HTTP); a sibling repo's build artifacts show it ships as RPM "stellar-on-sapp", indicating it is a next-generation session/event layer sitting on top of the sapp DPI engine. "Stellar" is not yet a named product in the taxonomy.

TFE includes a dedicated DoH (DNS-over-HTTPS) business plugin that parses and reconstructs DoH POST/response traffic, applies MAAT policy scanning to it, and supports a "Redirect-DoH" policy action tracked by a distinct "DoH_hijack" counter -- meaning encrypted DoH queries are actively parsed and redirected/hijacked by policy, not simply blocked outright.

The tango/tfe repository carries a long-lived branch "develop-21.09-K18" (K18 is the established Kazakhstan site codename), showing the core TLS-interception/HTTP-hijack/DoH-redirect engine (TFE) had dedicated customer-specific engineering for the Kazakhstan export deployment, not just generic TSG builds.

The tango/tfe ("TFE") engine ships dual root-CA trust stores (tango-ca-trust-ca.pem / tango-ca-untrust-ca.pem, mesalab-ca.pem) for TLS interception plus a JA3-fingerprint-based certificate-pinning detector with a configurable "Dynamic Bypass"; a 2021 bug ticket documents testing this against Firefox without a root cert installed visiting twitter.com, confirming live-target validation of the MITM/pinning-detection pipeline described under the certstore product.

TFE's "PanGu" business plugin implements live HTTP "insert" and "hijack" policy actions with configurable injected-traffic-rate control, and its test suite includes real Facebook and Google Search HTML pages as fixtures for the rewrite/replace logic; PanGu also serves custom HTTP403/404/451 block pages. This ties the content-injection capability directly to specific real-world sites and to a named internal component, "PanGu," not yet documented as its own taxonomy product.

IPReuse/mgw is a C++ NAT gateway (DNAT/SNAT) built by an IIE engineer that includes a vpn_monitor module which periodically polls a VPN server to resolve the current IP-to-user mapping, and integrates directly with the MAAT rule engine via a maat_redis handle (test_maat_redis.cpp, vendored maat-v2.3.3.tar.gz) — an early (2018) implementation of tying network-layer IP addresses to individual VPN user identity for policy purposes.

A MESA Lab Minio object-storage cluster repo (zhangchengwei/MinioRelated) provisions and Prometheus/Grafana-monitors separate environments explicitly named "Astana" and "Almaty" — the two primary Kazakhstan site codenames documented under K18 — confirming dedicated per-city storage and monitoring infrastructure for the Kazakhstan deployment as far back as 2018-2019.

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.

An internal "import format" reference document specifies a "Mobile Identity import format" that lets an operator bulk-import subscriber targeting rules by IMSI prefix wildcard (e.g. "5114*") or by phone-number wildcard/exact match (leading "$"/"*" wildcard syntax), enabling mass subscriber-identity targeting by carrier/country IMSI block rather than one subscriber at a time.

Grityu/model_duplication ("five modes duplication", 2023) built and evaluated ML traffic classifiers (Knn_test.py, ScenarioA.pkl, features.json) using CICFlowMeter flow-feature extraction over labeled pcap captures of major commercial VPN/circumvention tools — Psiphon (including a specific "psiphon_operation" capture), Surfshark over OpenVPN TCP/UDP, TorGuard over OpenVPN UDP and "OpenVPN over SSL", and Hotspot Shield VPN — directly evidencing GFW-side R&D on flow-level statistical fingerprinting of specific VPN products.

A complete patent invention-disclosure document describes a "Multipath TCP Functionality Restriction" device deployed inline at a network egress point that identifies the MPTCP TCP option (kind=30, MP_CAPABLE subtype) in initial-handshake SYN/SYN-ACK packets and strips or NOPs it in transit, forcing the connection to fall back to ordinary single-path TCP so that conventional TCP-based inspection and attack detection can be applied to traffic that would otherwise be split across multiple paths.

The IPReuse/mrl tool -- a NAT link-learning daemon integrated with Marsio (which fills VXLAN headers using MRL-supplied virtual link IDs) and MAAT (shared 'maat_feather' candidate/nominee tables) -- ships a Kazakhstan-specific MaxMind-format IP geolocation database (Kazakhstan_v4.mmdb) directly in its own config directory and again inside its bundled IPLocator dependency. Commit history describes self-learning of link info, SNAT/DNAT policy support, and sending virtual link IDs to 'the platform' for Marsio's VXLAN encapsulation.

'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.

An mrzcpd installer script registers a full set of AMD-Zen-optimized ("znver1") binaries and systemd units via update-alternatives — mrzcpd, mrtools-pinfo, mrpdump, monit_stream, monit_device, monit_obp, mrmarch, dpdk-hugepages.py, dpdk-devbind.py, plus services mrapm_device/mrapm_stream/mrapm_obp/mrtunnat/mrzcpd_hugepages_setup/mrzcpd_hwdb_setup — confirming mrzcpd's packet-capture/injection layer is built directly on DPDK with hugepage-backed, CPU-microarchitecture-tuned packet I/O, consistent with the taxonomy's marsio DPDK-framework note.

A leaked Grafana dashboard JSON template ("TSG-X") defines panels querying mrzcpd-exporter Prometheus metrics (rx_drops_total, tx_drops_total, ftx_missed_total, rx_bits_total) keyed per tsg-traffic-engine-vsys service function, confirming mrzcpd (the packet-mirror/inline-injection agent) is operationally monitored for packet loss and throughput as a production Kubernetes/Prometheus-instrumented component of TSG-X deployments.

TSG's data plane runs as containers (firewall, packet-io-engine, proxy, sce, shaping) per TSGX appliance, built on an internal packet framework called Marsio/MRZCPD (config at /opt/tsg/mrzcpd/etc/mrglobal.conf), deployed with 32GB hugepages and tunable TX rate-limiting per bonded NIC.

An official "Geedge Networks Confidential And Proprietary" sapp/mrzcpd operations manual documents the packet-injection API (MESA_kill_tcp / MESA_inject_pkt) used for both out-of-band mirror-tap RST injection (relies on the local box's own IP routing table to send) and inline in-path injection (requires mrtunnat.conf tunnel-tracking state -- use_recent_tunnel, use_link_info_table -- keyed on outer/inner MAC and link_id/link_dir), plus the Marsio DPDK-based driver's I/O sub-modes (marsio4, marsio_vxlan, pag_marsio, agent_smith) and its role extracting VXLAN/GTP encapsulation metadata and stamping link/circuit identifiers into mirrored packets' MAC field for session-log correlation.

Standard workflow (recurring across AdGuard, JumpJump, Hula, BigMama, and Ace VPN tickets) for adding a new VPN app to TSG's blocklist: capture traffic on iOS/Android/Windows in a dedicated test environment, extract SNI first, fall back to enumerating server IPs when SNI proves ineffective or the app rotates it, then re-verify weekly/periodically with automated 'dial testing' (拨测) that checks whether newly discovered IPs still connect ('未穿透' = not yet penetrated/blocked).

An 'Equipment label and cable label design' spec's data-center appendix lists far more Myanmar carrier taps than previously documented: Yangon sites for NDC, Mytel, MPT, ATOM, Ooredoo, Frontiir, Campana, GTG, GTMH, StreamNet, China Unicom, MTN and MBT; Mandalay sites for Mytel/MPT/ATOM/Ooredoo/GTG/China Unicom; plus Tachilek, Ketong, Myawaddy and Muse border sites; and a Naypyidaw entry 'NPT-NCCC' alongside 'NPT-MPT', plausibly a tap tied to Myanmar's National Cyber [Security] Coordination Center in the capital. The equipment-type table also confirms 'TSG-X' as the formal hardware model code.

A physical rack-elevation diagram for 'YGN Data Center Container 2' (Yangon, Myanmar -- taxonomy site codename M22) shows multiple 1U servers in racks 7-12 explicitly labeled 'TSG OLAP and Cyber Narrator' interleaved with plain 'TSG OLAP' nodes, each with its own IPMI management IP, directly corroborating that the CyberNarrator component is deployed as live production infrastructure at the Myanmar M22 site rather than only described in internal documentation.

A MESA research-log entry details a NAT/shared-connection identification methodology combining TCP/IP fingerprinting (IP-ID, TTL, DF, window size, MSS, TCP-option ordering -- p0f-style), HTTP User-Agent diversity, TLS/SSL JA3 fingerprint diversity, and traffic statistical features (concurrent-TCP-connection count, idle-time jitter, upstream/downstream ratio stability, DNS query frequency) per endpoint over rolling time windows, with detection methods spanning direct UA inspection, threshold statistics, ML classifiers (random forest/SVM), and per-window entropy jumps across the fingerprint features.

A NEZHA web-dashboard screenshot and four matching MySQL dumps (schema nz-temp, source host nz-prometheus) show Nezha is Geedge's internal physical-infrastructure/asset monitoring platform, tracking endpoints, IDCs, cabinets, links, and Prometheus-backed metrics/alerts per deployed Tiangou Security Gateway project -- the same system credited with detecting the hardware failure in the HDM/Nefas Silk fault ticket.

The 'nezha/nezha-fronted' internal infrastructure-monitoring dashboard (a customized fork of the open-source Nezha monitoring tool) carries a distinct '2.0-kz' branch/tag lineage dated from June 2021 -- a further, independent data point placing Kazakhstan ('kz') as a named, separately-maintained deployment as early as mid-2021, corroborating the K18 Kazakhstan evidence found elsewhere in this batch.

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).

Three independent internal ops/monitoring codebases — nms/nmsweb, nms/oam ("gloam"), and nezha/nz-web — each maintain a dedicated Kazakhstan-specific branch (nmsweb/oam: "k18-1.0"; nezha: "2.0-kz-2021-07-05" and later kz tags), and nmsweb additionally ships Russian-language localization (globalMessages_ru_RU.properties) plus topology icons for named inline-device hardware models (ADC-A016, ASEM-T102) and generic network elements (BlockRouter, ISPnInlineDevice, CoreSwitch) — confirming K18 = Kazakhstan (per existing taxonomy) received custom-built monitoring/OAM software, not just shared config.

The NMS network-monitoring-server repo (nms/nmsserver) maintains a dedicated, long-lived "k18-1.0" branch (K18 = Kazakhstan codename) alongside its generic dev/master branches, evidencing a customer-specific fork/release line of the monitoring-server product built for the Kazakhstan TSG deployment.

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.

The NEZHA monitoring-platform build repo (nezha/nz-build) contains commits building Myanmar-specific map tiles ("build: M22 7-11 pbf", "build: make myanmar 8-9"), directly corroborating the M22=Myanmar site-codename mapping already established in the corpus via an independent internal build artifact, and separately packages a Russian-language HASP license driver ("hasp_rus") into the NZ installer.

An internal, '内部资料 注意保密'-classified architecture-group ('架构组') research report systematically profiles many third-party OA (office-collaboration) software products, extracting per-product app-identification features -- port-usage ranking, URL patterns, favicons, trademarks, page titles, HTML structure -- plus dedicated Android/Windows client packet-capture sections and a documented packet-data storage scheme, consistent with app-ID signature engineering (AppSketch-adjacent work) rather than the market-research framing of the report's own title.

A MESA Lab git repo (wangmeiqi/obfs4_meek_snowflake) trains closed-world Deep Fingerprinting (DF) website-fingerprinting classifiers (ClosedWorld_DF_NoDef.py) using pre-trained Keras models specifically for Tor's obfs4 pluggable transport, meek domain-fronting, and Snowflake -- the same transport families Lantern's own circumvention stack draws on.

MESA Lab maintains a dedicated "obfs4验证" (obfs4 verification) tool repo (wangmeiqi/obfs4_verify) containing Go and Python obfs4-handshake test/verify scripts plus a bundled pyelligator (Elligator2) implementation — the elliptic-curve-point-indistinguishability library obfs4 itself relies on for its uniform-random handshake — indicating active work to validate, detect, or replicate Tor's obfs4 pluggable-transport handshake.

'PanGu/ObjectScanner' extracts file objects from intercepted network traffic and scans them with the third-party Antiy AVL SDK antivirus engine, publishing per-object detection results (a 5-column virus-verdict breakdown, plus object-size logging) to Kafka -- a deep content-inspection capability distinct from protocol/keyword DPI.

MESA Lab maintains 'ohmydns', a customized fork of CoreDNS with a bespoke 'v64dns' plugin family including a dedicated 'v64dns_policy.go' policy module and a separate gRPC 'analyze' service. The directory listing alone does not reveal what the policy module does; this only confirms MESA Lab operates custom DNS-server infrastructure with a purpose-built policy-decision plugin, worth follow-up if fuller source content becomes available.

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.

handingkang/ohxmap is an internal MESA Lab build of the XMap-family Internet-scale scanner, with extensive IPv6 DNS probe-generation modules (module_dns6a/dns6ae/dns6af/dns6x etc.) and custom Redis output modules; it is maintained by the same author (韩丁康/HDK, [email protected]) responsible for the DoH/recursive-DNS discovery campaigns in the diamondv repo, corroborating an internal large-scale IPv6 address-space/DNS reconnaissance capability.

Internal site codename "K18" is confirmed as the Kazakhstan TSG deployment, running TSG21.09 as of February 2024, via an internal ticket coordinating a timezone migration in response to Kazakhstan's real 2024 government-mandated single-timezone change.

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 maintains a dynamic runtime table (TSG_DYN_IPPORT_SUBSCRIBER_MAPPING) that correlates each network session's IP/port tuple with a subscriber's IMSI and phone number, loaded via incremental Redis-backed updates into the policy-matching engine — i.e. blocking/monitoring decisions can be attributed to a specific subscriber identity, not just an IP.

A security policy literally named "Lantern_vpn_test" was configured and actively enforced at the M22 (Myanmar) TSG deployment as of June 27 2024 — Lantern had a live, named blocking policy in production, not just a backlog research item.

A Myanmar deployment (M22 project) ticket requested Geedge R&D extract detection fingerprints for Signal (specifically targeting its anti-censorship "circumvention" toggle, currently evading blocking), LetsVPN, and LanternVPN — LanternVPN explicitly flagged lower priority with no fixed deadline given expected difficulty.

TSG's QUIC-parsing layer decrypts QUIC ClientHello payloads and parses a user-agent-like parameter from the decrypted content, deployed at the Ethiopia (E21) DIR-IGW site. A missing bounds check on this field caused a watchdog-timeout crash, confirmed via a MESA_Platform/quic GitLab commit (git.mesalab.cn/MESA_Platform/quic).

TSG's Psiphon3 blocking (Ethiopia/E21 site) uses a dynamically-learned "Top SNI" / "Top Server IP" allowlist meant to avoid collaterally blocking shared infrastructure Psiphon3 also rides on (e.g. Google); a bug in the learning pipeline (SNI values under 3 bytes rolled back the whole DB write transaction) let the allowlist silently go stale, causing Google traffic to be misidentified and blocked as Psiphon3.

Internal site codename "E21" is confirmed as the Ethiopia TSG deployment — IGW node names in a traffic report match Ethiopian cities (Bahir Dar, Dire Dawa) alongside other coded node names (BOL, MWV), giving a reusable search key for the rest of the leak corpus.

Ethiopia customer (E21/E-site) explicitly requested TSG blocking be extended beyond the baseline (Psiphon 3) to a named list of commercial VPNs: Freegate, CyberGhost, Torguard, NordVPN, IPVanish, VPN Unlimited, ExpressVPN, Surfshark, Windscribe, Hotspot Shield, Ivacy, Atlas VPN, PureVPN, ProtonVPN, Norton Secure VPN. Engineering confirmed delivery of NordVPN and Hotspot Shield signatures with successful field tests.

During active Psiphon3 blocking at an M-POC deployment, TSG's BGP-protocol-parsing plugin saw a CPU spike because Psiphon3 was observed shifting to port 179 (BGP's standard port) after other ports/IPs were blocked; TSG's DPI classifies by payload shape regardless of declared port, so the port shift did not itself evade detection.

A ticket from a Beijing TSG test environment (v23.07) reports that a 'Deny Telegram' policy generates hit logs but produces no actual blocking effect; the ticket shows no recorded resolution before closing over a year later.

TSG ships built-in BitTorrent detection apps in its "App Sketch DB" (v23.07). A 2023-08 field test found policies matched but did not block BT downloads; root cause was a UDP source/destination port ordering case (server port > client port) that let the real client IP land in the wrong field for the blocking policy to act on. Fixed via a second security policy rule.

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.

TSG deployments include an inline optical-bypass failsafe (光保) that, on link/health failure, can leave the segment in bypass (fail-open passthrough) mode rather than reverting to inline inspection — a 2023 incident at E21 (MSH-TSGX-02, 120Gbps) had a bypass segment stuck open until manually tuned.

TSG23.07 added support for FQDN substring matching (vs. exact/wildcard only) for the P19 deployment, a detection-capability upgrade.

Geedge's TSG self-check test suite (run against firewall version v23.07.18-591aed7) enumerates the product's full interference capability set: SSL bypass/intercept (including handling of expired, self-signed, and untrusted-root certificates), HTTP/SSL proxy actions (redirect, block, replace, hijack, insert), three distinct firewall deny modes (silent drop, TCP RST, blockpage), and DNS deny modes (silent drop, A-record redirect, AAAA-record redirect, including TTL-range variants).

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 integrates a licensed third-party DPI engine (versioned separately from TSG/App Sketch DB releases) that repeatedly segfaulted across many E21 (Ethiopia) NPB nodes over Oct-Dec 2023 when processing specific packet-encapsulation stacks (Ethernet->MPLS->IPv4->UDP, VLAN->IPv4->UDP), requiring an App Sketch DB version bump to resolve.

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 confirmed bypass — TSG failed to extract SNI from TLS ClientHello when the SNI extension appeared later than expected in the extension list, letting those flows through unblocked (and incidentally TLS 1.3 flows generally, since clients fell back to 1.3 after 1.2 was blocked); fixed on-site via a patch to the "ssl.so" detection plugin.

TSG's sapp engine requires periodic authorization from an "ACC" server via a "LM Server"; if a TWA device loses management-network connectivity to the LM Server for over ~1 hour, sapp stops running entirely until authorization is re-acquired. Fixed to auto-retry.

Confirms TSG deployment extends beyond Yangon/Mandalay to Myanmar border towns Tachileik, Kengtung, Myawaddy, and Muse, backhauled to the Yangon DC via VPN devices required to meet <100ms latency and >=1Gbps bandwidth.

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.

A Deny policy using an SNI "Negate" condition fails to block after a page is refreshed multiple times, a duplicate of a prior known bug (TSG-18234) — indicating a reliability gap for negated-SNI-condition policies under repeated/retried connections.

TSG's appliance hardware line is branded 'TSG-X' running an OS layer called 'TSG-OS'; a performance-tuning ticket requests two TSG-X units built on dual-socket AMD Zen 4 64-core CPUs, indicating the current-generation hardware performance tier for large-scale deployments.

TSG's sapp/firewall components run as Kubernetes pods, built from a "MESA_Platform" monorepo (path fragment .../MESA_Platform/sapp/... visible in a crash log), using jemalloc. A 2024-03 SIP-heavy deployment triggered jemalloc memory-purge deadlocks under high UDP concurrency, crashing the firewall pod every 2-4 days; fixed via jemalloc tuning and a session-count cap in the SIP plugin config.

TSG runs two separate detection engines: a licensed third-party DPI engine for general app/protocol identification (requires per-environment authorization -- absent in a demo environment caused a detection gap), and a Geedge-built component ('glimpse_detector') specifically for VPN protocol identification (WireGuard, OpenVPN). App-ID numbering (e.g. built-in wireguard=3700) can be silently shadowed by environment-specific custom IDs, causing detection to fail even when the underlying protocol is correctly classified.

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 app/protocol detection ("AppSketch" / context_based_detector plugin, part of the SAPP packet pipeline) is not purely static-signature: each detection rule can be an arbitrary Lua script (APP_SIG_LUA_SCRIPTS table) executed per-session in a per-worker-thread LuaJIT VM, with access to packet payload, session context counters, and helper functions (APP.data, APP.context.c2s_count, APP.log_debug, APP.append_extra_info). A validation CLI tool (luac-tool) checks script syntax, timeout, and return-value type before import.

TSG is deployed across multiple named Myanmar telecom carriers (Mytel and MPT/Myanmar Posts and Telecommunications) at both Mandalay (MDY) and Yangon (YGN) sites -- device naming convention TSG-OS-<city>-<carrier>-TSGX<n> -- confirming a nationwide, multi-operator rollout rather than a single-ISP pilot.

In WMS-UTR, a third party named "百分点" (Baifendian, a Chinese big-data analytics company) requested TSG's SIP protocol logs; Geedge added a monitor policy and extended the log schema with SIP-specific fields to support the handoff.

A crash/perf bug report reveals Geedge's MAAT rule engine (libmaatframe.so, using Intel Hyperscan for literal/regex matching) running with 545,441 FQDN blocking rules and 404,141 IP address blocking rules loaded in a single instance as of 2024; loading 500,000 new FQDN rules via the full Hyperscan path took ~95 minutes, addressed by an automatic fallback to a second engine ("Rulescan") above 50,000 rules.

TSG has a Lua-scriptable custom-classifier engine: operators upload a Lua script defining a custom traffic "Attribute", then build custom "App" rules matching on it. A 2024-05 ticket references a script literally named cdn_tunnel_finder.lua -- an operator-authored detector targeting CDN/domain-fronting-style tunneling.

Internal asset naming ("YGN-MYTEL-EF01-SMBIO01") ties a TSG deployment directly to Mytel, the Myanmar telecom carrier, at a Yangon (YGN) site -- corroborating and adding carrier-level specificity to the Myanmar export relationship already documented by Justice for Myanmar's "Silk Road of Surveillance" report.

A K18 customer specifically requested TSG support for TCP-segmented TLS ClientHello messages, confirming this was previously an inspection gap; Geedge shipped a fix ("Hotfix-Inspection-TLS-PQC-Extension") in 2024, and the same hotfix name indicates TSG's TLS inspection also tracks post-quantum-crypto ClientHello extensions.

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.

For the M22 project (domestic-China-labeled training ticket, but M22 is elsewhere confirmed as a Myanmar deployment), Geedge explicitly instructs trainers to describe 'Cyber Narrator' only as a black-box ML capability, to avoid revealing the internal domain tsg.bj.internal.geedge.net, and to omit the company logo from training materials — i.e. deliberate concealment of Geedge's involvement and internal infrastructure from the training audience.

Geedge ran a live demo for a visiting delegation at its Yizhuang (Beijing) facility specifically showcasing Psiphon3 blocking, alongside a CN console walkthrough — evidence Psiphon-blocking is used as a sales/prospect differentiator, not just a defensive feature.

Confirms the full Ethiopia (E21) deployment site list — Bole, Shashamane, Bahir Dar, Safaricom Kaliti, Safaricom STEP HQ, Dire Dawa, Legehar, Old Airport, Microwave, Nefas Silk, Kirkos — explicitly including Safaricom Ethiopia (the mobile carrier) sites, with aggregate session-log throughput nearly doubling from 728,000/s to 1,383,000/s between March and July 2024.

Project "M22" (running the Turbo VPN/7VPN extraction program) is tied to a site logged as "YGN NDC" -- YGN = Yangon, Myanmar; NDC reads as National Data Center. Corroborates M22 as Myanmar via primary-source project/site code.

Confirms TSG-OS deployment directly on Mytel's (Myanmar carrier) network with named host identifiers at Yangon (YGN-MYTEL-TSGX025, YGN-MYTEL-TSGX026) and Mandalay (MDY-MYTEL-TSGX001), corroborating and specifying the M22/Myanmar deployment beyond what Justice For Myanmar's public report identified.

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.

Internal project codename "M22" corresponds to a Myanmar deployment at telecom operator Mytel (site id "YGN-MYTEL", Yangon), running on TSGX hardware appliances (at least 25 units observed at this one site) alongside the TSG-OS software stack — extending prior public reporting (Justice for Myanmar) with the specific internal site/customer codename and confirmed hardware scale.

During QuarkVPN feature extraction, Geedge found client/server roles over UDP distinguishable by port-number heuristic (server's fixed ports 59001/59002/60000 exceed the client's random port), though this heuristic is currently causing misidentification, filed as an open bug.

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.

Ethiopia (E21) project completion/acceptance documentation was routed through an intermediary named 长城网际 ('Great Wall Cyber' or similar transliteration), which then delivered it onward to an entity referred to only as '进出口' -- plausibly a state export-import financing bank given the Belt-and-Road financing pattern gfw.report and others have already reported for this customer, but this ticket alone doesn't establish that identification with certainty.

Kazakhstan (K18) required a formal written response to its "进出口" trading-company intermediary about an unspecified "中间人" (man-in-the-middle) problem, resolved via a sapp upgrade. The generic "进出口" intermediary language recurs across K18 and E21 threads, consistent with CEIEC as a shared export channel.

At the K18 site, TSG's TLS-interception ("Tera") steering rules failed to cover all of a CDN-fronted site's IPs (avg.com via Akamai): certificate replacement succeeded on one resolved IP (185.189.92.41) but not another (23.61.224.112), indicating Tera's per-IP steering configuration can miss a fraction of a multi-IP CDN's address space.

TSG's 'APP' classification feature has named, purpose-built signatures for specific circumvention tools — the ticket explicitly configures active-client-IP tracking for the APP categories Freegate, Psiphon3, and Tor.

TSG's SSL interception engine matches wildcard SNI patterns (e.g. "*tumblr.com") to decide whether to intercept (certificate-replace) a connection, but a separately-maintained "SSL Decryption Exclusions" allowlist takes priority over interception policy -- a domain on that list is never intercepted even if it matches an active policy.

Project "E21" is conclusively Ethiopia: names IGW sites by city -- MWV-IGW, BOLE-IGW (Bole, the Addis Ababa airport district), Shashamane-IGW, Bahir Dar-IGW, Dire Dawa-IGW, Legehar -- each with a distinct IP block, indicating a national multi-city topology.

Root-caused an Ethiopia SNI-block-failure incident to the detection mechanism itself: APP_SKETCH's FQDN-scanning module -- which exists specifically to identify Psiphon3 and Freegate via top-N SNI matching -- was CPU-expensive enough to saturate cores, triggering sapp's fail-open DDoS bypass and letting some target connections through uninspected. A signature-structure fix roughly doubled throughput (33K/s to 73K/s new connections) and disabling the fail-open bypass restored reliable blocking.

Project "E21" tested SNI-FQDN-wildcard block policies against international news/media/academic domains -- opride.com (Oromo news), ethiotube.net, Reuters, NYT, Bloomberg, GitHub, ResearchGate, NIH.gov -- from an Ethio-Telecom-range office IP. Most blocks silently failed (shared root cause with OMPUB-466); britannica.com needed a separate deny-quic policy since QUIC bypassed SNI blocking.

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.

As of TSG's SSL/protocol parser in 2022, in-band STARTTLS negotiation (observed via XMPP) was not supported by the SSL parsing logic, causing app-identification-based blocking to silently fail for STARTTLS-negotiated sessions; the workaround was a manual TCP-payload string match rather than proper protocol classification. Confirm current status before relying on this -- single 2022-dated ticket, may since be patched.

TSG's app_proto_identify/app_sketch_local components reference and extend the open-source nDPI project's detectors (specifically openvpn.c) when fixing signatures. "MAAT" is sapp's Redis-backed live-config-sync subsystem, which can enter a bad state requiring an sapp restart to reload policy.

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.

Multi-week TSG engineering investigation of iTOP VPN (requested by an Ethiopia deployment, cross-tested in a Myanmar environment) found blocking only takes effect for VPN sessions established AFTER a detection policy is pushed; a VPN already connected before the policy loads is never blocked or logged, regardless of signature type (SNI or server-IP).

TSG engineers confirmed Redirect/Insert/Hijack policy actions fail (while Replace succeeds) against single-page-app style in-page search on both Twitter and Facebook, because the searched-for URL is never actually transmitted over the network (client-side routing) for those actions to match against.

TSG engineers explicitly acknowledged to an Ethiopia customer that the system's application-identification statistics over-count Psiphon3 and Freegate due to misidentification, inflating their apparent traffic share (e.g. Psiphon3 appearing in the application Top-2 despite the customer reporting no active blocking of it), and that Netflix's ranking also varies drastically by sort metric (bytes vs. sessions vs. unique client IP).

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.

Internal project code "K18" is a Kazakhstan TSG deployment: a 2022-10 ticket requests updating the "Data-Center" field in ADC device provisioning files from "Nur-Sultan" to "Astana", directly tying K18 to Kazakhstan. A separate cabling-documentation ticket references a physical site in Aktau, a Kazakh Caspian port city.

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.

A Fujian-site performance incident (single-core CPU pinned >90%, packet loss) traced to a large keyword-object list (~400 hex-encoded keywords, described as connected-vehicle-related) being scanned per-packet by components named libmaatframe, librulescan, and fw_http_plug. Removing unused keyword objects resolved the packet loss.

A known Psiphon3 relay IP, already in the signature set, wasn't blocked because it used destination port 179 (BGP): TSG's switch/distribution board bypassed port-179 traffic without forwarding it to the compute board for inspection at all (confirmed at the E21/Ethiopia site). A separate domain-whitelist mechanism can also override deny actions. Fixed by routing port-179 to compute.

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.

TSG supports a LUA-scriptable plugin that, when traffic matches a proxy-policy condition, injects a user-supplied HTML response back to the client (C2S direction), with template placeholders for live substitution of timestamp, content-length, a per-hit random token, and a configurable redirect URL.

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.

A TSG license's registered organization changed from "Geedge工程部" to "CEIEC" between 2022-04 and 2023-01 re-licensing of the same test environment. CEIEC (China National Electronics Import & Export Corp) is a state-owned trading conglomerate, consistent with "中电" references elsewhere.

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.

sapp has a CPU-overload protection mechanism that bypasses inspection when new-session rate is high enough (observed: 71 threads, ~50K new TCP/sec, ~32K new UDP/sec at a P-POC site). Treated as by-design; only the specific reported instance wasn't reproducible.

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.

At export site "E21" (naming consistent with Ethiopia elsewhere in this batch), Traffic Logs run across 13 servers with 40TB disk each (520TB total); Session Records consume ~7TB/day and Security Events ~1.5TB/day, giving a rough sense of logged traffic volume.

TSG's traffic pipeline has an encapsulation-handling layer called "marsio" (versions marsio4/marsio5) sitting in front of "sapp" (the core stream-processing engine). For unencapsulated mirrored traffic, a "wired_graft" plugin injects link/circuit identifiers into the MAC address field of copied packets so downstream session logging can recover which physical link a flow came from; for encapsulated traffic (e.g. VXLAN) marsio itself must expose that metadata.

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.

A crash backtrace from an Ethiopia-site TSG-OS node reveals internal DPI plugin architecture: a core 'sapp' binary (/opt/tsg/sapp/sapp) loads protocol-dissector plugins (dtls, tsg_master.so) chained through a 'marsio4' packet-processing worker, with a KNI/DPDK-style packet path (eth_entry -> ipv4_entry -> vxlan_entry -> gtp_entry -> dtls dissector). The specific bug was an uninitialized DTLS hello-verify cookie field.

TSG has a configurable, policy-driven TLS interception (MITM) engine (service: certstore) with per-connection 'Trusted'/'Untrusted' certificate profiles, a certificate-pinning-detection classification ('Pinning' vs 'Not Pinning'), and a Dynamic Bypass toggle, tested against *.badssl.com as of TSG 22.11/22.12.

Multi-engineer forensic investigation (pcap, JA3 hashing, TSG session-log correlation) at an Ethiopia site into tv.cctv.com being intermittently unreachable concluded the blocking was NOT done by TSG itself but by a separate, more-client-proximate network censorship system. That system dropped ClientHello-stage TLS1.2 sessions matching cctv.com's SNI, had degraded filtering ability once the client renegotiated to TLS1.3, and at one point misclassified cctv.com traffic as TikTok.

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).

TSG's Psiphon3 signature is a multi-stage stateful match (IP, then protocol/SNI, then a negative/NOT condition) where the NOT condition is only evaluated once, explicitly at the 8th packet of a session. Sessions carrying fewer than 8 packets never reach that evaluation point and are never flagged as Psiphon, regardless of actual protocol. Confirmed in production (E21) as the root cause of a customer-reported partial bypass.

TSG runs an automated program named 'vpn-thwarting' that calls the CM management API hourly to push freshly-learned Psiphon3 server IPs into a live blocklist object (dynamic_psiphon_ip); at the time of this incident the object held roughly 70,000-73,000 IPs, sourced from a companion automated-learning system referred to as 'CN'.

At export site "E21," TSG has a named detection object "Psiphon-Server-Signature"/"Psiphon-Server-APP"; two near-identical sessions to the same Psiphon-associated IP (82.223.55.87) over SSH/port 22 were logged, but only one was correctly tagged — a session-to-session consistency gap in the signature match.

A debugging ticket for sites "Old Airport-PE" and "Bole-IGW" (naming consistent with Addis Ababa, Ethiopia) confirms the customer verified Psiphon3, YouTube, Facebook, and Telegram blocking as working well during independent testing, and reveals the operational session-correlation method used when packet captures and system logs must be cross-referenced across NAT: JA3_HASH + server IP + client public IP + SSL SNI.

For Hotspot Shield's IKEv2 mode, SNI-only blocking failed because logged SNI hits corresponded to the VPN's own domain/CDN traffic while tunnel-negotiation domains (journalissue.us, middle-island.us) went unlogged; switching the rule to match DNS query name (qname) for those specific domains successfully blocked the connection.

Geedge's QA team tested Hotspot Shield VPN's three underlying protocols (Hydra, IKEv2, WireGuard) against a shipped TSG signature across Windows/Android/iOS. Hydra and WireGuard were blocked on effectively all tested nodes; IKEv2 was NOT blocked on the "Auto" and "Streaming" server-selection modes on any platform tested.

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.

TSG's App Sketch DB includes a "TachyonVPN" signature. A 2023-06 report found ordinary browsing to microsoft.com misclassified as TachyonVPN in security event logs; closed Nov 2024 with no confirmed fix.

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.

TSG's core traffic-processing daemon is named tsg_master (GitLab repo git.mesalab.cn/tango/tsg_master, part of the "TSG Appliance" project group). A 2023-07 field incident (site "P19") showed a single-core deadlock in tsg_master's log-sending path (function tsg_send_log) causing 100% CPU on one thread and packet loss; fixed in tsg_master-6.0.38 and shipped via the tsg-os-buildimage repo.

TSG's URL-blocking (P19 site) failed to block a second, near-simultaneous TCP session Chrome opens per HTTP request when that session's first-data-packet arrival lagged the SYN by 45+ seconds, because TSG's connection 'opening timeout' parameter defaulted to 10s and expired first, letting the session fall out of tracked state. Fixed in a later release by raising the timeout to 60s.

Documents Geedge's standard operating procedure for building a new app-detection signature: collect a target's server IPs and FQDNs, create IP-match and SNI-match (ssl.handshake.extensions_server_name) feature objects, combine them via OR logic into a named custom "application", then validate via session-log reports filtered on that application label.

TSG-OS's boot/installer layer (tsg/tsg-os-onie) is a fork of the open-source ONIE network-switch installer. Commits confirm production support for Dell EMC R7525 x86_64 servers and Huawei Kunpeng 920 (AArch64) servers as TSG appliance hardware, alongside whitebox switch support (Accton).

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).

Two hands-on QA 拨测 (dial-test) reports document engineers connecting to Ooredoo Myanmar's mobile hotspot and to a 'Campana' WiFi network supplied by 'NCSC', then repeatedly browsing target sites (pixiv.net, zerohedge.com, internxt.com, littledayout.com, palaceskateboards.com, among others) while packet-capturing and cross-checking TSG 'statistics' policy hits against specific internal tap addresses (YGN-Ooredoo: 10.164.12.x, YGN-CPN: 10.169.12.x) -- direct field verification of inline/mirror tap function at named Myanmar carrier sites.

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.

Internal site codename "P" (seen as "P-POC" and "P19") likely denotes a Pakistan deployment; a June 2024 ticket coordinating an in-person visit by a Pakistani delegation to Geedge's Beijing office falls in the same period P-coded site tickets appear, offering loose corroboration.

Internal tickets name an Astana ("K18现场") datacenter by the Kazakh capital's name directly, plus wiring tickets for Karaganda and Zhezkazgan and a training outline describing an Almaty backup datacenter -- corroborating and adding city-level specificity to the Kazakhstan TSG deployment already in this corpus from secondary reporting.

Geedge ran an ongoing, systematically-numbered program extracting detection fingerprints for individual VPN and non-VPN apps for the Myanmar (M22) deployment, tracked with weekly-cadence per-app tickets; methodology combined packet capture, DNS/domain analysis, and fixed-port protocol identification, validated in a live test environment before shipping, with results tracked as "CT" (successfully blocked) or not.

Geedge runs a video-content-fingerprinting pipeline: a crawler pulls YouTube videos by topic, routed through mitmproxy with a custom trusted root CA to intercept TLS and capture per-video traffic, targeting ~100 captures per topic.

Internal test of a standalone DNS server explicitly described as "DNS劫持" (DNS hijacking): baseline resolution passes through upstream, but a test domain (www.baidu.com) is intercepted and returned a different IPv4/IPv6 address than its real one.

Geedge runs standing weekly signature-extraction assignments specifically against Freegate, Psiphon, Ultrasurf, and Tor Browser (by Play Store package name) across at least two projects, each with a dedicated engineer, spanning Android/iOS/Windows.

Signature extraction for named circumvention tools (Freegate, Psiphon, Ultrasurf, Tor Browser) explicitly captures QUIC SNI alongside TLS SNI and HTTP Host header, confirming TSG's fingerprinting pipeline covers QUIC transport, not just TCP/TLS.

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.

M22's extraction against "VPN Hero" (OpenVPN-based) recovered 13 FQDN + 13 IP indicators; FQDNs follow a "zampakuto...shop" template. Post-signature testing in the Myanmar demo environment found no successful connections on Android/iOS.

Geedge extracted and analyzed Betternet VPN's underlying protocols (WireGuard, a proprietary "Hydra" protocol using spoofed-domain TLS 1.2, and IKEv2), and found the Hydra protocol could be "completely blocked" via JA3 TLS fingerprinting; IKEv2 was blocked via UDP port 500/4500 policy, and thousands of VPN server IPs were extracted as a supplementary IP blocklist.

Documents the exact methodology used to derive a block signature for 'Giti VPN': TLS interception (fiddler) to decrypt the app's traffic, identifying its control/initialization domain and a second per-session domain pattern, then blocking by those two domain-name features rather than deep packet content.

Geedge's non-VPN app signature-testing program is a numbered catalog reaching at least #551-600 as of 2024-07, tested against current Android/iOS builds -- systematic coverage across hundreds of apps, not a narrow VPN-only list.

Project "M22" runs a standing weekly program to extract and patch detection signatures against "Turbo VPN": automated dial-testing continuously discovers server IPs (tens to hundreds/week), each batch packaged into a dated JSON patch file, validated for both blocking efficacy and false-positive risk before rollout. Ran continuously Aug-Nov 2024 in the source ticket.

For 'VPN Turkey' app characterization, the signature-extraction team used Fiddler (a TLS-intercepting local proxy) to decrypt the VPN app's own control-channel traffic and read its server list directly, rather than only passively capturing live tunnel traffic. Repeated on a roughly weekly cadence over several months, each time recording how many new server IPs appeared.

The same M22 weekly-extraction program runs in parallel against "7VPN": automated dial-tests repeatedly found its free-tier nodes already non-functional/blocked across weekly checks Aug-Oct 2024, indicating sustained monitoring even absent a signature update.

Geedge extracted ProtonVPN server IPs using the app's own debug-log output to find its server-list API endpoint, directly querying it to harvest ~5,800 server IPs, then used automated repeated connection cycling to extract ~200 additional rotating IPs after the initial list was blocked; the app was subsequently reported fully blocked on Android, iOS, and Windows.

M22's VPN signature-extraction workflow, when API sniffing (fiddler) fails, escalates to decompiling the target APK: jadx-gui, then apktool -- which recovered node information for "Luna VPN" after the first two methods failed.

Myanmar deployment (M22) systematically reverse-engineered and blocked Orbot (Tor's official Android client) and ProtonMail, alongside numerous consumer VPN apps, via the AppSketch feature-extraction pipeline. Orbot: 287 server IPs extracted across multi-hop nodes, one connection mode fully blocked. ProtonMail: mail server IPs/FQDNs extracted, blocking verified as full service denial (cannot send, receive, download attachments, or create a new account) on Android and iOS.

M22 runs a large-scale automated pipeline against numerous commercial VPN apps: APK decompilation + HTTPS-proxy interception to extract servers/FQDNs, automated dial-testing at volume (one app: 17,554 dial-tests, 4,073 servers discovered, 94% 24-hour block rate), and OpenCV-based automated ad-dismissal to keep test automation running unattended.

Geedge fingerprinted several V2Ray-based VPN apps by their fixed API/bootstrap domains rather than protocol characteristics — blocking "V2 Pro" via pro.mucacherry.org, "V2 VPN" via v2.mucacherry.org, and "V2Net VPN" via api.v2net.live plus 5 rotating free-node domains (free1-5.v2n3t2.online / v2n3t.online) the app uses to fetch node lists.

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.

galaxy/tsg_olap/p19-file-sync-service is a Kafka-consumer-driven Spring Boot file transfer service explicitly namespaced "p19" — matching the taxonomy's WMS-UTR/P19 Pakistan site codename — confirming a dedicated TSG-OLAP infrastructure component built specifically for the Pakistan deployment's file-sync/HOS-storage needs.

An internal MESA Lab command log documents active development of hardware-accelerated DPI on a Barefoot/Intel Tofino2 programmable switch ASIC: compiling a P4 program named "tna_fsm_dpi" (finite-state-machine DPI) plus a related project "Deep4R" via the Tofino bf-sde 9.2.0 toolchain, against a switch reachable through an internal host ([email protected]).

Confirms an active Pakistan TSG-OS deployment (ACC license servers 10.10.10.159/10.10.20.159, Sentinel HASP hardware-dongle licensing) as of October 2023, corroborating Pakistan as a live customer, consistent with Amnesty International's 2025 'Shadows of Control' report.

PanGu's multimedia business schema defines dedicated service IDs for blocking AND monitoring based on speaker (voice) recognition, TV/radio station-logo ('台标') recognition, and face recognition (initially 0x10B-0x10D block / 0x18B-0x18D monitor as of Sept 2018, renumbered to 0x10C-0x10E / 0x18C-0x18E later that month) -- i.e. biometric/media-content classification is a native, named blocking capability in TSG's core policy engine, not just protocol/keyword/domain matching.

TSG's core policy-database spec (internal codename 'PanGu') formally defines proxy-layer 'Insert' and 'hijack' manipulation actions with configurable target IP/URL and, from May 2019, response-header fields -- plus a separate 'IP address impersonation' proxy service (business ID 0x206, PXY_INTERCEPT_IP) backed by a spoofing address pool (PXY_OBJ_SPOOFING_IP_POOL) -- i.e. HTTP response injection/hijacking and IP-level spoofing are named, first-class business rules in the schema underlying every TSG deployment, not ad hoc capabilities.

PanGu defines a configurable DNS response-spoofing subsystem (NTC_DNS_FAKE_IP_CB, NTC_DNS_RES_STRATEGY) supporting named 'answer groups' with a configurable number of fake answers returned per group (service ID 0x40 'dns欺骗'), i.e. DNS injection is a general, group-configurable policy primitive in TSG rather than a single hardcoded fake-IP response.

PanGu/ntc_http_collect is an HTTP-traffic collection tool (part of the broader "PanGu" / 盘古 system referenced elsewhere in this corpus) that extracts URL, referer, and packet-capture-machine IP from monitored HTTP sessions, applies a rule list (conf/http_url_filter.conf), and publishes to Kafka for downstream MESA/TSG processing.

PanGu defines explicit business/service IDs for webpage keyword blocking (0x28) and keyword monitoring (0x98), with a dedicated NTC_KEYWORDS_URL_LOG log table storing the URLs recovered from keyword-hit traffic -- confirming keyword-based content filtering is a named, first-class TSG business rule with its own audit log, separate from domain/IP/SNI blocking.

TSG's SSL/IPD logging schema records a hit_pos field on every SSL-blocking log entry (NTC_SSL_LOG, IPD_SSL_IP_LOG) whose value is explicitly one of SNI, SAN, or CN -- confirming TSG's TLS-blocking decision can be attributed to, and therefore driven by, the certificate's SAN or CN fields, not only the ClientHello SNI extension.

A repo under a "PanGu" (盘古) namespace, "t2httpcontentscanner" (component T2_HTTP_DIG_BIZ, i.e. an HTTP-layer inspection/scanning business module), bundles an HTTP content-scanning DPI plugin together with a packet-injection header (stream_inject.h); its final 2019 commit updates both a third-party "丁牛" (Dingniu) dynamic library dependency and a "主动测试脚本" (active-probing/active-test script), indicating active-probing tooling shipped alongside this HTTP scanning+injection module. This appears to be a separate or predecessor DPI line from the sapp/MAAT stack documented elsewhere in this corpus.

The PanGu/pangu_valve repo implements MAAT's live blocking/throttling distribution layer: it consumes Redis-backed MAAT config tables (APP_DOMAIN, APP_POLICY, LIMIT_DOMAIN, APP_STATIC_SEV_IP, APP_DYN_SEV_IP_CB, LIMIT_DYN_IP_CB) and pushes reference-counted domain/IP block and rate-limit rules to inline ("串联设备") network devices, scoped per inline-device business ID.

PanGu documents a dynamic VOIP-blocking pipeline where a system named 'Eastwatch' generates four-tuple blocking rules from VOIP call-detail ('FD') logs, which are then pushed by the policy gateway ('阀门') to a downstream component named 'C3' (MM_DYN_VOIP_DROP table) -- two previously unseen internal component names in this corpus tied specifically to real-time VOIP call blocking.

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.

A design document for "PDNS" specifies a recursive DNS resolver that dynamically monitors per-user behavior and applies differentiated blocking policy: NXDOMAIN or redirect-IP responses per target domain via BIND9 RPZ, a front-end "user reputation" score that adjusts per-user policy based on request history, and planned support for multiple ingress methods including encrypted DNS. The working prototype demonstrates source-IP-based user classification into block/passthru groups with policy synced via BIND9 zone transfer from a primary RPZ server.

A standalone DPI plugin (liuchang/pkt_seq_matcher, built against Hyperscan and a Ragel-generated state machine) computes per-flow packet-payload-length sequences and matches them against compiled patterns, explicitly excluding zero-payload packets from the length calculation -- a packet-length statistical fingerprinting approach, the kind of technique used to identify fully-encrypted/obfuscated pluggable-transport traffic by its handshake length signature rather than by content.

An internal Go tool named 'prober' (handingkang/prober, from the same author as a separate 'alias_prefix' detection script) implements packet-sending ('发包') functionality and a 'test ingress/egress correlation' ('测试出入口关联') feature -- an active-probing capability for testing whether traffic entering and exiting a network point can be correlated, consistent with GFW-style active probing of candidate circumvention servers.

Internal project codenames decode to specific customers: M22 = Myanmar (operators Mytel, Ooredoo Myanmar, and ATOM; sites YGN=Yangon, MDY=Mandalay), K18 = Kazakhstan (site renamed Nur-Sultan to Astana in OLAP config), E21 = Ethiopia (operator Safaricom Ethiopia; sites ADAMA-PE/SSM-PE to KLT-IGW/SHQ-IGW), WMS-UTR = Pakistan.

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 raw, verbatim capture of ProtonVPN's own "LogicalServers" API response (127 server entries with entry/exit IPs, WireGuard X25519 public keys, and country/city metadata) sits alongside a MAAT "ProtonVPN_ip"/"ProtonVPN_fqdn" signature in the same corpus, indicating the operator harvests VPN providers' own server-list APIs to seed IP/domain blocklists -- the same methodology documented for the Psiphon-IP-harvesting "vpn-thwarting" pipeline (CyberNarrator), here shown applied to a second, unrelated VPN provider (ProtonVPN).

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.

A MAAT/AppSketch signature named Psiphon-QUIC-Payload (id 4203) flags Psiphon's QUIC transport by matching an exact UDP client-to-server first-packet payload length of 1252 bytes combined with an internal app_id and an extensive destination-IP CIDR allowlist covering hundreds of /22-/24 blocks -- i.e. Psiphon-over-QUIC is fingerprinted by a fixed early-packet length rather than by content.

On the E21 (Ethiopia/Safaricom) deployment, TSG blocked Psiphon3 via ~1.69M known server IPs; in one ~3.5hr window, 76,496 unique client IPs still attempted Psiphon3, which accounted for 14% of total bandwidth, 5.96% of sessions, and 1.32% of unique client IPs despite the active Deny policy.

The same online-config repo's Flink ETL "completion" topology (deployed at both DC and NC tiers) processes a dedicated "PXY-EXCH-INTERMEDIA-CERT" event stream alongside SYS-PACKET-CAPTURE-EVENT and ETL-SESSION-RECORD-COMPLETED — production-pipeline evidence that proxy/TLS certificate-exchange (i.e. TLS-interception) events are logged and processed at scale across live field deployments, not just tested in isolation.

A MESA Lab repo (daxiaoxu/xmr_bsexpr3) contains standalone detection/fingerprinting scripts specifically targeting QQ (Mobile and Windows clients) and WeChat, alongside a script named PSK_LifeTime.py, suggesting TLS session-resumption / PSK-ticket lifetime is being explored as a traffic-fingerprinting feature for identifying or tracking these apps' encrypted sessions.

2021 MESA meeting notes describe drafting a patent disclosure for "全透视内容在线解析" ("full-transparency online content parsing"), alongside "用户测绘" (user/asset mapping) work and a "整形平台" (reshaping platform) built on S3-compatible (minio) storage -- suggesting an online content-decryption/parsing capability under active IP filing, though the notes do not specify the underlying mechanism.

A MESA Lab researcher maintains a small repo explicitly named "quic-block" (LiFulian/quic-block) containing a single C++ source file "quic_lfl.cpp", indicating standalone development work on QUIC/HTTP-3 blocking logic; the repo's minimal size (5 files) and "studyGit" commit suggest early-stage or personal research rather than a shipped product module, so this should be read as evidence of active R&D interest rather than a confirmed deployed capability.

A TSG-OLAP Storm topology (galaxy/tsg_olap/storm/radius-account-knowledge, bolt class RadiusCleanBolt.java) cleans and streams carrier RADIUS accounting logs via Kafka as a standing, general-purpose TSG-OLAP pipeline component (with an EAL4/Common-Criteria-tagged build branch), structurally similar to — but broader than — the Pakistan-site CyberNarrator RADIUS/AAA subscriber-correlation engine already documented in this corpus.

A "tango"-group RADIUS accounting plugin (PanGu/ntc_radius_plug, originated at IIE/CAS) parses configured RADIUS packet types and emits Kafka log fields partitioned by account, providing plausible underlying data-capture plumbing for the subscriber-to-session correlation seen elsewhere in the platform (IP-learning-graph, CyberNarrator's RADIUS-based identity resolution); direct wiring between this specific plugin and those downstream systems was not confirmed in this artifact alone.

The general-purpose TSG big-data pipeline (galaxy/tsg_olap/dynamic_complement) includes dedicated "FlumeRadiusOnOffInterceptor" and "FlumeSubscriberInterceptor" modules plus a standalone "用户名写入Hbase程序和上下线日志程序" (username-to-HBase-write and login/logout-log program) built against tickets TSG-1845/TSG-2020, showing RADIUS-based subscriber-identity correlation is wired into the general OLAP data pipeline used across deployments, not confined to the Pakistan-specific CyberNarrator subscriber-correlation module already documented.

TSG's galaxy/tsg_olap analytics subsystem runs dedicated Storm topologies (radius-relationship-hbase, log-subscriber-hbase-datacenter) that ingest carrier RADIUS/AAA accounting data and subscriber-ID logs from Kafka and persist account-to-framed-IP relationships into HBase, generalizing the RADIUS-based subscriber correlation documented elsewhere at the Pakistan CyberNarrator deployment into standard TSG OLAP infrastructure not tied to one customer.

A MESA graduate-project spec ("网络流量随机性检测技术研究与系统实现") calls for a prototype implementing 10+ classical statistical randomness tests (frequency, approximate-entropy, runs, matrix-rank, overlapping-subsequence, autocorrelation, etc., in C, 3000+ LOC) against TCP/UDP payloads to classify traffic as "encrypted data flow" (high entropy) vs. not, trained/validated on a 50GB+ labeled corpus of actively-generated encrypted and compressed traffic.

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 MESA Lab traffic-fingerprinting dossier builds DPI detection material for third-party remote-access/tunneling software (Sunlogin/花生壳, TeamViewer, and a self-hosted OpenVPN test deployment) by cataloguing each tool's domains/IPs, TLS SNI values, HTTP User-Agent and Host headers, and UDP ports, with traffic captured and labeled per discrete user action (login, add device, start remote session, quit, logout) — exactly the raw material an app-identification signature system would be built from.

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.

The same feature spec adds a "定向攻击检测" (targeted-attack detection) mechanism: the front-end tracks per-rule (configID) hit counts against a threshold/interval, and once exceeded can throttle or fully suppress emission of RST/block packets and logs for that rule (action codes include "do not send block packets," "sample block packets") -- an explicit rate-limiting countermeasure against the operator's own RST-injection infrastructure being weaponized for reflection/availability attacks, the same attack class (Bock et al., "Weaponizing middleboxes"; "Your censor is my censor") cited in this same lab's own literature survey (see companion finding 2026-mesa-censorship-research-survey-f8c349).

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.

MESA Lab meeting notes (Nov-Dec 2021) document development and a staged production rollout of a new sapp plugin that identifies encrypted video streams via "burst" (packet-timing/size-burst) traffic features designed to generalize across varying network conditions, trained with machine learning, with a first burst-rule version scheduled for live deployment and sapp modified to log additional features for continued training.

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.

sapp has a global CPU-load-based 'under_ddos' bypass mode: once realtime CPU usage on a worker thread exceeds a configurable threshold (95% in the shipped default), sapp enters a global bypass state in which matched streams skip all plugin processing (no classification, no blocking) until load recovers, smoothed via an EWMA and a multi-second recovery-observation window. A separate anti_flood.conf additionally hard-drops SYN floods above 15000pps and UDP/DNS floods above 1000pps at the packet-filter level, while explicitly whitelisting DNS (port 53) and SIP (port 5060) from that drop.

sapp's packet_io configuration exposes three deployment topologies (mirror, inline, transparent) and, for non-mirror modes, four packet-injection paths for delivering blocked/modified traffic: default system routing, VXLAN encapsulation to an inline device over UDP, or raw Ethernet delivery to a single or multiple next-hop gateways (with configurable spoofed source/destination MAC). This confirms the same sapp codebase backs both passive-tap (RST-only) and fully in-line (drop-capable) TSG deployments.

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.

The gdev_block sapp plugin decouples DPI classification from enforcement: once sapp identifies a stream it wants blocked, it dynamically loads /opt/MESA/lib/libc3client.so and sends a 5-tuple (src/dst IP, src/dst port, protocol) block rule with action GRULE_ACTION_ADD to an external 'c3' rule-distribution server over a licensed connection (auth_data license key from etc/gdev_block.conf), rather than dropping the packet itself. This is a distinct blocking path from sapp's own in-process RST injection, pushing enforcement out to a separate gateway device ('gdev').

SAPP's internal developer manual documents three generic "packet-send" interfaces exposed to every business plugin: MESA_kill_tcp (builds and sends a TCP RST matching the current flow's four-tuple/sequence numbers to forcibly terminate a connection), MESA_kill_tcp_synack (sends a forged SYN/ACK so the client can never complete a handshake with the real server), and MESA_inject_pkt (injects arbitrary application-layer payload toward either side of a flow). This confirms RST-injection and payload-injection are first-class, reusable platform primitives, not one-off code, and that mrzcpd is the mechanism that re-injects sapp-generated blocking packets into a mirrored/passive-tap link (consistent with taxonomy.yaml's mrzcpd note).

Primary-source MESA Lab wiki documentation confirms SAPP ("Stream Analyse Process Platform") is a plugin-based traffic-inspection engine achieving 10-40Gbps per hardware unit, deployable either inline (串联) or as a passive mirror tap (并联), and exposes core platform APIs available to any business-layer plugin for forging a TCP RST (MESA_kill_tcp), spoofing a fake SYN/ACK to block connection establishment (MESA_kill_tcp_synack), and injecting arbitrary application-layer data into an established flow (MESA_inject_pkt).

sapp ships a native protocol-identification plugin for ISAKMP/IKE (IPsec VPN tunnel setup, UDP port 500): it validates ISAKMP header structure (fixed reserved bits, exchange type range, payload type, initiator/responder cookies matching the RFC 2408 constraints) before establishing a stateful 'ipsec' tunnel session and handing off to a downstream business/policy plugin. This confirms IPsec/IKE VPN detection is a first-class, built-in sapp capability, not something bolted on via the separate AppSketch/glimpse_detector signature systems.

A raw sapp deployment/config script shows an operator toggling `kickout_udp_stream_enabled=0` to `=1` in sapp.toml (via sed, in place on a live tsg-traffic-engine-vsys-1 install), alongside RPM upgrades of sapp's ssl/firewall/dtls/utable/libmaatframe components, and separately disabling SEND_SESSION_RECORD and SEND_FILE_STREAM_RECORD logging flags in main.conf — confirming sapp has an explicit, operator-toggleable feature to actively terminate UDP streams it flags, independent of whatever passive detection triggered the flag.

A leaked shell hotfix script shows an operator live-patching a production sapp instance — installing sapp-pr-4.3.59.c5b96a4-1.el8.x86_64.rpm, dropping in traffic_sketch.so under sapp's stellar_plugin directory and libfieldstat4.so under the framework lib, and tuning sapp.toml stream parameters (max_timeouts_per_sec, kickout_udp_stream_enabled, bloom_library, TOPK_UPDATE_MS) — concrete evidence of sapp's plugin architecture and active operational tuning cadence.

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.

A June 2021 MESA Lab test report ("精管流量初步分析报告") measured a live TLS-decryption pipeline feeding two sapp instances -- sapp A ingesting raw encrypted traffic via mrzcpd, sapp B ingesting plaintext from a third-party decryption platform over a Unix domain socket -- and found decrypted plaintext covered only 4.85% of raw traffic bytes and 7.4% of port-443 connections, with average MITM decryption latency of 1741ms (range 158-6000ms) across 2957 matched connections.

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).

A sapp performance-test report benchmarks the traffic engine under ~11 Gbps / ~330 Kpps of test-instrument load, reporting sapp CPU usage averaging 932.53% (i.e. roughly 9-11 cores) with only 0.053% packet loss at the functional-endpoint receive stage, and separately reports resource usage for a distinct shaping component named "nirvana" (整形nirvana, CPU avg 85.15%) — a component name not previously seen in this corpus's product taxonomy, suggesting sapp's traffic-shaping stage is a separate named module worth tracking as a taxonomy candidate.

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.

sapp's TCP RST-injection ('kill_tcp') subsystem is configurable per deployment with an auto-remedy retry count and a two-part numeric 'signature' embedded in injected RST packets (signature_seed1/signature_seed2), plus an option to have the reset instead issued via a separate inline device rather than from sapp itself. The low-level injection API (sapp_inject_pkt) explicitly supports excluding/including the IP header so a companion 'assistant' module can forge the TTL, IP ID, and TCP window to match the live flow before injection, and logs the exact spoofed ttl/ipid/checksum values it sent.

A MESA engineer wrote a SAPP business-layer plugin (v1 shipped to GitLab) that fingerprints network scanning/probing tools, producing a "scanning/probing tool fingerprint-database construction report." The companion fingerprint report documents Nmap's default host-discovery probe sequence (ICMP echo request, TCP SYN to port 443, TCP ACK to port 80, ICMP timestamp request) captured against a live target.

Commit history in the core sapp DPI engine repo (MESA_Platform/sapp) shows its RST-style blocking/injection path is internally called "欺骗包" (literally "deceptive/spoofed packet") injection, implemented via a sapp_inject_ctrl_pkt function that sends forged control packets to all devices opened through the marsio packet-I/O layer; ticket TSG-20317 documents active, ongoing optimization of "inject packet duplicate traffic detection" performance in this code path as of 2024.

A 'feature_extract_plugin' repo built for MESA Lab's sapp platform (using the same '*_entry.cpp' plugin-registration pattern seen elsewhere in sapp's plugin family) implements dedicated SSL/TLS parsing and statistics entry points (sslparse_entry.cpp, sslstat_entry.cpp) alongside a generic stream-statistics entry (stmstat_entry.cpp), indicating sapp has an extensible plugin architecture specifically for extracting TLS-connection features -- consistent with TLS fingerprinting / classifier feature extraction -- beyond the base DPI engine.

The stellar/stellar-dev-env repo pins a paired release of sapp-4.3.38 with a companion component "stellar-c-1.0.13", built via an internal RPM repo hostname (el8.repo.internal.geedge.net.repo) and a "tsg_framework.sh" bootstrap script — evidence of a previously undocumented internal component ("stellar-c") versioned alongside sapp and an internal geedge.net package-repo infrastructure supporting TSG-OS builds.

A source comment in sapp's plugin-management init code names 'udp_teredo_identify_entry()' alongside 'gdev_keepalive_udp_entry()' as reserved, always-loaded built-in ('inner') plugin entries that bypass the normal dynamic-plugin registry — indicating sapp has a dedicated Teredo (IPv6-over-UDP NAT-traversal tunneling) identification capability compiled directly into the platform. The implementation itself is not in this file, only the reference.

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."

The lirenjie/lrj_vxlan sapp-plugin repo (2019-2020) implements a mirror/re-inject packet-processing plugin for VXLAN-encapsulated traffic that defaults to DROP for all packets and explicitly distinguishes two traffic-handling modes, "回流" (return-flow/mirror-received) and "回注" (re-inject), consistent with the mrzcpd/marsio architecture where sapp's blocking decisions on mirrored traffic are re-injected into the link.

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.

The 'galaxy/deployment/schema-updater-tool' repository's test schema catalog enumerates TSG/Galaxy's production log/event table set across ClickHouse, Druid, ES, and HBase backends, including radius_onff_log (RADIUS on/off subscriber events), gtpc_record (mobile-core GTP-C signaling), dos_event, active_defence_event, proxy_event, and security_event_hits_log -- a concrete inventory of the telemetry TSG's analytics layer generates.

MESA Lab / IIE-CAS research (patent application no. 202410203156.3, "一种基于主动探测的Tor桥节点的隐藏节点发现方法及系统") built automated active-probing tooling that discovered 44 "ShadowBridge" instances and 71 hidden real-IP nodes behind public Tor bridges over a 3-month run, finding this hidden-node churn increased the count of ASes able to eavesdrop on bridge traffic by roughly 30.8%; the same effort built an automated bridge-collection pipeline (proxied Gmail-based bridge requests plus manual enumeration, ~8000 bridge addresses collected) and a private Tor test range including private obfs4 and meek bridge deployments.

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.

TSG's "shaping-engine" (tango/shaping-engine) implements bandwidth-shaping "Profiles" (fair-share token allocation, priority-based bandwidth borrowing, active queue management) driven by rules loaded directly from MAAT (shaper_maat.cpp/h, shaping_maat.json, migrated to MAAT's JSON rule format with UUID rule IDs), providing the likely underlying enforcement mechanism behind app-specific RateLimit deny actions such as the Psiphon/Freegate throttling documented in gap_tsg_api.

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.

Signal's built-in censorship-evasion feature routed traffic through Google infrastructure (SNIs clients3/4.google.com, inbox.google.com, android.clients.google.com), fully bypassing a TSG Deny policy as of July 2024 for messaging/file transfer (voice/video still failed).

The same JSON signature-rule format used for VPN-app detection (signatureName / andConditions / orConditions, matched on http.host or ssl.sni) is used at production scale for ordinary domestic consumer apps as well — individual signature files observed for Kuaishou, Taobao, the digital-RMB wallet app ("数字人民币"), and WeWork — confirming a single, general-purpose app-identification pipeline (consistent with the taxonomy's AppSketch/MAAT description) covers both everyday commercial traffic and circumvention tooling under one signature format and production cadence.

A sapp-based "single flow aggregation" module's header dependencies (Maat_command.h, Maat_rule.h alongside stream_inject.h and sapp_inject.h, plus wiredLB.h/wired_cfg.h) show sapp's Maat rule-matching engine and its packet/stream-injection subsystem share a common internal API surface within the same MESA include tree, corroborating that a Maat rule hit can directly drive inline packet injection within one sapp pipeline instance.

A dedicated, actively-maintained TSG_OLAP Flink streaming job (galaxy/tsg_olap/sip-rtp-correlation, 200+ commits through late 2024) fuses one-way SIP signaling records with their corresponding RTP media-stream records into unified bidirectional VoIP call records in real time, keyed by address/session state with configurable expiry -- a production system for reconstructing complete VoIP call metadata (parties, duration/state) from separately-captured signaling and media flows.

'voip-analysis/sip-voip-completion' is a Storm/Kafka/ClickHouse real-time pipeline that tracks SIP/VoIP call metadata at scale -- server and service-domain identification (VoipServer, VoipServiceDomain), client User-Agent fingerprinting (VoipUa), and caller/callee routing relationships (RouteRelationLog under a 'voipSipFromToLog' package) -- indicating a VoIP call-metadata/social-graph correlation capability distinct from simple VoIP-protocol detection.

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).

Internal spec for "spacemap-service", a passive-DPI-fed reconnaissance database and web UI that catalogs every observed website's IP/domain, geolocation, ASN, DNS server, CDN vendor, TLS certificate fields (issuer/CN/SNI), OS and web-framework fingerprint (via Wappalyzer), and WHOIS/ICP registration data, exposing reverse-lookup search by any single attribute (e.g. all sites behind a given cert issuer, ASN, or CDN vendor).

A leaked SQL migration renames/normalizes a session-attribute-dictionary entry to `ssl.analysis.sni_absent` (backed by virtual_table `ATTR_SSL_NO_SNI`), confirming the detection pipeline maintains an explicit, first-class boolean signal for "TLS ClientHello with no SNI present" — a classic tell for ECH, domain fronting, and custom TLS stacks that omit SNI to evade SNI-based blocking.

MESA Lab's "stellar" SSL/TLS decoder (ssl_decoder, packaged in test fixtures as "stellar-on-sapp") ships a dedicated regression test case captured against an Ethiopia (E21) target host, alongside TLS 1.3 ESNI, encrypted ClientHello (ECH), and TachyonVPN-client test pcaps, showing the decoder is validated both against E21-deployment-style traffic and emerging TLS privacy extensions.

"stellar" (stellar/stellar-2022) is a plugin-based protocol-decoder SDK (packet_io, plugin_manager, session_manager modules, with HTTP and DNS decoder components under active development through 2022) that runs on a "marsio mode" packet-I/O backend, showing the DPI decode layer beneath sapp is a modular framework supporting pluggable per-protocol decoders beyond SSL/TLS alone.

A full-featured DNS message decoder plugin ('stellar', stellar/dns_decoder) is built and packaged specifically to run on top of sapp (its own test fixtures bundle sapp-4.3.59 and stellar-on-sapp-2.1.2 RPMs), implementing complete DNS parsing including DNSSEC RRs (NSEC/NSEC3/RRSIG), multi-transaction TCP reassembly, and EDNS OPT records -- the depth of DNS parsing that would be needed to support MAAT's separately-confirmed NTC_DNS_FAKE_IP_CB fake-IP injection rule type.

The "stellar" DNS decoder plugin parses complete DNS messages including all standard resource-record types plus DNSSEC records (DS, RRSIG, NSEC, DNSKEY, NSEC3, NSEC3PARAM), and exports every answer/authority/additional RR as JSON per DNS transaction via a dedicated exporter, along with a separate CNAME-chain-only JSON exporter. This is full-content DNS resolution logging infrastructure feeding the wider "stellar" inspection pipeline; no DNS injection/poisoning/answer-rewriting logic is present in these two files, only passive parse-and-export.

TSG's DPI engine (sapp) runs a pluggable protocol-decoder framework called 'stellar' (packaged as 'stellar-on-sapp'); its HTTP decoder module (TSG-20446) explicitly parses and can intercept HTTP CONNECT-method tunnels and HTTP/1.1 Upgrade (HTTP/2, WebSocket) transitions, so traffic tunneled or upgraded inside HTTP is visible to and selectively handled by TSG's classification pipeline rather than passing through as an opaque TCP stream.

The "stellar" HTTP decoder plugin identifies HTTP CONNECT-method proxy tunnels (httpd_tunnel_identify) and, once a successful CONNECT response is observed, re-enters the payload as a nested HTTP stream (tracking tunnel_state transitions through session exdata) so that traffic carried inside an HTTP CONNECT tunnel continues to be parsed as HTTP rather than treated as opaque bytes — i.e. the DPI follows through simple HTTP-proxy tunneling rather than losing visibility at the CONNECT boundary.

A November 2024 commit to the stellar DPI engine's TLS decoder adds JA4 and JA4S TLS-handshake fingerprint calculation ("tls decoder support calculating JA4/JA4S fingerprint"), showing Geedge's core inspection engine has adopted the modern JA4/JA4S fingerprinting scheme (successor to JA3/JA3S) for client/server TLS fingerprinting as of late 2024.

"stellar-on-sapp" (232 commits) is a plugin/decoder SDK running on top of sapp, providing session/packet management (pub-sub message queue, per-session exdata) for protocol decoder plugins including HTTP, DNS, and GTP tunnel (mobile-carrier) decoding, plus explicit "Layer-7 proxy filtering" support. A separate FTP decoder plugin (stellar/ftp_decoder) built against the same sapp/stellar SDK confirms the plugin architecture covers additional protocols beyond HTTP/DNS/GTP.

A previously-undocumented sapp plugin named 'Stellar' (repo stellar/quic_decoder, packaged as stellar-on-sapp, depending on sapp-devel and OpenSSL) implements 'quic_deprotection' — QUIC packet-protection removal — as a component distinct from the older MESA_Platform/gquic plugin, sharing the same test corpus of GQUIC/IETF-QUIC pcaps (RFC9000, chlo-fragment, no-SNI cases). This is a candidate new product entry for the taxonomy: a second, apparently newer QUIC-inspection engine alongside gquic.

The "stellar" QUIC decoder plugin implements a complete RFC 9001 QUIC Initial-packet header- and payload-deprotection pipeline (HKDF key derivation from the well-known public IETF/gQUIC initial salts, AES-128-GCM payload decryption, AES-CTR header-protection removal) to decrypt QUIC ClientHello messages in real time, reassembling CRYPTO frames fragmented across multiple UDP datagrams, and extracts SNI and User-Agent from the decrypted handshake. It separately parses legacy Google QUIC (gQUIC) CHLO tag-value blobs (TAG_SNI / TAG_UAID) for older/non-IETF QUIC variants, and recognizes version ranges for a long list of QUIC implementations (mvfst, quant, quicly, msquic, mozquic, picoquic). A config flag (DECRYPTED_SWITCH) toggles whether the decrypt-and-inspect pass runs.

"stellar" (git.mesalab.cn / geedgenetworks.com) is a C++ core DPI packet-processing engine with protocol decoders (HTTP, FTP, mail, QUIC, RTP, SIP, DTLS, SSL, DNS, SOCKS, stratum) and a dedicated packet-injection module (src/stellar/inject.cpp) with an extensive TCP-RST-injection test suite covering injection timed after SYN, SYN-ACK, first C2S payload, and sub-ACK. It integrates the MAAT rule engine (security_enforcer.cpp / scanner_maat.c, "Security enforcer maat plugin table"), the Marsio packet-I/O framework (marsio_io.cpp), and glimpse_detector as an integrated decoder plugin ("integration glimpse_detector", "rename to lpi plugin").

A DPI session-plugin ("stellar" framework) SSL/TLS decoder fully parses live ClientHello/ServerHello handshakes, computing JA3/JA3S fingerprints (MD5 over version+cipher-suites+extensions with GREASE values stripped per the standard JA3 spec), extracting plaintext SNI, explicitly flagging whether a ClientHello carries ESNI (extension type 0xFFCE) or ECH (extension type 0xFE0D), and decoding full X.509 certificate chains (issuer/subject RDN sequences, SAN, validity window, serial, pubkey, signature algorithm) in real time. It also recognizes TLCP 1.0 (China's national "国密"/GmSSL TLS variant) as a distinct protocol version alongside SSLv2 through TLS1.3.

TSG's galaxy-data-platform business-API module models 'SubscriberId' as a first-class entity in an ArangoDB knowledge graph (SubscriberIdPath.java, SubscriberIdProviderImpl.java), sitting alongside dedicated FQDN and IP path providers (FqdnProviderImpl, IpProviderImpl) in the same query strategy interface. A separate, actively-maintained Flink topology (radius-account-knowledge) ingests carrier RADIUS accounting records per-VSYS (multi-tenant) dimension to populate this graph, giving analysts a queryable link between a subscriber identity and the IPs/domains it touched.

swarmkv is an internally-built, CRDT-based distributed key-value store (Redis-like, with Bloom filter, HyperLogLog, Count-Min Sketch, and token-bucket data types) referenced directly by TSG ticket numbers (TSG-20539, TSG-21840, TSG-15595) for its Committed-Information-Rate/Committed-Burst-Size (CIR/CBS) token-bucket throttling — the distributed state layer backing TSG's cluster-wide rate-limit/throttling policy actions.

The same import-format reference document specifies wildcard-keyword bulk-import formats spanning IP/CIDR ranges, FQDN, URL, email Account, Subscriber ID, raw hex-encoded byte keywords (isHexbin flag), APN, and — notably — "Http Signature" imports scoped to a specific HTTP field (User-Agent, Cookie, Set-Cookie, or Content-Type), letting an operator add an arbitrary HTTP-header-based match/block rule via a simple wildcard text import rather than custom engineering per rule.

'tcpdump_mesa' (Geedge's tcpdump fork, packaged as an RPM dependency of the sapp DPI role) adds a '-g' greedy-jump mode that filters and captures by the innermost IP/port inside tunneled/encapsulated traffic (coordinated with sapp over a control connection), and can capture packets sapp routes around DDoS-bypass handling -- confirming TSG's packet-capture tooling is explicitly built to see through tunnel encapsulation rather than only inspecting the outer transport.

pzx/tensor-k18 packages a MAAT-integrated processing component ("tensor") with three separate customer/site config profiles (IPZY, T1-2, YSP), each with its own maat_redis.conf, and the repo itself is named "tensor-k18" — direct evidence this component is built and configured specifically for the K18 (Kazakhstan) deployment.

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 June 2023 MESA engineering report on "TF项目" ("project TF") documents TSG configuration changes alongside CM and OLAP components, and explicitly records resolving a "hijack-injection function" (劫持注入功能) interface issue where policy was not taking effect, followed by completed hijack-effect verification and active-defense (主动防御) effect verification -- naming two further internal tools, netflood and houyi, used alongside sapp for packet injection, plus a git.mesalab.cn/active-defense repository.

The tango/tfe-kmod repo is a DKMS Linux kernel module that reconstructs live TCP connections from out-of-band control messages (CMSG), using the TCP_REPAIR_WINDOW socket option to set window state without a handshake and adding special-case handling for protocols such as SSH where the server sends the first packet -- kernel-level infrastructure letting a userspace process ("TFE") transparently take over or inject into an in-progress TCP flow.

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.

An 11,266-line, apparently frequency-ranked domain list dominated by TikTok/ByteDance CDN domains (tiktokv.com, tiktokcdn.com, ibyteimg.com, etc.) also contains at least 11 VPN-provider domains interspersed (urban-vpn.com, nordvpn.com, avira-vpn.com, sofavpn.com, brightvpn.com, itopvpn.com, flashvpn, top10vpn.com, arpavpn.com, cnvpn001.com), consistent with a co-occurrence-derived FQDN classification/training list rather than a curated blocklist — i.e. domains commonly seen alongside TikTok sessions (plausibly because users pair TikTok with a VPN) feeding an app-ID signature or feature list.

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.

MESA Lab operates an internal Tor "cyber range" (靶场) that builds and deploys custom Docker images running a modified Tor codebase across directory-authority, relay, guard, exit, client, and onion-service roles for hands-on experiments; this doc walks through forcing the deprecated Tor v2 onion-service protocol back on for a specific "v2 hidden service discovery" exercise.

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).

A single MAAT-format signature named "tor_ip" enumerates at least 802 distinct IPv4 addresses matched against ip.dst, i.e. a dedicated, large-scale Tor relay/bridge IP blocklist maintained as a first-class detection signature alongside the commercial-VPN signatures in the same corpus.

chongming/traffic_replay is a Flask/tcpreplay-based QA harness that replays curated pcaps against a TSG instance to exercise its decoders, including SSL fixtures specifically named ssl_ech_false.pcap, ssl_no_sni.pcap and ssl_tls13.pcap alongside esni.pcap, openvpn.pcap, and major-platform captures (facebook/google/twitter/ youtube). A companion update_tsg_ca.py/tsg_ca.txt installs a TSG-issued CA cert on the test client, confirming the QA environment exercises TLS interception as part of routine detection testing.

A SQL migration renaming TSG's audit-log 'op_target_type' enum from human-readable admin-UI labels to API slugs exposes the full first-class feature list of the TSG management console, including 'Insert_Script'->insert_script and 'Hijack_File'->hijack_file (content-injection features distinct from the previously-documented cert-implant side), alongside 'Decryption_Keyrings'->ssl_keyrings, 'Trusted_Certificate_Authorities'->trusted_ca_cert, 'Response_Page'->response_page, 'Cached_Intermediate_Certificates'->exch_intermedia_cert, and 'HSM'->hsm, corroborating and extending the certstore/content-injection capability descriptions with concrete named UI object types.

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.

TSG's proxy-manipulation policies go well beyond blocking: confirmed live capabilities include Redirect, Insert, Hijack, and Replace actions, demonstrated live-testing JavaScript injection into an intercepted HTTPS response (Bilibili/Baidu search-box word substitution via injected event listeners) and Request-Body content replacement against Google/YouTube's live API traffic (youtubei/v1/search), both requiring full TLS interception of major-platform HTTPS traffic.

TSG ships a built-in periodic-report feature ("Tiangou Secure Gateway" branded PDF exports) that breaks down traffic per major global platform — observed for YouTube, Facebook, Instagram, Netflix, Snapchat, BBC, and Bigo across six independent report exports — via "SNI Report of Overseas APP" and "Server IP and Location of Overseas APP" tables, giving operators granular, per-platform SNI- and IP-geolocation-based usage visibility as a standard dashboard capability, not just blocking.

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 MESA Lab experiment re-identifies individual users across time solely from which domains they visit, using one-hot/frequency "domain access vectors" (Jaccard, overlap-coefficient, cosine, Euclidean) computed against real production HTTP logs pulled from a ClickHouse table named tsg_galaxy_v3.connection_record_log_http_domain. The best-performing configuration (Alexa top 100-10000 domain list, overlap coefficient) distinguished the same user's adjacent-hour sessions from other users' sessions with high separation (~0.19 vs ~0.88 average difference).

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.

The official TSG Administrator's Guide (customer-facing LaTeX source in tsg-manual/tsg-admin-guide, versioned releases through 2021) contains a dedicated 'Decryption' chapter and ships an 'AppSketch_Model' architecture diagram alongside chapters on Policies, Objects, and Monitoring -- confirming TLS interception and AppSketch-based app identification are documented, customer-configurable features of the exported TSG product rather than undisclosed internal-only capabilities.

A TSG MIB Specification (SNMP, registered enterprise OID 1.3.6.1.4.1.54450) documents the TSG chassis as four CPU sleds ('MCN') plus one switch sled ('MXN') monitored via IPMI for temperature/voltage/fan health, and a companion install manual names the specific model 'TSG-7400' using an ONIE-based boot/installation flow -- concrete hardware architecture detail for the exported gateway product.

A "TSG系统安装手册" (TSG System Installation Manual, dated 2021-05-28) documents clustered install architecture with three named components (OLAP, CM, ADC) deployed via Ansible + Docker on CentOS 7.4 nodes (24+ cores, 32GB+ RAM, 2TB disk each); a separate "Installation" manual documents bare-metal TSG-OS install/upgrade via ONIE (Open Network Install Environment), confirming TSG-OS ships on white-box networking hardware rather than a proprietary appliance image.

Four separate TSG "Server IP and Location of Overseas APP" reports (Instagram/Facebook CDN traffic) list Kazakhstan locations (Almaty, Pavlodar) as significant contributors to top-50-by-bytes tables alongside US/France/Hong Kong entries, consistent with a TSG vantage point that has substantial visibility into Kazakhstan-bound consumer traffic — corroborating the corpus's existing K18 (Kazakhstan) site attribution with independent network-traffic evidence.

Two independently-leaked TSG session-log CSV exports share an identical 224-field schema whose proxy_* columns (proxy_action, proxy_pinning_status, proxy_intercept_status, proxy_cert_verify, proxy_intercept_error) log the outcome of TLS interception per session, alongside ssl_ja3_hash/ssl_ja3s_hash, ssl_esni_flag, ssl_ech_flag, and quic_sni fields — confirming MITM/cert-pinning-bypass instrumentation and TLS/QUIC fingerprinting are built into TSG's standard traffic-logging pipeline, not a bolt-on feature.

An internal MESA Lab log-format specification ("上网日志格式文档", covering GKRZ/JCRZ/YBRZ session-log record types) shows every logged session record carries subscriber identity fields (phone number, IMSI, IMEI, serving-cell ULI, APN, province/region code) alongside monitoring-policy fields (rule ID, department ID, monitor category/property, center ID). A separate content-extension field table adds per-session capture of search/post keywords, platform user IDs (QQ number, WeChat uin, Weibo user ID, Baidu Tieba user ID), plaintext passwords, and VPN/tunnel protocol details (OpenVPN version/encryption/HMAC, PPTP/L2TP encryption mode, IPSec key exchange).

The same TSG session-log schema carries subscriber_id, imei, imsi, apn, and phone_number as first-class columns on every logged network session (alongside client/server IP, app-ID, and full HTTP/mail/DNS/TLS detail), meaning subscriber-identity correlation is a built-in field of TSG's default traffic log, not a separate add-on module.

TSG ships a Lua-scripting DPI extension module (pxz/tsg_lua_module, shared library "elua") whose example/test suite includes scripts that extract WeChat account IDs and QQ numbers from captured traffic (handle_weixinnum.cpp, handle_qqnum.lua) alongside a generic protocol_recognition.lua script, indicating the DPI pipeline supports custom, scriptable extraction of IM account identifiers from live traffic, not just protocol/app classification.

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.

The "TSG OAM CLI User Guide" describes TSG hardware as a chassis of "four CPU sleds (MCN) and one switch sled (MXN)"; the OAM CLI runs on the switch sled and dispatches jobs to per-blade CLI agents on each MCN sled via a named internal management API called "Bifang API" for policy-related information -- a previously undocumented internal component name.

The "TSG OAM CLI User Guide" describes TSG's physical hardware architecture as four CPU sleds (MCN) plus one switch sled (MXN) per chassis, with CLI commands issued on the MXN sled and dispatched to each MCN sled via a per-sled CLI agent, running on top of CentOS — a concrete confirmation of TSG's modular blade-chassis hardware design and OAM access model.

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.

The galaxy/deployment/tsg-olap-data-initialization repo defines TSG's production big-data backend (ClickHouse/Druid/HBase/Kafka via "groot-stream" ETL) and includes a named multi-datacenter pipeline "pxy_exch_intermedia_cert_kafka_to_ndc_kafka" that streams proxy-exchange intermediate (MITM) certificates from a site datacenter to a "national datacenter" (ndc) Kafka cluster, alongside session/transaction/VOIP record and DOS-event pipelines with per-site vs. national-datacenter topology.

A TSG-Application blocklist test found that disabling Facebook/Twitter in TSG's per-app policy did not stop Psiphon3 traffic from reaching those services in practice, because Psiphon3's dual-stack fallback drove the tunneled Facebook traffic over IPv4 QUIC, which TSG's classifier failed to attribute to Facebook -- in contrast to Taobao/Bilibili/Youku/JD, which TSG blocked successfully in the same test.

The tango/tsg-service-chaining-engine (SCE) repo implements TSG's traffic-steering core: it VXLAN-encapsulates and routes both "raw" and "decrypted" copies of a session (four tracked metadata directions) through a chain of up to 32 third-party "Service Functions", with explicit per-flow actions of block, bypass, forward, and rx_drop for both mirrored and inline-steered traffic, coordinating with SAPP, mrzcpd (packet capture/re-injection), and MAAT4 (rule engine) via control-plane messages.

A leaked TSG session-log CSV schema (device XXG-TSG-BJ) includes built-in per-session fields for TLS interception status (proxy_intercept_status, proxy_cert_verify, proxy_pinning_status, proxy_passthrough_reason) alongside JA3/JA3S TLS fingerprints and explicit ssl_esni_flag/ssl_ech_flag columns, confirming TSG logs whether a session was MITM'd and whether it used ECH/ESNI.

The same TSG session-log schema includes per-session subscriber-identity fields (subscriber_id, imei, imsi, phone_number, apn) plus cleartext-credential-capture fields (mail_password, ftp_account) and full HTTP request/response body columns, confirming the platform is built to tie flagged traffic directly to a subscriber's phone number/IMSI and to capture credentials/content, not just classify protocols.

The full TSG session-log CSV schema header discloses the complete set of per-session fields the platform records, including TLS JA3/JA3S fingerprint hashes, explicit ssl_esni_flag/ssl_ech_flag columns, QUIC/DTLS SNI and JA3 fields, and direct subscriber-identity fields (subscriber_id, imei, imsi, apn, phone_number) captured on every logged session alongside ordinary network 5-tuple data.

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.

A DerScanner SAST report on 'source-code.zip' (322K lines, Dec 2020) reveals internal package/module names for TSG's control-plane codebase: a Java web console under cn.nis.ntc ('bifang-api', modules ntc-admin/ntc-api/ntc-service handling TsgIpLocationService/TsgProfileDecryptionController policy objects), a Storm+HBase log-processing pipeline under cn.ac.iie.storm (tying the codebase to CAS's Institute of Information Engineering), and a nezha_code/nz-confagent module -- the first direct source-level map of how TSG's web console, the Nezha monitoring agent, and the big-data log pipeline relate as one codebase.

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).

Live TSG mirror-mode session logs (device_group XXG-TSG-BJ) show a granular, weekly-cadence app-classification chain for Turbo VPN — signatures dated TurboVPN_Patch01 through Patch08 (Sept 2024-Oct 2024) — with "Psiphon-Server"/"Psiphon Provider" recognized as an intermediate hop the classifier walks through before landing on "Turbo VPN", plus separate live detections of Proton VPN and "Super Unlimited VPN" (SuperUnlimitedVPN) in a second export from the same device group.

tsg-ui/demo is a TSG v3.0 "Security Policy" UI prototype (logo file literally named "TIANGOU logo", confirming TSG's Tiangou naming origin) whose page inventory enumerates the product's full policy-object model: certificate management (keyrings, SSL-decryption exclusion, trusted CA authorities), policy objects including keyword (kw) and subscriber-ID (sid) categories and a "proxy manipulation policy" object, and per-profile "Hijack Files", "Insert Scripts", "Response Pages", and "Traffic Mirror Profiles / decrypted-traffic-forwarding" configuration screens.

Eleven separate TSG session-log exports (all device_group XXG-TSG-BJ) each isolate one named commercial VPN app under a dated, patch-versioned signature and record security_action=Deny for every matched session: BeePass VPN, VPNHero, JumpJumpVPN, BigMamaVPN, AlohaBrowserLite, VPNMonster, QuarkVPN, SecureVPN, and BetternetVPN. This is live enforcement evidence (not passive mirroring) for at least nine distinct commercial VPN products, each individually fingerprinted and actively blocked.

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.

The TSG-9140 hardware repo documents supporting infrastructure: a Network Packet Broker (NPB, jut_shm) for traffic mirroring/distribution, NEZHA monitoring dashboards, and an OEO6500-OLP-TBP optical-line-protection/bypass device — the last ensuring inline link continuity if the TSG-9140 DPI node fails, a resilience feature specific to inline (not mirror) deployments.

TSG's automated QA suite (dongxiaoyan/tsg_autotest) includes an end-to-end test matrix for live HTTP/SSL content manipulation (Allow/Deny/Hijack/Insert/Replace/Redirect actions, both UI-driven and via curl scripts) and SSL interception, using a self-signed "mesalab-ca"/"tango-ca" root and intermediate CA chain with forged leaf certificates for real domains www.amazon.cn and www.bing.com, plus localized block/404 response-injection pages in Chinese, English, and Russian.

Geedge's production inline-deployment container bundle (tango/tsg_container) wires mrzcpd (capture/inject), sapp (DPI via maat rules), and a third component "tfe" (traffic-forwarding engine) together via Docker Compose; tfe ships a dedicated doh.conf (DNS-over-HTTPS handling) and the firewall-mode container's sapp config includes a send_raw_pkt.conf, a KNI (kernel network interface) config, an "asymmetric_presence_layer.conf" for mirror/asymmetric-routing deployments, and a "pangu" proxy module (pangu_pxy.conf / pangu_http.json).

The tsg/tsg-deploy repo (2019-2020) shows TSG's full commercial deployment stack: a "bifang" API service deployed via Docker, a packaged TSG-web v2.01 Pro frontend, and bundled infrastructure components (Consul, Minio, Grafana, InfluxDB, MariaDB, Redis, JDK 1.8) for on-prem/offline installs — giving a concrete picture of the commercial appliance's supporting architecture beyond the DPI engine itself.

TSG's self-diagnostic suite (tsg/tsg-diagnose) imports the full badssl.com test-certificate corpus (superfish, eDellRoot, mitm-software, captive-portal, revoked, weak-key variants, etc.) to continuously validate its own TLS-interception logic in production, adds test cases for TLS ClientHello fragmentation handling by the intercept engine, and documents that firewall DENY blocking was changed from sending only a FIN to sending FIN-then-RST to close connections.

TSG's own policy API documentation (tsg/tsg-doc) defines dedicated database/API objects for live content manipulation: a content-hijack policy-file table (内容劫持策略文件) with a contentName field, and an injected-script policy-file table (注入脚本) with an insertOn (injection point) field, alongside a block-page (访问阻断页面) policy-file type — confirming content injection and block-page replacement are first-class, documented TSG policy actions.

The same TSG API/DB documentation shows subscriber-identity fields (TSG_DYN_SUBSCRIBER_IP table, RADIUS attribute support added 2019-11-08) are built into TSG's core security-policy schema itself, not only into the separate CyberNarrator add-on — session-to-subscriber correlation is a base-platform capability at any TSG deployment, carrier-RADIUS-integrated or not.

The tsg_master core DPI/blocking daemon's GitLab repository carries a dedicated long-lived branch "dev-K18" alongside version-numbered TSG-OS release branches, confirming Kazakhstan (K18) receives its own customer-specific development branch of the product's core traffic engine, not just configuration-level customization.

TSG's core traffic-processing daemon (tango/tsg_master) added explicit support for treating Encrypted ClientHello (ECH) as a security-policy match condition (TSG-15163/TSG-15711) and tags app_full_path output with ESNI and ECH markers (TSG-15779), meaning field TSG deployments can write and enforce policy rules that specifically key on ECH/ESNI usage rather than only on plaintext SNI.

tsg_master computes and logs JA3 TLS ClientHello fingerprints (feature present since at least 2020, field renamed common_ja3_fingerprint -> common_ja3_hash; toggle GENERATE_JA3_FINGERPRINT added 2023) and, since 2023, also outputs OS-fingerprint log fields (common_client_os_name, common_server_os_name), plus improved SSL/TLS detection when the ClientHello is split across multiple TCP segments.

tsg_master resolves IP:port sessions to a carrier Subscriber ID and mobile identifiers (IMSI/IMEI/APN/MSISDN) via dynamic MAAT lookup tables synced at runtime (TSG-17219, TSG-16294), a capability present since at least 2021 (TSG-8084, DYNAMIC_MAAT_SWITCH). This subscriber-identity resolution runs inside the core DPI/blocking daemon itself, not only in the separate CyberNarrator subsystem already documented in this corpus.

A TSG OAM (Operations & Maintenance) install guide v0.4 (2020) documents sub-components OAM_CORE, OAM_CLI, OAM_CLI_Agent, OAM_SNMP, and OAM_Cluster deployed across MXN/MCN/OAM-Cluster-Server tiers, backed by MariaDB and InfluxDB, and includes a hardcoded default datasource password (`tsg2019`) in cleartext in the operational documentation itself.

TSG's field operations-and-maintenance toolkit (lijia/tsg_oam) runs certstore, kni, tfe, and tsgenv each as independent systemd services on TSG appliances, and includes a dedicated tsg_monit_intercept.py monitoring script alongside per-protocol monitors (tsg_monit_protocol_v3.py/v4.py) and a marsio-based traffic reader (get_traffic_by_marsio.py) -- showing the certstore/interception subsystem is treated as its own independently-monitored production service rather than an incidental sapp sub-feature.

A Storm-based OLAP pipeline (galaxy/tsg_olap/storm/log-address-hbase) includes a dedicated "SubscriberIdBolt"/"SubcribeIdBolt" topology stage that writes RADIUS session data into HBase, alongside a subscriber-config.properties file. This is distinct infrastructure evidence (2018-2021) that TSG's big-data/OLAP layer, not just the CyberNarrator subsystem, ingests and persists RADIUS-derived subscriber identity data at scale.

The 'galaxy/tsg_olap/tsg-complement' repository implements two custom Flume interceptors -- FlumeRadiusOnOffInterceptor and FlumeSubscriberInterceptor -- that write RADIUS session on/off events and subscriber data into HBase, confirming a dedicated pipeline for correlating network sessions to RADIUS-derived subscriber identity within the TSG/Galaxy analytics stack.

TSG-OS has a configurable 'overload bypass' mode (tsg-os-cli: set template name tsg_traffic_engine_default overload_protection enable yes) that, per Geedge support guidance to a customer experiencing packet drops, is a standard remediation for performance issues under peak load — implying traffic can be configured to bypass full processing when the appliance is overloaded.

TSG's Ansible deployment platform ('tsg/tsg-scripts-platform') installs per-protocol firewall RPM modules -- dedicated dns, ftp, http, mail, quic, and ssl packages -- alongside the sapp DPI engine and mrzcpd packet-mirror/inject agent, confirming TSG ships a purpose-built QUIC/HTTP3 blocking module as a first-class protocol-firewall component.

TSG's policy-API test suite (zhaokun/tsg_policy_api, 508 commits) enumerates the full deny-action taxonomy exercised against combinations of IP/SNI/APP/flag match conditions and negation: deny_alert (HTTP 200 with profile or text body), deny_block (403/404 with profile or text), deny_drop, deny_noreset, deny_redirect (DNS with 1-3 forged answers), and deny_rate_limit (high/low), plus "allow" and "shunt" (traffic-diversion) actions — a precise map of TSG's blocking/throttling/redirect action space.

The tsg-scripts Ansible deployment repo (git.mesalab.cn:tsg/tsg-scripts) contains dedicated per-city deploy configs for well over a dozen Kazakhstan locations (Astana/Nur-Sultan, Almaty, Karaganda, Zhezkazgan, Aktau, Shymkent, Petropavl, Pavlodar, Semey, Taraz, Kostanay, Taldykorgan, Uralsk, Kokshetau, Ust-Kamenogorsk, Aktobe/Aktubinsk, Kyzylorda), consistent with and substantially extending the K18 Kazakhstan site codename. A single 2020-10-24 commit was authored directly from a '[email protected]' account 'at K18-2 Control Center', concretely tying CEIEC (China National Electronics Import & Export Corp) to on-site K18/Kazakhstan deployment access.

The same TSG QA suite includes purpose-built "hijack" test fixtures for at least seven content types (APK, EXE, GIF, HTML, JPEG, PNG, SVG) alongside JS/CSS insertion scripts and Lua replace/insert manipulation scripts, and its UI/API test cases reference a "Manipulation" policy object with replace/hijack/deny(drop) actions triggered by "Keywords" objects inside "http_signature" matching and an explicit "no_sni" traffic-matching condition; separate pcap test fixtures (esni.pcap, ssl_ech_false.pcap, ssl_no_sni.pcap, ssl_tls13.pcap) show this is specifically regression-tested against ESNI/ECH and SNI-less TLS 1.3 traffic.

Geedge's TSG QA automation suite (chongming/tsg_test) ships dedicated certstore test fixtures -- a full "trust" and "untrust" CA chain (tango_ca_v3_trust_ca / tango_ca_v3_untrust_ca certs and keys) plus multi-level intermediate/root test certificate chains -- used to validate TLS-interception (certstore) behavior end-to-end as part of routine regression testing.

TSG-X's NEZHA monitoring-dashboard repo (tango/tsgx_hardware) shows certstore-specific dashboard charts being added ("Add certstore charts") and, three weeks later, the dashboard-template set updated explicitly sourced from the M22 (Myanmar) deployment ("sync chart from m22"), confirming certstore (TLS-interception) has its own operational monitoring and that NEZHA dashboard templates are shared from the Myanmar site into the general TSG-X product line.

MESA Lab's 'uaanalyser' library performs regex-based User-Agent parsing to classify client terminal type and OS family (separate Android/Apple/Windows analyser classes plus a StandardUaList/TerminalClassify feature set), persisting results to MariaDB -- a client-fingerprinting building block for app/device identification.

A user manual for a third-party ATCA traffic-splitter/bypass appliance ("VELA System" / S3300, made by Beijing Ebright Information Technology Co., Ltd., an ATCA chassis form factor matching the "TSG Ether Fabric" hardware documented elsewhere in this corpus) gives example hardware-level ACL rules that bidirectionally drop any TCP flow on port 80/8080 whose payload contains the literal HTTP header bytes "Content-Type: application/octet-stream", "content-Type: audio", or "content-Type: video" — a raw, DPI-independent, byte-pattern flow-drop capability at the switch/ACL level, distinct from TSG's own sapp/MAAT signature engine.

TSG's security-policy verification engine (tango/verify-policy) supports 'ssl.no_sni', 'ssl.ech' (Encrypted ClientHello), and 'ssl.esni' (Encrypted SNI) as first-class Boolean match conditions in its policy language (TSG-18943), meaning TSG can write and evaluate blocking/monitoring policies that specifically trigger on TLS connections carrying no SNI, ECH, or ESNI.

TSG's policy-verification engine added IMEI as a scannable/matchable attribute (TSG-17514), alongside its existing CallingStationID and ASN/geolocation match conditions -- confirming device-identity (IMEI) correlation is a formal, policy-actionable input in TSG's security-policy engine rather than an ad-hoc export-specific add-on.

TSG formally distinguishes a 'Proxy-Intercept' policy action type from generic security policy (TSG-14954/14955, later merging their underlying MAAT rule-engine handles) and layers service-chaining/traffic-shaping actions with a defined priority order (Shunt > Allow(monitor) > Deny(monitor)) -- confirming TLS/traffic interception (MITM) is a named, first-class policy category in TSG rather than an implicit side effect of blocking rules.

A UCAS master's thesis repo by an Institute of Information Engineering (Chinese Academy of Sciences)-affiliated researcher (chenguanlin_thesis, referencing the PACK algorithm, content-based classification, and a YouTube test image) and a related MESA Lab repo by the same author (chenguanlin/td_evaluation) that builds 'video ID' fingerprints from traffic (vedio_id_build.c) and evaluates detection accuracy with formal mistake/lost-rate statistics together indicate applied R&D on identifying specific video content from traffic patterns -- a content-fingerprinting capability beyond simple protocol classification.

A CAS-institute thesis ("面向加密场景的视频入口发现关键技术研究") builds a system that associates known encrypted video-resource traffic back to its hosting webpage/app "entry" domain even when the video itself is served from generic CDN infrastructure, using co-occurrence/sequence mining plus active-learning ranking (XGBoost) partly trained on plaintext-flow ground truth; the author's prior project record lists a "某音视频节目库项目" funded under the national "242" information-security special program (2019–2020), and the thesis is explicitly framed as enabling detection of "有害视频" (harmful video) sources.

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.

hezhengjie/videoportaldetection is a Spark/ClickHouse-backed MESA Lab pipeline (cn.ac.iie package) that mines DNS/HTTP/SSL/AV traffic logs with frequent-pattern-mining and a precision/recall evaluation module to automatically discover new audio/video-service domains (source resource file named "AV domains to be detected"), i.e. an automated FQDN-discovery system for media-streaming services that likely feeds a blocklist/classification pipeline rather than relying on static signature lists alone.

The galaxy/tsg_olap/log-stream-voip-relation repo is a Flink/Kafka streaming job (VoIpRelationTopology) that correlates SIP signaling flows with their corresponding RTP media flows across VSYS (virtual-system) boundaries, reconstructing complete VoIP call sessions from separately-observed signaling and media traffic.

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.

Geedge's AppSketch/MAAT signature store contains a large, actively-maintained catalog of per-app FQDN+IP blocking signatures for dozens of named consumer VPN apps (StartVPN, DotVPN, VPNLite, BullVPN, RapidVPN, QuarkVPN, AdGuardVPN, BulletVPN, NotVPN, LetsVPN, PandaVPN, ACE VPN, BetternetVPN, HulaVPN, ThunderVPN, TurboVPN, and more, patch-dated across 2024), each tagged category='networking'/subcategory='tunnels' (or similar) with a deny_action of packet drop (sometimes with TCP RST), and some apps additionally flagged characteristics='evasive' with elevated risk scores; several apps' FQDN lists show the same domain-generation pattern (random word + .xyz/.info) later seen automated in a companion detection script.

Geedge runs an ongoing, largely manual weekly signature-extraction program against commercial VPN apps (LetsVPN, Betternet, VPNLITE, and a ~80-app batch), combining server-IP lists, FQDN patterns, and payload/SNI/Host/User-Agent signatures, tested for blocking efficacy and false-positive rate before rollout. VPNLITE was fingerprinted via TCP direct-connect on ports 18000/3320/8099 plus TLS to randomized .xyz/.info subdomains on Cloudflare ranges (104.21.0.0/16, 172.67.0.0/16).

Live TSG session logs from an internal test bed (device 21426003 / XXG-TSG-BJ) show active Deny actions firing against named commercial VPN apps -- Super Unlimited VPN, BetternetVPN, TouchVPN, LetsVPN -- via dated signature patches (e.g. BetternetVPN_Patch01_20240812 through Patch06_20240920, SuperUnlimitedVPN_Patch05 through Patch10 within six weeks), and LetsVPN's block fires on a JA3 TLS fingerprint (LetsVPN_by_ja3) even when the SNI/Host is spoofed to www.bytedance.com.

Geedge's VPN-app signature-extraction methodology (M22/Myanmar project, run weekly per-app) is primarily IP-address-list-based rather than protocol-fingerprint-based: automated scripts enumerate each VPN app's server IPs (extraction runs cited pulling 7-200+ IPs per test cycle for apps like BigMama VPN, Giti VPN, JumpJumpVPN), which are then pushed as blocking signatures and validated against a live test environment plus a separate false-positive ('误封') test environment before deployment.

Three artifacts contain complete server-side infrastructure catalogs for commercial VPN provider families rather than just observed traffic: (1) a JSON dump of 38 VPN server nodes for the WaselPro/BVPN/SmokeTunnel/iWasel brand family, each with a full CA certificate, an SSH private key (for stunnel obfuscation), an IPsec pre-shared key, and listen IP, spanning US/EU/Asia/Middle East; (2) a ~150-datacenter API dump from VPN infrastructure reseller pointtoserver.com (data center id/name/ping-IP/hostname, reseller_id 2); (3) a similarly-structured per-country VPN config/cert bundle list referencing flag_url assets from bgnmobi.com. Together these show systematic collection of VPN providers' backend server credentials and infrastructure maps, not just client-side traffic fingerprints.

Meeting notes from a MESA "VPN基础设施" (VPN infrastructure) project log explicit work sessions on "cloud services & CDN IP range" cataloging, "SS [Shadowsocks] experiments," and "Snowflake, SS organizing" across consecutive weeks in mid-2022, alongside a separately named "网络公害" ("internet nuisance/hazard") project.

The corpus contains a locally-cached mirror of NordVPN's public server catalog (149+ entries visible before truncation, spanning 20 countries, with IP, hostname, and per-protocol support flags for IKEv2/OpenVPN/WireGuard/SOCKS) plus a separate harvested record pairing a country_code with a base64-encoded, ready-to-use OpenVPN client config — evidence of systematic collection of commercial VPN server IPs/configs for blocklist construction, beyond the previously-documented Psiphon3-specific CyberNarrator pipeline.

A 2024 bachelor's thesis from UCAS, advised by a senior engineer at the Institute of Information Engineering (IIE), Chinese Academy of Sciences, built and evaluated a dynamic, iterative VPN-server identification prototype combining active-probing response features with passive traffic features and an IP-similarity graph-relationship model; the combined system reached 92.44% online-test identification accuracy (versus 87.19% accuracy / 86.38% F1 for the offline active-probing-only variant).

A CAS-institute master's thesis ("基于IP相似性分析的VPN服务识别技术研究") builds a VPN-server-identification system combining active TCP/UDP port probing (SYN scan on ports 1194 OpenVPN, 500/4500 IPSec, 1701 L2TP, 22, 443, 51820 WireGuard, 992, 4090, 655; UDP scan on 80/53/25/465/110/143/389/21/3389/445/69/3306/6379) with passive-traffic "IP similarity" graph analysis, reaching 92.44% online-test accuracy and supporting dynamic feature-library updates as services change.

The online-config repo defines Flink topologies literally named "vpn-recommend" and "app-recommend" (both keyed on a config named RECOMMENDATION-APP-CIP, i.e. client-IP-based app/VPN recommendation) alongside a family of "ip-learning-spark" Spark jobs (including an "ip-learning-spark-subid-only" variant tying IP-learning to a subscriber ID) — evidence of an automated, cross-site VPN/app client-IP classification-and-learning pipeline distinct from, but conceptually similar to, the Pakistan-specific CyberNarrator vpn-thwarting IP-harvesting capability documented elsewhere.

A Flink project internally named "flink-vpn-recommend" (galaxy/tsg_olap/app_recommend, package com.galaxy.recommend.Recommendation, class TopNHotItems) computes top-N "hot item" rankings from TSG OLAP traffic data; the project naming and Recommendation/TopN class structure suggest a VPN or app usage-ranking pipeline, plausibly used to prioritize which VPN services warrant new detection-signature development, though no explicit VPN-selection logic is visible in this metadata-only artifact.

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.

Three harvested datasets catalog full server-fleet inventories for multiple commercial VPN/proxy brands -- WaselPro/BVPN/SmokeTunnel/iWasel/BackboneVPN (with per-node CA certificate, IPsec PSK, and SSH private key captured), VyprVPN/GoldenFrog (per-location hostname/IP/coordinates), and tap2free (per-node IP with PRO/FREE tier flags) -- i.e. Geedge enumerates and archives entire commercial VPN provider bootstrap/config responses, not just individually observed connections.

Beyond the Lantern-specific rules, this batch contains ~40 individually-dated JSON signature files from the same MAAT/AppSketch rule format, each targeting one named VPN/circumvention client by FQDN, destination IP, TLS JA3 hash, or certificate issuer: Signal, Orbot, Cloudflare WARP (including a MASQUE-specific variant combining an app_id classifier with an FQDN condition), ExpressVPN (matched by a literal JA3 hash plus a separate FQDN rule), ProtonVPN/ProtonMail, TurboVPN, QuarkVPN, LetsVPN, BetternetVPN, Browsec, GeckoVPN, HulaVPN, JumpJumpVPN, MouseVPN, NotVPN, SecureVPN, StarkVPNReloaded, SuperUnlimitedVPN, TowerVPN, TrustzoneVPN, USAVPN, VPNIndia/VPNLite/VPNPro/VPNTurkey, FlyVPN, ACE VPN, F1 Rockets VPN, and the Chinese gaming accelerator biubiu加速器. Dates cluster tightly (e.g. many on 2024-08-09, others 2024-09/10/11), indicating an active, continuously-updated per-app signature production pipeline rather than a static list.

A large set of individually-dated per-product signature files shows at least 31 distinct named commercial VPN apps under active, ongoing detection engineering (SecureVPN, LetsVPN, BetternetVPN, SuperUnlimitedVPN, TunnelBear, AtlasVPN, TurboVPN, UrbanVPN, GeckoVPN, VPNUnlimited, BitdefenderVPN, QuarkVPN, FlyVPN, HulaVPN, SurfVPN, BulletVPN, BeePassVPN, SnapVPN, WhitehatVPN, LunaVPN, SuperNetVPN, GitiVPN, CleanerAntivirusVPN, V2VPN/V2Netvpn, 7VPN, and country-branded VPNIndia/VPNCanada/VPNIndonesia/VPNKorea apps), each with multiple detection vectors per app (destination-IP ranges, FQDN, DNS QNAME, TLS cert issuer, JA3, WireGuard-protocol matching, ISAKMP/IKE matching, raw TCP payload); one file shows the resulting policy rule object wired directly to an explicit deny action.

Across dozens of individual signature-rule JSON files in this batch, at least 40 distinct named commercial VPN products carry dedicated detection signatures (by IP src/dst, FQDN, JA3 hash, or protocol-specific payload): BeePassVPN, BetternetVPN (separate isakmp/ja3/WireGuard sub- signatures), BigMamaVPN, BravePrivateVPN, ExpressVPN (JA3 + UDP-payload variants), FlyVPN, hidemevpn (OpenVPN UDP payload), JourneyVPN, JumpjumpVPN, LetsVPN (JA3), Psiphon3 ("psiphon3vpn_serverip"), QuarkVPN, SecureVPN, SuperUnlimitedVPN, TurboVPN, VPNHero, VPNTurkey, and others, each dated/versioned (e.g. "_20240812") indicating an ongoing signature-maintenance pipeline rather than a one-off ruleset.

Dozens of near-identical MAAT/AppSketch-style signature-definition files in this batch each target one named commercial VPN app/service (ProtonVPN, HotSpot VPN, SuperUnlimitedVPN, jumpjumpVPN, BetternetVPN, NotVPN, VPNLite, SymlexVPN, etc.), matched via FQDN suffix, destination IP list, and/or TLS JA3 hash. The same "SuperUnlimitedVPN" signature recurs with new signature_ids/dates roughly monthly (2024-06, -09, -10, -11), showing this is a continuously-maintained, actively-updated VPN-detection pipeline rather than a one-off snapshot.

Leaked per-app JSON signature-rule exports show the detection engine layers multiple independent signals per VPN product: Windscribe VPN is matched via fixed-offset hex-byte keywords inside the OpenVPN UDP handshake payload (offset 73/depth 78 and offset 81/depth 85); "Super Unlimited VPN" (the SuperUnlimitedVPN app) gets three parallel signatures — a JA3 TLS-fingerprint match, an FQDN match, and an OpenVPN c2s-payload-prefix/length match; Hide.me VPN is matched on OpenVPN UDP payload; FastVPN is matched purely by known source/destination IP; and "V2VPN" (Google Play com.v2ray.v2vpn, a V2Ray-based VPN app) has its own dedicated signature — evidencing a deliberately layered (protocol-fingerprint + TLS-fingerprint + FQDN + IP) detection strategy per circumvention product.

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.

The same M22-tagged VPN-finder plugin set implements active UDP probing to elicit and harvest server IP addresses from CyberGhost VPN's protocol behavior, and separately fingerprints Windscribe VPN via TLS certificate features — two distinct active-probing/fingerprinting techniques feeding the same central VPN-blocklist knowledge base, with an explicit configurable active-scan packet rate.

The "intelligence-learning-engine/vpn-finder-plugins" repo was initialized specifically for the M22 (Myanmar) deployment ("Init: M22初始化", branches "24.08_M22"/"tsg24.02_M22") and implements per-service detection plugins for at least nine commercial VPN products (CyberGhost, ProtonVPN, TurboVPN, Windscribe, IPVanish, Ivacy, VPN Unlimited, GeckoVPN, Hotspot Shield) plus Psiphon3, feeding discovered server identifiers into a central "knowledge base" that field deployments sync from on their own release cadence.

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.

A production Python pipeline queries the TSG session-log ClickHouse database roughly every 5 minutes for sessions matching either a fixed set of VPN-associated TCP ports (18000, 3320, 8099) or a domain-generation heuristic (FQDN = 10-14 lowercase letters + '.xyz' or '.info' TLD, hosted on Cloudflare IP ranges 104.21.0.0/16 or 172.67.0.0/16), and automatically inserts newly-observed matching IPs/FQDNs into the live 'VPNLite_ip'/'VPNLite_fqdn' blocking objects via a config-management API, with no human review step.

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.

The tsg/wannat-ansible-deploy repo bundles a "wannat_natgw" NAT gateway role together with OpenVPN-server and PPTPD-server Ansible roles, both integrated with FreeRADIUS (radius_server/radius_client roles, radiusplugin.so for OpenVPN), as part of the standard TSG deployment stack (synced to "TSG v21.09" releases, tracked under TSG-8xxx tickets). Whether this VPN-terminating gateway exists for TSG field-engineer remote access or for a VPN-interception use case is not established from this metadata alone.

Two paired MAAT signatures, "warp_masque_m" and "warp_ip", detect Cloudflare WARP/MASQUE traffic: one matches destination IP 162.159.198.1 (a published Cloudflare WARP anycast address) combined with an internal app_id classification (140/15629), the other matches the same infrastructure via IP protocol number alone -- i.e. WARP is detected both by a fixed anycast IP and by an app-ID classifier layered on top of it.

A certificate-store JSON list maps 40+ regional server hostnames of commercial VPN brands WaselPro, BVPN/BackboneVPN, iWasel, and SmokeTunnel (e.g. ca.us.waselpro.com, hk.as.bvpn.com, de.eu.smoketunnel.com) to their captured X.509 TLS certificates (base64-encoded), matching the taxonomy's certstore capability description of per-connection Trusted/Untrusted profiles and certificate-pinning-detection classification.

"WebHopper" (zhuyujia/webhopper) is a website crawling/analysis pipeline combining a customized headless-Chromium build ("adg-linux"), a CA-certificate lookup module (caLookup.py), a DNS lookup module (dnsLookup.py), and EasyList-based ad-filtering (ATFilter.py) — infrastructure consistent with building or maintaining large-scale website classification/blocklist datasets that could feed FQDN rule sets like those used by Maat/AppSketch, though the artifact's metadata alone does not show the crawl output's downstream destination.

TSG's galaxy-job scheduler runs a 'Web Sketch' domain-probing task (given a sharded mode explicitly to support large-scale parallel probing across servers) and a 'CN' knowledge-base sync pipeline (JIRA ticket prefix CN-, matching this corpus's CyberNarrator codename) that supports encrypting sensitive knowledge-base files and periodically updates a dark-web-indicator table (ioc_darkweb) -- evidence that CyberNarrator's blocklist/knowledge-base pipeline includes an active domain-probing component and a dark-web IOC feed, beyond the previously-documented Psiphon3 IP-harvesting and Pakistan subscriber-correlation components.

A URL/domain-classification service (yinjiangyi/webskt-query-agent) integrates the third-party BrightCloud (Webroot) URL-categorization API (BrightCloudUtils.java, brightcloud.properties, map_clf2brightcloud.csv) alongside its own reputation/whois lookups, suggesting TSG's category-based content policies (e.g. block-by-category) are informed by a licensed external URL-reputation database rather than purely in-house classification.

"WebSketch" (web-sketch/webskt-query-agent, internal package com.mesasoft.cn) is a domain-intelligence query service enriching domain records via third-party APIs BrightCloud and ChinaZ (category/ICP lookups) and maintaining a DoH-resolver support list, backing centralized content-category data used elsewhere for classification/blocklists.

A MESA Lab research note dissects the Tor Project's webtunnel pluggable transport (HTTPT-based) and reports a hands-on pcap analysis of 3 public webtunnel bridges: the observed TLS ClientHello/cipher-suite fingerprint and SNI matched an ordinary HTTPS connection to the bridge's cover domain, with no certificate visible in the captured handshake -- i.e. these deployments withstood the lab's basic passive TLS-layer fingerprinting attempt at the time of writing.

wangmeiqi/wfp_dataprocess is a small MESA Lab repo ("WFP实验设计" = "WFP [Website Fingerprinting] experiment design") containing a connection-dataset builder script, indicating active internal research into Website Fingerprinting attacks — identifying which site a user visits from encrypted/proxied traffic patterns alone.

A single AppSketch/MAAT signature bundle for Windscribe VPN fuses four independent detection techniques in production: an OpenVPN-handshake payload signature (fixed hex bytes at a specific byte offset/depth plus an exact packet-length check), a TLS certificate subject_organization_name match on the literal string 'Windscribe', a JA3 TLS-ClientHello fingerprint hash, and DNS query-name matching against 100+ individually enumerated obfuscation/CDN-rotation domains (windscribe.com plus many totallyacdn.com and whiskergalaxy.com hostnames).

An explicitly test-labeled MAAT signature ("test_wireguard_ww_2", signatureDesc "wireguard_tcp_payload") fingerprints WireGuard's handshake-initiation message by its fixed leading bytes (hex 01000000 = message type 1 + zeroed reserved field), matched both against raw UDP payloads (client-to-server and server-to-client first packets, left-anchored) and against a TCP-encapsulated variant (same pattern at a fixed sub-offset/depth within the TCP payload). This shows active development of WireGuard detection covering both native UDP and TCP-tunneled deployments.

wujiating/detection (by the same MESA Lab researcher behind wujiating/censorship_detection, a translated censorship-detection literature survey) is a CICFlowMeter-based ML traffic classifier trained on the public ISCX VPN-nonVPN dataset plus custom-captured DoH and generic web pcaps, organized into explicit closed-world (CW) and open-world (OW) evaluation splits — evidence of dedicated open-world DoH-traffic classification research at MESA Lab.

An internal methodology memo for the '新疆省口项目' (Xinjiang provincial-gateway project) and '联通IDC项目' (Unicom IDC project) states both rely on 现有的系统（TSG与CN） (the existing TSG and CN [CyberNarrator] systems) to Block/Monitor/identify mainstream apps, and describes a largely manual signature-engineering workflow -- download the target app, capture traffic with 科莱(Colasoft Capsa)/Wireshark, extract fingerprint fields (http.host, http.user_agent, quic.sni, ssl.handshake.extensions_server_name) by hand, and register a per-app signature -- extending CyberNarrator's documented role beyond Psiphon-IP-harvesting/Pakistan subscriber correlation into general domestic app-blocking alongside TSG.

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.

The daxiaoxu/xmr_bsexpr1 repo is a 3,500+ file dataset of raw PCAP captures and per-device "SUB_FEATUREs" text extracts spanning a wide range of real consumer devices (Honor Magic2, iPad Air2/mini2, LG G7 ThinQ, MacBook Air 2021, MacOS 15, RedMi Note9, Windows 7/10/11), consistent with a device/OS traffic-fingerprinting feature-extraction pipeline feeding TSG's app/device identification signatures.

A dial-testing ('拨测') log documents systematic active-probing/reachability testing from a 'YGN-GTG' (Yangon Gateway, Myanmar) network node against six overseas test sites in Singapore, France, the US, New Zealand, South Africa, and Chile, using packet capture plus flow statistics to quantify one-way vs two-way flow completion (0-45%% flow loss observed per site) through gateway node IPs 'YGN-GTG: 10.173.12.x' -- direct empirical evidence of connectivity/blocking-effectiveness QA testing tied to the Myanmar (M22) Yangon deployment, run against an 'NCSC'-provided 'Campana' test WiFi network.

MESA Lab researchers built and iterated a Scapy-based website-fingerprinting classifier that identifies specific YouTube videos from encrypted traffic by matching the packet-size sequence of thumbnail-image requests (triggered on SNI yt3.googleusercontent.com / yt3.ggpht.com) against a pre-built reference dataset (dataset_24_youtube_fingerprints.csv), scoring candidate matches on sequence overlap and total-payload-size ratio against fixed thresholds (0.65 / 0.85).

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.

Thesis-defense revision notes for a MESA-adjacent CAS-institute master's thesis describe a YouTube video-title identification system that decrypts HTTPS video traffic between a crawler and video servers via mitmproxy, then fingerprints each video from per-chunk HTTP response timing/size derived from a corpus of 38,000 YouTube video chunks (identification method: response-time-distribution based).

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.

A MESA researcher's status report lists work on encrypted-DNS-resolver role classification (ADNS/FDNS/RDNS) and DoH resolver component-chaining clustering, alongside a project named "YYDNS" (probing-system backend workflow and data integration) and a completed "ZX VPN active-probing requirement discussion" -- indicating a dedicated active-probing module was scoped against a specific named VPN product.

MESA Lab operates a distributed active-probing system internally called "YYDNS" (backend repos handingkang/yserver and handingkang/yyserver, frontend repo zhuyujia/yydns_vue, all sharing a "YYDNS 库表关系设计.pdf" design doc). Agents perform TCP ping/latency measurement against "targets" ("参与探测的节点信息", "状态感知"/state-sensing), and the Vue frontend's icon set uses literal Tor role terminology (guard.svg, relay.svg, onion.svg, torInfo.svg, client.svg), indicating the system is built to track and classify Tor guard/relay nodes specifically. One deployment instance (yyserver, 2023) stores probe-target geolocation data heavily concentrated in coordinates matching Taiwan (lat ~22.6-25.1N, lon ~119.5-121.7E).

A 2024 student-thesis project inside MESA Lab (chengyifei/yy_strategy_adjust, presentation titled "毕设交流_大模型策略控制" / "Thesis exchange: large-model strategy control") wires Moonshot AI's Kimi LLM into a "strategy adjustment" module via kimi_main.py/kimi_strategy.py/kimi_strategy_client.py and a content_role_system.txt role/prompt file, indicating exploratory R&D on using an LLM to drive dynamic policy/strategy decisions. Framed as a graduation-project exercise, not confirmed production use.