Deep Packet Inspection

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

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.

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.

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.

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.

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

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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

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

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.

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.

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.

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

At the 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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.