tsg_master resolves IP:port sessions to a carrier Subscriber ID and mobile identifiers (IMSI/IMEI/APN/MSISDN) via dynamic MAAT lookup tables synced at runtime (TSG-17219, TSG-16294), a capability present since at least 2021 (TSG-8084, DYNAMIC_MAAT_SWITCH). This subscriber-identity resolution runs inside the core DPI/blocking daemon itself, not only in the separate CyberNarrator subsystem already documented in this corpus.

A live tsg_master engine config file exposes a [RESET] section with concrete TCP-RST-injection parameters (NUM=1, SEED1=65535, SEED2=13, FLAGS=20, DIR=3, REMEDY=0), a [TRAFFIC_MIRROR] section confirming mirror-tap deployment (NIC_NAME="eth_vf_mirr"), a [MAAT] section wiring tsg_master directly to MAAT's subscriber-ID tables (TSG_OBJ_SUBSCRIBER_ID/TSG_DYN_SUBSCRIBER_IP), and a device tag "BeiJing-XXG" confirming this specific instance is a domestic Beijing deployment. A plaintext Kafka SASL credential (SASL_PASSWD="galaxy2019") is also exposed, and "galaxy" recurs as an internal project codename elsewhere in this batch (docker service path /home/galaxy, APP_BRIDGE_NAME).

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.

Sample MAAT rule-table exports (maat_cfg1, dated 2018-06-16/07-10: APP_DOMAIN, APP_POLICY, LIMIT_DOMAIN) show the on-disk schema for MAAT app/domain policy tables — numeric region/group/domain IDs, an app-name field, numeric match flags, and a KEY=VALUE;KEY=VALUE region string carrying APP_ID/DOMAIN_ID — with every sample row using the identical app-name string 'circuitiOS'. The tiny, sequential-ID row count (1-2 entries per table) suggests this is likely test/demo fixture data rather than a live production ruleset, but the repeated app-name string is worth flagging for correlation against known iOS circumvention clients.

pangu_valve.conf explicitly binds the 'PanguValve' traffic-control daemon (阀门, ASMIS_PROC_NAME=Pangu/PanguValve) to the Astana, Kazakhstan (K18) site — REMOTE_DIR=ASTANA and a MAAT_EFFECTIVE_RANGE tag of location=Astana — and configures it to receive live rule updates from a MAAT Redis backend rather than static files, tying this enforcement component directly to a real-time MAAT rule-dispatch pipeline at a named export deployment.

pg_valve_deal.cpp / pg_valve_main.cpp source shows the 'valve' (pangu_valve) component implements a MAAT-fed, hierarchical (region/group -> dataset -> domain-ID) rule-dispatch engine: each incoming rule line carries a keyword field plus expr_type/match_method/is_hexbin matching flags, an ADD/DEL action, and a percentage-based 'Droprate' throttle parsed out of a semicolon-delimited region string (DOMAIN_ID=...;config_id=...;Droprate=...) — i.e. a keyword/domain-based engine that can partially throttle traffic, not just binary-block it.