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.
对域IP表添加引用计数，引用计数不为0时不下发删除；删除表中service定义；APP类表关联采用user_region中的config_id代替APP_ID；有开关的情况下使用IP域表的service替代开关表中的service；
Defense implications
- Lantern egress/exit IPs and domains distributed via CDN or domain-fronting should assume reference-counted, near-real-time (Redis-synced) block-list churn — a domain added to APP_DOMAIN or an IP added to LIMIT_DYN_IP_CB can propagate to inline blocking devices without a full TSG-OS release; design domain/IP rotation cadence assuming turnaround on the order of a Redis sync interval, not a release cycle.
Cited artifacts
mesalab_git—PanGu/pangu_valve.bundle(git-commit-log)
Provenance pointers only — no leak content is rehosted. Raw material: Enlace Hacktivista.
Related findings
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.
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.
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.