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.
进入sapp机器,/home/mesasoft/sapp_run_yb/durain_master_maat/ 查看IP_PORT.json文件... 程序启动后会自动加载配置文件从而实现特定目标数据加载... 配置文件中配置对应的IP的配置,可以标识为对应的特定目标的获取与标注
Defense implications
- IP-based individual/entity watchlisting is confirmed as a first-class, config-driven feature (not ad-hoc code): a target's IP can be flagged, tagged, and its full contact-relationship graph logged in real time. Lantern's egress/entry IP rotation strategy should assume a flagged IP is durably tracked, not just transiently blocked.
Related findings
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.
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 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.
An internal Q&A on the MAAT rule engine's C API confirms sapp is MAAT's calling business system (maintained by a separate team from MAAT/rulescan), that MAAT's incremental-rule loading works by watching a config directory for the highest-indexed new file (with a separate "config line" pipeline compiling user-facing JSON rules into MAAT's matchable binary format), and specifies deployment hardware requirements for a single MAAT node: CentOS 7, 256GB+ RAM, 2TB+ disk, 48-logical-core Intel Xeon E5.
Internal MAAT engineering specification (v3.1.20, MESA Lab, revision history spanning 2014-2021) documents the config schema underlying sapp's rule-matching engine: per-rule action types (0=block/阻断, 1=monitor/监测, 2=whitelist/白名单), string/regex/IP/numeric/digest match types, and a geographic+ISP "tag" targeting system that lets the identical rule set be selectively activated per city district and carrier (e.g. Beijing/Chaoyang + China Telecom vs. Shanghai/Pudong), enabling narrowly-scoped rule rollout/testing before wider deployment.