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.
vim /home/mesasoft/sapp_run/TF_conf/TF_tableinfo.conf ... "do_blacklist": 1, "do_log": 1, ... "table_name": "IP_REGION_INFO", "table_type": "ip_plus", "table_content": {"addr_type": "ipv4", "src_ip1": "10.133.254.225", ...}
Related findings
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.
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.
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.
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.