A T2-tier business plugin (T2_HTTP_DIG_BIZ) reassembles full HTTP request and response bodies (including gzip-decompressed content) out of monitored sessions and hands them to an internal 'digapis_detector' engine that classifies traffic into vulnerability/attack categories, logging hits to an Elasticsearch index ('aiids_tcp_', doc_type 'vulnerability') on an internal ES cluster reached with a hardcoded admin credential. A companion Python script bundled in the same archive ('high_menace_zhilan_exp.py', i.e. roughly 'high-risk ... exploit') is a working proof-of-concept that logs into a DVWA test target and repeatedly uploads a base64-encoded PHP webshell to the uploads directory to get remote command execution — consistent with being used to exercise/validate the digapis vulnerability detector against a known file-upload RCE class rather than for censorship per se.
MESA_load_profile_string_def(t2_biz_conf_file, "HTTP_BIZ", "ES_URL", dig_cfg.es_url, MAX_PATH_LEN, "http://elastic:[email protected]:39200/"); ... MESA_load_profile_string_def(t2_biz_conf_file, "HTTP_BIZ", "ES_DOC_TYPE", dig_cfg.es_doc_type, 128, "vulnerability");
Defense implications
- Not primarily a censorship-blocking component, but confirms the pipeline fully reassembles and content-inspects gzip-decompressed HTTP bodies (not just headers) for every session — any covert channel riding over plaintext HTTP is fully visible at the content level to this tier, not just at the URL/header level covered by other T1 plugins.
Cited artifacts
mesalab_git—PanGu/t2httpcontentscanner.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 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.
An internal design note for a 'Shadowsocks traffic parsing/restoration module' describes decrypting captured Shadowsocks payloads back to the original HTTP request/response, given a known pre-shared key (AES-256-CFB, MD5-derived key, IV embedded in the stream).
A dedicated internal "运营商前端分析团队" (Carrier Front-end Analysis Team) produces weekly, carrier-specific traffic-analysis reports explicitly titled "新疆移动流量分析报告" (Xinjiang Mobile Traffic Analysis Report) and "新疆联通流量分析报告" (Xinjiang Unicom Traffic Analysis Report), with instances dated from at least July 2022 through March 2024. One instance (Xinjiang Mobile, 2023-05-15) reports total carrier bandwidth of 4.4Tbps (1Tbps access bandwidth), 27.34PB of weekly throughput, 123 distinct identified application-layer protocols, and a section (4.1, pages 17+) explicitly tracking server IP/location for 28 named overseas apps (BBC, Discord, ESPN, Facebook, Gmail, Google, Hulu, Instagram, Netflix, Reddit, Skype, Telegram, Twitter, Uber, WhatsApp, Wikipedia, YouTube, Zoom, etc.).
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.