An internal SAPP platform training/reference manual (marked "Geedge Networks Confidential And Proprietary") gives SAPP's full name as "Stream Analyse Process Platform" and documents its three-tier plugin architecture (platform / protocol-parsing / business layers, each loaded via dlopen), inline and mirror deployment modes at a stated 10-40 Gbps per box, tunnel-protocol support (GRE/MPLS/IPIP/IPv6-over-IPv4/Teredo), and the MESA_kill_tcp() plugin API that forges and sends RST packets to sever a monitored TCP connection, with the manual noting it was "originally used in mirror mode to send RST packets to block a TCP connection" and auto-retries until the connection is confirmed dead.
sapp是个简称，它的全名叫Stream Analyse Process Platform，即面向高速网络流处理的网络安全开发平台。...MESA_kill_TCP 最早用于mirror并联模式，用于发送RST包，以阻断某个TCP连接。后来增加了一系列隐含逻辑：以后不再调用任何插件；自动FD补救...因丢包、网络延时、序号猜测错误等原因，可能导致kill不成功，为了简化插件的操作，平台会自动再发RST包，直至连接被阻断为止。
Defense implications
- Assume GFW-lineage mirror/passive-tap deployments retry forged RST packets automatically until a flow is confirmed dead (MESA_kill_tcp's auto-remediation loop) — a transport that merely ignores a single spoofed RST is not enough; it should tolerate repeated RST bursts over the flow's lifetime.
- The manual documents an explicit anti-evasion check for SYN-sequence reuse on a reused 4-tuple within a 3-second window ("防止恶意逃逸检测行为") — do not rely on rapid port/4-tuple reuse with altered sequence numbers as a blocking-evasion technique against SAPP-based inline deployments.
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 same SAPP manual documents mrzcpd's inline (串联) packet-re-injection subcomponent mrtunnat, configured at /opt/mrzcpd/etc/mrtunnat.conf: use_recent_tunnel=1 allows it to inject a packet with no prior session record, and use_link_info_table=1 makes it validate outer MAC, link_id, link_dir, and inner MAC against a live link-state table at /run/mrzcpd/mrmonit.tunnat before re-injecting a censor-forged packet onto the correct physical link.
The same operations manual's troubleshooting section confirms the blocking system operationally injects forged RST and "spoofed" (欺骗) packets onto mirrored/passive-tap links via network devices — validated by test-injecting a packet via tcpreplay to an external VPS and confirming arrival with tcpdump — runs the sapp process under supervisor scripts with live status/config-version files (TF_maat.status, RESTART.log), and distinguishes a national "GF" system from separate provincial-gateway ("省口") deployments when localizing which egress point a given block should have taken effect at.
A "精管流量初步分析报告" (2021-07-26) documents a live paired-sapp TLS-interception testbed: sapp instance A captures raw ciphertext via mrzcpd/PAG while sapp instance B ingests plaintext from a third-party decryption platform over a Unix domain socket. The report measures decryption latency (mean 1.82ms), completeness (only 44% of connections flagged decryptable via an SSL/TLS ClientHello-based "user legitimacy" check were actually decrypted, and 88% of eligible users), and confirms RST-based blocking triggered from the decrypted side reaches the client in a median ~0.5ms and successfully blocked live access to Facebook, Wikipedia, Twitter, the New York Times, and Google (BBC was the one tested site that evaded blocking). The decrypted side also resolves each session to a persistent per-user ID via the ciphertext side's four-tuple lookup.
TSG's RST-injection blocking pipeline is architecturally split: mrzcpd (packet-mirror/capture agent) batches packets (config sz_buffer, packets-per-forward) before handing them to sapp (the inspection/policy engine) for match-and-RST. Under certain carrier/traffic conditions this batching introduced a 5-20ms delay between the real SYN and sapp's RST, letting the blocked connection's data through before the RST arrived -- a confirmed, reproducible bypass ('穿透') on specific Fujian ISP links, fixed only by setting sz_buffer to 0 (no batching).
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).