An internal operations manual documents the end-to-end workflow for turning an official government blocking/monitoring request ("来函") into a technical rule on the sapp-based filtering system: analysts capture live traffic with Wireshark/Chrome to derive the exact keyword (DNS qname, TLS SNI, HTTP Host+path, or email From/To/Subject/Content/ attachment), choose one of four match modes (exact/prefix/suffix/ substring), and push it as either a "JC" (监测, monitoring) or "GK" (阻断/禁止, blocking) rule; DNS rules operate via DNS spoofing, HTTP/SSL rules via keyword/SNI matching, and email rules match headers or body/attachment content.
判断是GK还是JC配置。如果为监测需求，下发监测类配置。如果为阻断、禁止需求，下发GK类配置。DNS规则：如果用户需要对网站进行GK，可以下发DNS欺骗规则。邮件头匹配位置包括：From/To/Subject。邮件体匹配位置包括：Content/AttachName/AttachContent。
Defense implications
- Production keyword matching supports 4 modes (exact/prefix/suffix/substring) across DNS qname, TLS SNI, HTTP Host+path, and email header/body/attachment — any circumvention protocol using a stable, guessable domain, path prefix, or repeated string in cleartext or SNI is directly exposed to this exact rule type; randomize/rotate identifiers that could become a substring-match target.
Related findings
The internal 'MAAT网络流处理配置统一描述框架' engineering manual (v3.1.20, author name redacted, 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.
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.
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.
Internal MAAT documentation lays out the rule-engine's config hierarchy (Region -> Group -> Compile, i.e. domain-config policy units combined by OR, grouped policy objects combined by AND/OR/NOT, up to 8 clauses per compiled policy) synced through a tree-structured Redis (one master, many replicas) with a live add/delete path, and names three engineers (names redacted) working on sapp with a planned future Rust rewrite. It also notes MAAT is deployed per-frontend-machine (not distributed) and that config changes take ~10 minutes to fully propagate.
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.
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.