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.
省口通过maat_redis_tool拉取现网配置 APP_SIG_SESSION_ATTRIBUTE_STRING表中共配置了1667条负载特征...钉钉配置了0001000200076465，微信配置负载特征如下
Defense implications
- Payload-prefix (first-packet) matching is confirmed as a live, actively-maintained detection method at scale (1000+ signatures per site) -- protocols with a distinctive, static byte pattern in the first few packets are at direct risk regardless of TLS/SNI-level obfuscation.
- The centrally-authored, periodically-synced signature database model means a signature developed against one deployment likely propagates to others on a similar cadence -- assume cross-deployment signature reuse.
Related findings
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.
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.
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.
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.
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.