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.
MSG_OPT_DNS_CHEAT_TYPE, // Only in FD ... MSG_OPT_DNS_CHEAT_RCODE, // Only in FD ... MSG_OPT_DNS_CHEAT_STRATEGY, // Only in FD ... MSG_OPT_DNS_CHEAT_RECORD, // Only in FD ... MSG_OPT_DNS_CHEAT_TTL, // Only in FD ... int TF_get_dns_response_strategy_id(const char *user_region); ... bool TF_is_L7_vpn_prot(char *l7_protol_name, uint length); ... MSG_OPT_SSL_JA3, MSG_OPT_SSL_JA3S, MSG_OPT_SSL_JA3_FULL_STRING, MSG_OPT_SSL_JA3S_FULL_STRING
Defense implications
- DNS spoof responses from this stack are configurable per user_region (i.e. per deployment/site) -- do not assume a single global DNS-injection behavior; probe each site codename separately.
- JA3/JA3S is captured natively as a first-class field, so TLS client fingerprint randomization is directly relevant to evading this pipeline's classifier, not just its keyword/SNI stage.
Related findings
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.
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.
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 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.