SAPP platform

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

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

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

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.

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

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

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

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.

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

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.

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.

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.

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

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

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.

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.

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.

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

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.

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.

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.

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

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

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.

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

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

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

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

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

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.

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.

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.

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

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.

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.

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.

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

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

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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

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.

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

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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

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.

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

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

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.

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.

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.

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.