TSG's T1 traffic-engine plugin framework (NTC_APP_PLUG, NTC_IP_COMM) tags every classified flow with a composite app-identification label (PROTO_ID/APP_ID/OS_ID/BS_ID-browser/WEB_ID/BEHAV_ID) drawn from a shared per-stream 'dpkt' classification struct, and streams it via Kafka/local log for every session. A disabled (#if 0) code path in NTC_APP_PLUG shows this exact label being matched against the MAAT rule engine (Maat_full_scan_string) to trigger MESA_kill_tcp (RST-based termination) when a block rule fires; NTC_IP_COMM separately logs a live 'stream_killed_flag' via an 'after_kill_switch' option, confirming the TCP-kill/track-after-kill mechanism is real in production even though this particular scan-and-kill call site is currently compiled out.
scan_ret = scan_nesting_proto_addr(g_t1_maat_feather, pstream, trans_proto, &mid, result, MAX_MAAT_RESULT); scan_ret += Maat_full_scan_string(g_t1_maat_feather, g_ntc_app_plug.table_id, CHARSET_GBK, label_buf, label_buflen, ...); if(fetch_block_rule(result, scan_ret) != NULL && trans_proto == PROTO_TCP) { MESA_kill_tcp((struct streaminfo *)pstream, raw_pkt); }
Defense implications
- Classification (and any downstream block decision) keys on a composite app/OS/browser/website/behavior fingerprint computed before the kill fires — a transport that avoids leaving a recognizable app-layer signature in this label space denies MAAT's rule engine the features it scans against.
- The kill path is RST-based (MESA_kill_tcp) and fires only after several packets have let the classifier commit to a label; delaying any protocol-identifying behavior in the opening packets buys time against this specific block mechanism.
Cited artifacts
mesalab_git—PanGu/ntc_app_plug.bundle(git-commit-log)mesalab_git—PanGu/ntc_ip_comm.bundle(git-commit-log)
Provenance pointers only — no leak content is rehosted. Raw material: Enlace Hacktivista.
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 AppSketch/MAAT signature system contains a systematically dated, patch-versioned catalog of FQDN-based detection signatures for dozens of individually named commercial VPN apps (e.g. V2VPN, V2Netvpn, Turbo VPN, LetsVPN, AdGuard VPN, Avira Phantom VPN, TouchVPN, FinchVPN, Opera VPN, Ultrasurf VPN, GoFly VPN), each modeled as an 'app' object in category 'networking' / subcategory 'tunnels' whose default deny_action drops the flow while sending both an ICMP-unreachable and a TCP RST to the client. At least 35 such distinct VPN-app signature objects appear in this batch alone, dated July-November 2024, with repeated 'Patch0N' revisions to the same app as its domains rotate.
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.
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).
A 2018 MESA Lab monthly report describes work on the "GPS"/"先导" (Pioneer) active-probing projects: adding IPv6 scanning support and simultaneous 3-domain scanning to MAAT, alongside active-probing experiments (nslookup/dig/nmap) and root-DNS-server BGP-anycast measurement -- indicating MAAT's rule engine is paired with an active network-scanning subsystem, not purely passive/inline matching.
An internal 'MAAT Configuration Description Manual (String)' fully documents MAAT's rule-compilation model: per-field string matches (substring/prefix/suffix/exact/regex/AND-of-substrings/offset-anchored substrings) grouped into up to 8 AND/NOT clauses per compiled rule (conjunctive normal form), each carrying an action code (0=block, 1=monitor-only, 2=whitelist), blacklist and logging flags, and a floating-point execution-order field for safe rule reordering, plus the C scanning API (Maat_full_scan_string) and the file/JSON formats used to push rule updates to production.