MAAT / maatframe

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.

The same T1/NTC node config (ntcconf/t1conf/main.conf, K18/Astana/Kazakhtelecom) exposes concrete DPI enforcement toggles: a SYNACK_OR_RST switch and SEND_INJECT_PKT flag governing active TCP-response/packet-injection behavior; ASN- and IP-based blocklists (ASN_MAAT, IPD_DYN_MAAT, IPD_STATIC_MAAT) refreshed from MAAT/Redis on a 1-second effect interval; a dynamic blacklist with a 180s timeout; explicit protocol-blocking switches for BitTorrent (DHT/uTP) and eMule (Kad); and TLS metadata harvesting including certificate SAN fields (NTC_SSL_COLLECT, collect_san_sw=1) streamed to a Kafka topic.

The T1/NTC (text-content DPI) node's wired-config manifest (main.conf, dated 2019-01-30) sets REMOTE_DIR=ASTANA/KAZAKHTELECOM/, directly naming Kazakhtelecom — Kazakhstan's dominant state-linked telecom operator — as the carrier context for this K18 deployment. The NTC_MAAT module's EFFECTIVE_FLAG further scopes rules to {location: Astana, isp: Tanstelecom}, naming a second Kazakhstani ISP (Transtelecom) tied to the same deployment.

Exported AppSketch/MAAT signature-object JSON shows named per-VPN detection rules combining multiple independent vectors: CyberGhost's WireGuard variant is matched by a hex UDP-payload pattern (04000000*), destination port 1337, and ip.proto=17 together (signature cyberghostvpn_wireguard); Windscribe's OpenVPN control channel is matched by two offset-anchored hex byte patterns plus an exact 86-byte payload length (windscribevpn_openvpn_payload); and ExpressVPN is matched independently via a literal JA3 hash (ssl.analysis.ja3), FQDN strings (expressapisv2.com, www.expressvpn.works), and a large enumerated IP list (700+ individual ip.dst entries observed before the 200KB text-extraction cutoff).

A dedicated AppSketch/MAAT signature object named 'Psiphon-Volunteer-IP' (signature_id 4054) blocklists specific IPv4/IPv6 CIDR ranges by ip.dst regardless of port (192.122.190.0/24, 2001:48a8:687f:1::/64, 141.219.0.0/16, and more), i.e. Geedge maintains infrastructure-level blocking of known Psiphon volunteer-hosted proxy server ranges rather than relying solely on app/protocol fingerprinting.

A signature object dated 2024-10-28 and named 'VPN servers in Russia' (fqdn variant signature_id 6217, IP variant 6216) blocklists specific FQDNs (api.tap2free.net, vpnlocal.app) and a companion IP-address object, showing Geedge curates geography-scoped VPN-infrastructure collections by country rather than only per-app-brand signatures — i.e. any server identified as VPN infrastructure hosted in a given country can be swept into a blocklist independent of which client app uses it.

An exported IP-blocklist object with the literal header format 'IP[Single||/CIDR||-Range]#[Port]' and 5,511 entries, each a single IP with port range 0-65535 (i.e. full-IP block regardless of port), includes 185.220.101.77 — an address in the 185.220.101.0/24 block long associated with Tor exit-relay operators — suggesting at least part of this object targets Tor exit infrastructure by IP rather than by protocol fingerprint.

A second raw, unlabeled IP list (13,786 entries, no header/context) contains dense runs of adjacent addresses within a small number of /24-ish blocks (e.g. multiple 146.66.209.x and 102.129.227.x addresses), a pattern consistent with enumerating a hosting/VPS provider's allocated ranges rather than random targets. Format (flat one-IP-per-line) matches the kind of raw export MAAT's IP-rule policy objects are built from, but this file lacks the labeling seen in 788a452cfa86, so its specific purpose/target list is not independently confirmed from this artifact alone.

A MAAT/AppSketch signature literally named "Psiphon-Server-IP" blocks by destination IP against a list of 1,300+ IPs (the extracted text is truncated at ~200KB so the true list is likely larger, consistent with the taxonomy's cybernarrator/vpn-thwarting note of ~70-73K harvested Psiphon IPs), directly corroborating that the CyberNarrator/vpn-thwarting Psiphon3 IP-harvesting pipeline feeds its output straight into a production MAAT/AppSketch blocking signature.

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).

MAAT/AppSketch signatures "turbovpn_udp_payload1"/"turbovpn_udp_payload2" detect Turbo VPN by matching a literal hex-encoded ASCII string in the UDP payload — keyword "$747572626f76706e0a00" decodes to the plaintext bytes "turbovpn\n\x00" — plus a second offset-anchored byte pattern, meaning Turbo VPN's own protocol handshake leaks a recognizable, unencrypted magic string that the DPI engine matches directly rather than needing any statistical or behavioral analysis.

MAAT/AppSketch signatures "hotspotvpn_ja3" and "ultrasurfvpn_update_behavior" identify Hotspot VPN and Ultrasurf specifically via static JA3 TLS ClientHello hashes (e.g. f49621211538d12435b8498f195d0c31 for Hotspot VPN; 706ea0b1920182287146b195ad4279a6 and 1f0d8bb4fab11dc335dec2e69da0c36e for Ultrasurf), in Ultrasurf's case combined with an AND-condition on a set of legitimate-looking cover domains (skype.com, msn.com, microsoft update domains) — showing the DPI engine defeats Ultrasurf's domain-mimicry cover by fingerprinting the underlying TLS stack instead of trusting the SNI/host.

The batch contains 200+ individual MAAT/AppSketch signature JSON files, most defining FQDN- and/or destination-IP-based blocking rules for a single named commercial/consumer VPN app each (LetsVPN, TurboVPN, QuarkVPN, PandaVPN, StarkVPNReloaded, VPNTurkey, BitdefenderVPN, SnapVPN, SuperSpeedVPNProxy, SuperUnlimitedVPN, CafeVPN, and dozens more), each carrying a build date — the dated files span June 2024 through November 2024 — showing a large, actively and continuously maintained per-app VPN signature catalog rather than a static blocklist.

A MAAT/AppSketch signature named "WARP on CF Edge" identifies Cloudflare WARP by matching destination IP against Cloudflare's published WARP anycast CIDR ranges (both IPv4, e.g. 162.159.192.0/24, and IPv6, e.g. 2606:4700:d0::/48) AND IP protocol UDP (ip.proto=17), while explicitly excluding destination port 443 (not_flag on a dstport=443 condition) — implying a separate rule is needed to catch WARP traffic that uses port 443.

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.

Internal MAAT engineering Q&A notes detail the rule engine's filter hierarchy: a 'region' config matches on keyword / regex / IP / extended-IP(CIDR) / numeric / file-digest / text-similarity / FQDN fields; regions roll up via AND/OR into 'group' configs; groups roll up into an 8-clause-max 'compile' config in conjunctive normal form. Rule config is pushed via a Redis single-primary/multi-replica tree, and MAAT itself is not distributed — each production front-end box runs its own single MAAT instance that receives pushed config and calls the shared rulescan library to execute the actual scan.

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.

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.

An internal TSG troubleshooting runbook ("HTTPS证书替换策略无效果") documents the certstore MITM-certificate service actively serving/validating forged certificates keyed by SNI, walking an operator through checking certstore logs for specific real-world domains including Google's update service (update.googleapis.com) and Nvidia's GFE service (services.gfe.nvidia.com), and cross-checking keyring config live via maat_redis_tool.

certstore's own commit history documents its transparent-TLS-MITM mechanics directly: it writes the client's observed SNI into the SAN field of the leaf certificate it mints on the fly, supports ECC issuance (secp192r1/secp256r1) for those forged certs, and reads its Trusted/Untrusted decryption-keyring configuration from MAAT's DECRYPTION_KEYRING table -- confirming the interception pipeline end-to-end: client SNI in, matching forged certificate out, gated by MAAT-synced keyring policy.

The "cyberghostvpn_servername" signature detects CyberGhost VPN by matching DNS query names against a list of the provider's own predictable backend node hostnames (e.g. blade6.singapore-rack456.nodes.gen4.ninja, blade5.frankfurt-rack486.nodes.gen4.ninja), showing the censor harvests and enumerates a VPN vendor's internal infrastructure-naming convention rather than relying only on client-facing domains.

An internal reference JSON enumerates known commercial VPN protocol/port/cipher combinations (L2TP:500 UDP, IKEv2 with remote-id "vpn.ipvanish.com", PPTP:1723, SSTP:443 AES-256-CBC, OpenVPN on 443/1194 UDP+TCP and additional non-standard ports like 8443, each with scramble-related fields for obfuscated variants) — functioning as a lookup table of known VPN-protocol fingerprints feeding signature development.

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.

A single AppSketch/MAAT-format signature bundle for "JumpJump VPN" (app_id 15172, characteristics "evasive,widely-used,tunnels-other-apps", deny_action method "drop") defines six independent detection surrogates: FQDN lists (including specific CloudFront distribution hostnames and *.cloudfront.net + a fixed 517-byte first-packet-length side channel), a hex-encoded HTTP tunnel payload signature, an HTTP "getNodes" API-path signature, and an HTTP/2-connection-preface byte pattern ("PRI * HTTP/2.0...SM") used to fingerprint the app's TLS-disguised tunnel.

A master AppSketch-format signature file mixes hundreds of domestic-app identification rules (iQiyi, JD.com, Tencent, Xiaomi Store, China Construction Bank, China Merchants Bank, Postal Savings Bank, Baidu Netdisk, government tax/medical portals) with foreign-VPN detection rules (BeePassVPN, BetternetVPN, BigMamaVPN, BravePrivateVPN, JumpJumpVPN, QuarkVPN, SecureVPN, VPNHero, VPNLite, VPNTurkey, etc.) inside the same rule framework and file, confirming VPN/ circumvention-tool detection is built on the identical general-purpose app-ID engine used for ordinary commercial app traffic classification, not a separate subsystem.

An internal risk memo, "Signal审查规避模式阻断风险说明" (Signal circumvention-mode blocking risk explanation), documents that after the operator pushed a "Deny Signal APP" policy, users with Signal's censorship-circumvention (domain fronting via Google infrastructure) enabled could still send messages/files; packet capture showed the fronted traffic used Google SNIs (clients3/4.google.com, inbox.google.com, android.clients.google.com, www.google.com), and the team built a targeted FQDN+JA3+payload signature specifically to block this fronted traffic while flagging a residual risk of false-positive blocking of legitimate Google services.

The tsg/dp_telemetry_app repo is a data-plane telemetry agent that loads MAAT-sourced rules (maat.c/maat.h, etc/dp_telemetry_rules.json) including BPF filter expressions, and on a match exports full packet captures (pcapng) plus MessagePack-encoded session telemetry over Kafka -- i.e. a MAAT policy match can trigger targeted, per-session raw packet capture, not just a pass/block decision.

An internal "DPI Benchmark" methodology document names the three production components underlying TSG's DPI stack and proposes benchmarking each against open-source equivalents: Marsio (DPDK-based packet I/O) for receive/transmit, Sapp ("网络安全开发平台", a high-speed traffic-processing platform) for protocol parsing and flow-table management, and Maat (Hyperscan-class signature engine with Redis-based multi-machine config sync) for pattern scanning.

The AV/frag_monitor tool (headers AV_kill_connection.h + Maat_rule.h/Maat_command.h, i.e. a MAAT-integrated flow classifier with active connection-termination capability) ships per-deployment JSON templates including frag_monitor_k_online.json — explicitly defaulted to "K project" per a 2018-12 commit, matching taxonomy's K18/Kazakhstan site codename — plus a dedicated frag_monitor_k_online_youtube.json template and a "zhongxin" (中信)-named template, indicating per-target (YouTube) and per-site blocking profiles built on top of an active kill-connection primitive.

A production TSG maat.conf shows the MAAT rule-matching engine running four parallel instances (STATIC, DYNAMIC, APP_SIGNATURE_MAAT, CAPTURE); the APP_SIGNATURE_MAAT instance is explicitly configured against app_sketch_tableinfo.conf / app_sketch_maat.json -- directly confirming MAAT is the execution engine underlying the AppSketch signature system -- and is tagged with an ACCEPT_TAGS datacenter value 'xjlhs', indicating this specific instance is scoped to a Xinjiang deployment.

A CAS-institute thesis on differentiating human vs. automated ("machine") network behavior deploys an HTTP/SSL key-field extraction and app-identification system at a live network gateway (mirrored traffic) built on a modified nDPI (extended to recognize 108 application-layer protocols) plus a custom rule-scan module whose region/group/compile config hierarchy and terminology closely parallel MAAT's separately-documented architecture, suggesting shared lineage between this academic prototype and MAAT's production rule engine.

The IPReuse/mctrl repo implements an "IP reuse" (IP复用) NAT-policy controller managing SNAT/DNAT policy tables (DNAT_POLICY) that was refactored multiple times in January 2019 specifically to call "MAAT's new interface", tying NAT-based traffic redirection/control directly to the MAAT rule engine.

The "ivacyvpn_udp_payload" signature detects IvacyVPN not via domain/IP but via a byte-pattern match on the UDP payload ("421f016e1648*" in hex, wildcarded) combined with an exact first-packet data length of 42 bytes -- i.e. a protocol-level handshake fingerprint independent of the app's server infrastructure, and robust to IP/domain rotation.

The GitLab group itself is named "K18_NTCS_WEB" (K18 = Kazakhstan), and its "nfs" web app implements per-protocol keyword-filter configuration classes (App/FTP/Mail/P2P/SSL keyword configs), an OpenVPN IP-list config, RADIUS-based logging/reporting entities, MAAT rule-sync beans, and an explicit "IP spoofing" business feature with its own "PXY仿冒地址池" (proxy spoofed-address pool) and dedicated policy-log support -- the single strongest piece of evidence in this batch tying named keyword-filtering plus IP-spoofing capabilities directly to the Kazakhstan deployment.

Geedge's MAAT/AppSketch signature system contains a dedicated, dated ruleset naming Lantern by product: signature_id 7312 "Lantern_fqdn_20241104" matches common.server_fqdn against the literal keyword "$lantern.io", and a companion signature_id 7240 "Lantern_ip_20241104" matches ip.dst against a static list of 1,604 individual IPv4 addresses, both dated 2024-11-04. The same signature file appears twice in the leak at two different artifact paths (identical content, not independent corroboration). Independent whois verification of all 1,604 IPs (not itself present in the leak document -- done by the extracting analyst against current registry data) found they collapse into only 38 distinct /16 ranges, of which ranges totaling 86.7% of the IPs return an explicit Oracle Corporation whois org record (netnames like OC-195, OC-260, ORACLE-4, ORACLE-MY, ORACLE-SE, OPC1); the remaining 13.3% are unattributed legacy RIPE/APNIC-ERX blocks with no other org found, consistent with the same historical-Oracle-lease pattern as the confirmed ranges. The individual IPs are a stale point-in-time snapshot given Lantern's IP rotation, but the provider concentration is the durable signal: this enumeration was effectively a sweep of Oracle Cloud Infrastructure's address space, not a list of arbitrarily-located relays.

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.

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.

A 616-row "Keyword" list of URL path fragments (login/register/loan-related API endpoints such as api/Order/loanuse, api/index/jiekuang, plus generic JS/CSS resource paths) with at least one entry annotated "（暂停）" (paused), demonstrating that MAAT/AppSketch signature curation extends to URL-path-level keyword matching for a specific app category (apparent online-lending/finance apps) with an active edit/curation workflow (entries can be individually paused).

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 engineering docs detail MAAT's config/policy hierarchy (region/policy-unit -> group/policy-object -> compile/policy, a conjunctive-normal-form structure capped at 8 top-level groups), its Redis-backed one-master-many-replica config push ("MAAT Redis") with a rulescan fallback, and confirm MAAT runs non-distributed -- one instance per front-end traffic-scanning box -- invoked by sapp per-packet or per-stream (Maat_stream_scan_string_detail) with match-all-then-return semantics; recommended hardware is CentOS 7, 256GB RAM, 2TB disk, 48-core 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.

A 2024-05-17 MESA Lab / field-deployment engineering meeting documents MAAT's live rule-config pipeline in operational detail: a hard cap of 4096 hit results per query, incremental sequence-numbered config deltas reloaded on top of the last full snapshot, a documented "hit vacuum period" during config reload where partially-loaded rules silently fail to match, and separate JSON (test-only, small-scale) vs. Excel-tool-generated (production) config-authoring workflows.

The Transformer_master.h header (part of the Maat/sapp DPI framework, dated 2023-05-04) defines a region-keyed DNS response-forgery subsystem (MSG_OPT_DNS_CHEAT_TYPE/RCODE/STRATEGY/RECORD/TTL, DNS_FAKE_INFO/DNS_FAKE_IP tables, TF_get_dns_response_strategy_id(user_region)) used specifically by the block ("FD") action path, plus a dedicated function to classify whether a detected L7 protocol is a VPN (TF_is_L7_vpn_prot), and native extraction of TLS JA3/JA3S client and server fingerprints.

The tango/maat rule-matching engine (TSG's core signature/policy compiler behind libmaatframe.so, 1077 commits) has production test fixtures containing a rule category literally named NTC_DNS_FAKE_IP_CB ('DNS fake-IP callback'), alongside NTC_DNS_REGION and NTC_DNS_RES_STRATEGY rule types -- confirming DNS response injection/spoofing is a first-class, named rule category in MAAT's compiled rule format rather than an ad hoc side capability.

The 2019 chenguanlin/gie_server repo implements a standalone "Gram Index Engine" (GIE_server) service that links directly against libmaatframe.so and bundles Maat_rule.cpp/.h, indicating an n-gram/substring pre-indexing layer sits alongside MAAT's Hyperscan/Rulescan pattern-matching engine for DPI signature matching.

MAAT's compiled rule format includes explicit HTTP URL/request-body/response-body matching rule categories (NTC_HTTP_URL, NTC_HTTP_REQ_BODY, NTC_HTTP_RES_BODY) and email content/header matching categories (NTC_MAIL_BODY, NTC_MAIL_HDR), and its scanner backend supports two swappable regex engines -- a Hyperscan adapter (adapter_hs) and a 'Rulescan' adapter (adapter_rs) -- corroborating this corpus's existing understanding that MAAT falls back from Hyperscan to Rulescan above roughly 50K rules.

Internal Q&A notes and the libmaatframe.so MAAT_INIT_OPT header confirm MAAT's rule-matching engine is Redis-backed for config sync (MAAT_OPT_REDIS_IP/PORT/INDEX, matching taxonomy.yaml's maat_redis_tool note), supports an optional decrypt key for encrypted rule files (MAAT_OPT_DECRYPT_KEY), and accepts arbitrary JSON deployment-tag metadata via MAAT_OPT_ACCEPT_TAGS — the documented worked example tags a MAAT instance with a street-level location. A companion Q&A confirms sapp calls MAAT via Maat_stream_scan_string_detail for cross-packet (streaming) signature matching, that match rules are authored in a web front-end and pushed to field machines by a "config pipeline" (配置线) as JSON, and specifies minimum deployment hardware: CentOS 7, 256GB+ RAM, 2TB+ disk, 48-core Intel Xeon E5.

The liuxueli/install-standalone-redis repo shows MAAT's Redis config-distribution backbone deployed as a 3-tier replication topology (redis-master, redis-global-slave, redis-global-slave-master) with dedicated systemd services and a MAAT_PRE_VER initialization variable, confirming Redis is provisioned specifically as MAAT's live rule-sync layer rather than as general-purpose caching.

A MAAT/rulescan crash-debugging log shows the engine's getCfgId() lookup called with domain=".twitter.com", table_id=12, type="SNI", confirming MAAT performs SNI-field domain matching against a configured blocklist table (table_id 12 = SSL/SNI domain tables DF_SSL_REGION/DJ_SSL_REGION; table_id 22 = HTTP URL tables DF_HTTP_URL/DJ_HTTP_URL seen in the same crash series), and that the underlying librulescan.so string-scan library is prone to native crashes (SIGABRT) under real traffic.

The MAAT rule-engine's native C initialization API (MAAT_INIT_OPT enum) confirms Redis-backed live config sync (MAAT_OPT_REDIS_IP/PORT/INDEX, with a cumulative-update mode), matching the taxonomy's maat_redis_tool description, and exposes a MAAT_OPT_ACCEPT_TAGS mechanism for attaching arbitrary JSON metadata tags -- the documented example tags a deployment with a specific Beijing district location and an ISP name.

MAAT's URL-classification/rule-matching RESTful service (url_label_restiful, maat_table_info.conf, Maat_rule.h) is built on the shared MESA 'stream' C headers -- including stream_inject.h, stream_control.h, stream_proxy.h, and stream_rawpkt.h -- confirming packet injection, proxying, and raw-packet control are core primitives of the same low-level framework MAAT's rule engine sits on.

Geedge maintains an internal fork of the open-source ZeroTier libzt P2P networking SDK (zhangyang/libzt) with Geedge-only commits adding an example named "wannat" and enabling LWIP_RAW/IP_FORWARD. The recurrence of "WANNAT" naming here and in MAAT's subscriber-ID-to-IP rule objects suggests a shared internal system/codename spanning the rule engine and a modified peer-to-peer tunneling library, though the exact relationship is not established from this artifact alone.

Demo configs for the MAAT rule engine define object types WANNAT_OBJ_UE_ID and WANNAT_DYN_UE_ID_IP (a dynamic mapping of subscriber/device UE ID to current IP address), showing MAAT's rule/object model has first-class support for correlating a subscriber identity to an IP address, not only FQDN/IP signature matching.

TFE includes a dedicated DoH (DNS-over-HTTPS) business plugin that parses and reconstructs DoH POST/response traffic, applies MAAT policy scanning to it, and supports a "Redirect-DoH" policy action tracked by a distinct "DoH_hijack" counter -- meaning encrypted DoH queries are actively parsed and redirected/hijacked by policy, not simply blocked outright.

IPReuse/mgw is a C++ NAT gateway (DNAT/SNAT) built by an IIE engineer that includes a vpn_monitor module which periodically polls a VPN server to resolve the current IP-to-user mapping, and integrates directly with the MAAT rule engine via a maat_redis handle (test_maat_redis.cpp, vendored maat-v2.3.3.tar.gz) — an early (2018) implementation of tying network-layer IP addresses to individual VPN user identity for policy purposes.

The IPReuse/mrl tool -- a NAT link-learning daemon integrated with Marsio (which fills VXLAN headers using MRL-supplied virtual link IDs) and MAAT (shared 'maat_feather' candidate/nominee tables) -- ships a Kazakhstan-specific MaxMind-format IP geolocation database (Kazakhstan_v4.mmdb) directly in its own config directory and again inside its bundled IPLocator dependency. Commit history describes self-learning of link info, SNAT/DNAT policy support, and sending virtual link IDs to 'the platform' for Marsio's VXLAN encapsulation.

A crash/perf bug report reveals Geedge's MAAT rule engine (libmaatframe.so, using Intel Hyperscan for literal/regex matching) running with 545,441 FQDN blocking rules and 404,141 IP address blocking rules loaded in a single instance as of 2024; loading 500,000 new FQDN rules via the full Hyperscan path took ~95 minutes, addressed by an automatic fallback to a second engine ("Rulescan") above 50,000 rules.

TSG's app_proto_identify/app_sketch_local components reference and extend the open-source nDPI project's detectors (specifically openvpn.c) when fixing signatures. "MAAT" is sapp's Redis-backed live-config-sync subsystem, which can enter a bad state requiring an sapp restart to reload policy.

A Fujian-site performance incident (single-core CPU pinned >90%, packet loss) traced to a large keyword-object list (~400 hex-encoded keywords, described as connected-vehicle-related) being scanned per-packet by components named libmaatframe, librulescan, and fw_http_plug. Removing unused keyword objects resolved the packet loss.

The Fujian (domestic China) deployment uses a punycode/IDN-aware keyword-filtering policy object named '中文涉诈域名' (Chinese fraud-related domains) with wildcard item matching; a bug ticket shows the policy engine failing to match an IDN punycode domain correctly against this object, revealing the underlying components: a 'verify-policy' microservice, and libraries 'libmaatframe' and 'librulescan' handling rule evaluation.

The PanGu/pangu_valve repo implements MAAT's live blocking/throttling distribution layer: it consumes Redis-backed MAAT config tables (APP_DOMAIN, APP_POLICY, LIMIT_DOMAIN, APP_STATIC_SEV_IP, APP_DYN_SEV_IP_CB, LIMIT_DYN_IP_CB) and pushes reference-counted domain/IP block and rate-limit rules to inline ("串联设备") network devices, scoped per inline-device business ID.

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.

A generic RADIUS/AAA-sniffing traffic-engine plugin (NTC_RADIUS_PLUG, default SERVICE_ID 0xA2) parses live RADIUS Access/Accounting packets off the wire and extracts User-Name, Calling-Station-ID (the subscriber's phone number), Called-Station-ID, Framed-IP-Address, NAS-IP, Acct-Session-Id and related attributes, tags each record with a global stream-trace ID, and streams it to Kafka topic 'RADIUS-RECORD-LOG'. This is a concrete source-code-level match for the carrier RADIUS/AAA-ingestion mechanism the taxonomy attributes to the CyberNarrator subscriber-identity-correlation component (Pakistan deployment, Jazz/Zong/Ufone/Telenor), though this particular file is generic/unbranded rather than explicitly named CyberNarrator.

A raw, verbatim capture of ProtonVPN's own "LogicalServers" API response (127 server entries with entry/exit IPs, WireGuard X25519 public keys, and country/city metadata) sits alongside a MAAT "ProtonVPN_ip"/"ProtonVPN_fqdn" signature in the same corpus, indicating the operator harvests VPN providers' own server-list APIs to seed IP/domain blocklists -- the same methodology documented for the Psiphon-IP-harvesting "vpn-thwarting" pipeline (CyberNarrator), here shown applied to a second, unrelated VPN provider (ProtonVPN).

A MAAT/AppSketch signature named Psiphon-QUIC-Payload (id 4203) flags Psiphon's QUIC transport by matching an exact UDP client-to-server first-packet payload length of 1252 bytes combined with an internal app_id and an extensive destination-IP CIDR allowlist covering hundreds of /22-/24 blocks -- i.e. Psiphon-over-QUIC is fingerprinted by a fixed early-packet length rather than by content.

Primary-source MESA Lab wiki documentation confirms SAPP ("Stream Analyse Process Platform") is a plugin-based traffic-inspection engine achieving 10-40Gbps per hardware unit, deployable either inline (串联) or as a passive mirror tap (并联), and exposes core platform APIs available to any business-layer plugin for forging a TCP RST (MESA_kill_tcp), spoofing a fake SYN/ACK to block connection establishment (MESA_kill_tcp_synack), and injecting arbitrary application-layer data into an established flow (MESA_inject_pkt).

A raw sapp deployment/config script shows an operator toggling `kickout_udp_stream_enabled=0` to `=1` in sapp.toml (via sed, in place on a live tsg-traffic-engine-vsys-1 install), alongside RPM upgrades of sapp's ssl/firewall/dtls/utable/libmaatframe components, and separately disabling SEND_SESSION_RECORD and SEND_FILE_STREAM_RECORD logging flags in main.conf — confirming sapp has an explicit, operator-toggleable feature to actively terminate UDP streams it flags, independent of whatever passive detection triggered the flag.

TSG's DPI signature engine is organized around named internal components confirmed by config paths and error logs: SAPP (installed at /home/mesasoft/sapp_run or /opt/tsg/sapp), MAAT (config at .../tsgconf/maat.conf, tied to a Redis-backed APP_SIG_SESSION_ATTRIBUTE_STRING table), and App-SketchDB (a versioned, centrally-maintained app-identification signature database pulled periodically by field deployments). One deployment's provincial gateway alone had 1,667 TCP/UDP first-packet payload signature entries active (396 at the IDC site), confirming payload-prefix matching as a live, large-scale detection method, including custom byte-prefix entries for DingTalk and WeChat.

A MESA lab engineering project codenamed "SAT" builds a user-station identification module on top of TSG, using the MAAT rule-file format for its front-end/back-end policy (PZ) interface, and ingests LTE mobile-network-element traffic (S1-U interface -- SGW/PGW/eNodeB/MME, captured via a simulated Docker SDR environment) to write subscriber-station status into a "TSG-Radius" table.

TSG's "shaping-engine" (tango/shaping-engine) implements bandwidth-shaping "Profiles" (fair-share token allocation, priority-based bandwidth borrowing, active queue management) driven by rules loaded directly from MAAT (shaper_maat.cpp/h, shaping_maat.json, migrated to MAAT's JSON rule format with UUID rule IDs), providing the likely underlying enforcement mechanism behind app-specific RateLimit deny actions such as the Psiphon/Freegate throttling documented in gap_tsg_api.

The same JSON signature-rule format used for VPN-app detection (signatureName / andConditions / orConditions, matched on http.host or ssl.sni) is used at production scale for ordinary domestic consumer apps as well — individual signature files observed for Kuaishou, Taobao, the digital-RMB wallet app ("数字人民币"), and WeWork — confirming a single, general-purpose app-identification pipeline (consistent with the taxonomy's AppSketch/MAAT description) covers both everyday commercial traffic and circumvention tooling under one signature format and production cadence.

A sapp-based "single flow aggregation" module's header dependencies (Maat_command.h, Maat_rule.h alongside stream_inject.h and sapp_inject.h, plus wiredLB.h/wired_cfg.h) show sapp's Maat rule-matching engine and its packet/stream-injection subsystem share a common internal API surface within the same MESA include tree, corroborating that a Maat rule hit can directly drive inline packet injection within one sapp pipeline instance.

"stellar" (git.mesalab.cn / geedgenetworks.com) is a C++ core DPI packet-processing engine with protocol decoders (HTTP, FTP, mail, QUIC, RTP, SIP, DTLS, SSL, DNS, SOCKS, stratum) and a dedicated packet-injection module (src/stellar/inject.cpp) with an extensive TCP-RST-injection test suite covering injection timed after SYN, SYN-ACK, first C2S payload, and sub-ACK. It integrates the MAAT rule engine (security_enforcer.cpp / scanner_maat.c, "Security enforcer maat plugin table"), the Marsio packet-I/O framework (marsio_io.cpp), and glimpse_detector as an integrated decoder plugin ("integration glimpse_detector", "rename to lpi plugin").

pzx/tensor-k18 packages a MAAT-integrated processing component ("tensor") with three separate customer/site config profiles (IPZY, T1-2, YSP), each with its own maat_redis.conf, and the repo itself is named "tensor-k18" — direct evidence this component is built and configured specifically for the K18 (Kazakhstan) deployment.

A single MAAT-format signature named "tor_ip" enumerates at least 802 distinct IPv4 addresses matched against ip.dst, i.e. a dedicated, large-scale Tor relay/bridge IP blocklist maintained as a first-class detection signature alongside the commercial-VPN signatures in the same corpus.

The tango/tsg-service-chaining-engine (SCE) repo implements TSG's traffic-steering core: it VXLAN-encapsulates and routes both "raw" and "decrypted" copies of a session (four tracked metadata directions) through a chain of up to 32 third-party "Service Functions", with explicit per-flow actions of block, bypass, forward, and rx_drop for both mirrored and inline-steered traffic, coordinating with SAPP, mrzcpd (packet capture/re-injection), and MAAT4 (rule engine) via control-plane messages.

Geedge's production inline-deployment container bundle (tango/tsg_container) wires mrzcpd (capture/inject), sapp (DPI via maat rules), and a third component "tfe" (traffic-forwarding engine) together via Docker Compose; tfe ships a dedicated doh.conf (DNS-over-HTTPS handling) and the firewall-mode container's sapp config includes a send_raw_pkt.conf, a KNI (kernel network interface) config, an "asymmetric_presence_layer.conf" for mirror/asymmetric-routing deployments, and a "pangu" proxy module (pangu_pxy.conf / pangu_http.json).

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.

TSG's Ansible deployment platform ('tsg/tsg-scripts-platform') installs per-protocol firewall RPM modules -- dedicated dns, ftp, http, mail, quic, and ssl packages -- alongside the sapp DPI engine and mrzcpd packet-mirror/inject agent, confirming TSG ships a purpose-built QUIC/HTTP3 blocking module as a first-class protocol-firewall component.

TSG's security-policy verification engine (tango/verify-policy) supports 'ssl.no_sni', 'ssl.ech' (Encrypted ClientHello), and 'ssl.esni' (Encrypted SNI) as first-class Boolean match conditions in its policy language (TSG-18943), meaning TSG can write and evaluate blocking/monitoring policies that specifically trigger on TLS connections carrying no SNI, ECH, or ESNI.

TSG formally distinguishes a 'Proxy-Intercept' policy action type from generic security policy (TSG-14954/14955, later merging their underlying MAAT rule-engine handles) and layers service-chaining/traffic-shaping actions with a defined priority order (Shunt > Allow(monitor) > Deny(monitor)) -- confirming TLS/traffic interception (MITM) is a named, first-class policy category in TSG rather than an implicit side effect of blocking rules.

Geedge's AppSketch/MAAT signature store contains a large, actively-maintained catalog of per-app FQDN+IP blocking signatures for dozens of named consumer VPN apps (StartVPN, DotVPN, VPNLite, BullVPN, RapidVPN, QuarkVPN, AdGuardVPN, BulletVPN, NotVPN, LetsVPN, PandaVPN, ACE VPN, BetternetVPN, HulaVPN, ThunderVPN, TurboVPN, and more, patch-dated across 2024), each tagged category='networking'/subcategory='tunnels' (or similar) with a deny_action of packet drop (sometimes with TCP RST), and some apps additionally flagged characteristics='evasive' with elevated risk scores; several apps' FQDN lists show the same domain-generation pattern (random word + .xyz/.info) later seen automated in a companion detection script.

Live TSG session logs from an internal test bed (device 21426003 / XXG-TSG-BJ) show active Deny actions firing against named commercial VPN apps -- Super Unlimited VPN, BetternetVPN, TouchVPN, LetsVPN -- via dated signature patches (e.g. BetternetVPN_Patch01_20240812 through Patch06_20240920, SuperUnlimitedVPN_Patch05 through Patch10 within six weeks), and LetsVPN's block fires on a JA3 TLS fingerprint (LetsVPN_by_ja3) even when the SNI/Host is spoofed to www.bytedance.com.

Beyond the Lantern-specific rules, this batch contains ~40 individually-dated JSON signature files from the same MAAT/AppSketch rule format, each targeting one named VPN/circumvention client by FQDN, destination IP, TLS JA3 hash, or certificate issuer: Signal, Orbot, Cloudflare WARP (including a MASQUE-specific variant combining an app_id classifier with an FQDN condition), ExpressVPN (matched by a literal JA3 hash plus a separate FQDN rule), ProtonVPN/ProtonMail, TurboVPN, QuarkVPN, LetsVPN, BetternetVPN, Browsec, GeckoVPN, HulaVPN, JumpJumpVPN, MouseVPN, NotVPN, SecureVPN, StarkVPNReloaded, SuperUnlimitedVPN, TowerVPN, TrustzoneVPN, USAVPN, VPNIndia/VPNLite/VPNPro/VPNTurkey, FlyVPN, ACE VPN, F1 Rockets VPN, and the Chinese gaming accelerator biubiu加速器. Dates cluster tightly (e.g. many on 2024-08-09, others 2024-09/10/11), indicating an active, continuously-updated per-app signature production pipeline rather than a static list.

A large set of individually-dated per-product signature files shows at least 31 distinct named commercial VPN apps under active, ongoing detection engineering (SecureVPN, LetsVPN, BetternetVPN, SuperUnlimitedVPN, TunnelBear, AtlasVPN, TurboVPN, UrbanVPN, GeckoVPN, VPNUnlimited, BitdefenderVPN, QuarkVPN, FlyVPN, HulaVPN, SurfVPN, BulletVPN, BeePassVPN, SnapVPN, WhitehatVPN, LunaVPN, SuperNetVPN, GitiVPN, CleanerAntivirusVPN, V2VPN/V2Netvpn, 7VPN, and country-branded VPNIndia/VPNCanada/VPNIndonesia/VPNKorea apps), each with multiple detection vectors per app (destination-IP ranges, FQDN, DNS QNAME, TLS cert issuer, JA3, WireGuard-protocol matching, ISAKMP/IKE matching, raw TCP payload); one file shows the resulting policy rule object wired directly to an explicit deny action.

Across dozens of individual signature-rule JSON files in this batch, at least 40 distinct named commercial VPN products carry dedicated detection signatures (by IP src/dst, FQDN, JA3 hash, or protocol-specific payload): BeePassVPN, BetternetVPN (separate isakmp/ja3/WireGuard sub- signatures), BigMamaVPN, BravePrivateVPN, ExpressVPN (JA3 + UDP-payload variants), FlyVPN, hidemevpn (OpenVPN UDP payload), JourneyVPN, JumpjumpVPN, LetsVPN (JA3), Psiphon3 ("psiphon3vpn_serverip"), QuarkVPN, SecureVPN, SuperUnlimitedVPN, TurboVPN, VPNHero, VPNTurkey, and others, each dated/versioned (e.g. "_20240812") indicating an ongoing signature-maintenance pipeline rather than a one-off ruleset.

Dozens of near-identical MAAT/AppSketch-style signature-definition files in this batch each target one named commercial VPN app/service (ProtonVPN, HotSpot VPN, SuperUnlimitedVPN, jumpjumpVPN, BetternetVPN, NotVPN, VPNLite, SymlexVPN, etc.), matched via FQDN suffix, destination IP list, and/or TLS JA3 hash. The same "SuperUnlimitedVPN" signature recurs with new signature_ids/dates roughly monthly (2024-06, -09, -10, -11), showing this is a continuously-maintained, actively-updated VPN-detection pipeline rather than a one-off snapshot.

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.

Session-log exports from a Beijing test/demo TSG device ("XXG-TSG-BJ") show live "Deny" enforcement actions (security_rule_list "Deny_VPNHero", "deny_TowerVPN") against traffic the app-ID engine classified with nested app chains "VPNHero" and "OPENVPN.TowerVPN.Psiphon Provider.Psiphon-Server" -- i.e. TowerVPN is specifically tagged internally as riding on Psiphon infrastructure, and both it and VPNHero are actively blocked, not just logged, on this device.

Two paired MAAT signatures, "warp_masque_m" and "warp_ip", detect Cloudflare WARP/MASQUE traffic: one matches destination IP 162.159.198.1 (a published Cloudflare WARP anycast address) combined with an internal app_id classification (140/15629), the other matches the same infrastructure via IP protocol number alone -- i.e. WARP is detected both by a fixed anycast IP and by an app-ID classifier layered on top of it.

A single AppSketch/MAAT signature bundle for Windscribe VPN fuses four independent detection techniques in production: an OpenVPN-handshake payload signature (fixed hex bytes at a specific byte offset/depth plus an exact packet-length check), a TLS certificate subject_organization_name match on the literal string 'Windscribe', a JA3 TLS-ClientHello fingerprint hash, and DNS query-name matching against 100+ individually enumerated obfuscation/CDN-rotation domains (windscribe.com plus many totallyacdn.com and whiskergalaxy.com hostnames).