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).
对于TCP_RST包，数据包构造即发送全部由平台实现，插件直接调用此接口即可发送符合当前流四元组和序号的RST包，可强制终止当前TCP流。通常是TCPALL层的业务插件获取到第一个SYN包后调用，通过发送一个虚假的SYN/ACK应答，导致客户端无法和真实服务器建立连接。发送任意的应用层数据，插件调用此接口后，平台自动根据当前流的四元组信息（及隧道封装信息），发送给C/S通信双方。
Defense implications
- sapp's inline deployment can both send forged RST toward either endpoint and forge a SYN/ACK to preempt real handshake completion — protocols should not trust an early RST or SYN/ACK as authoritative and should prefer designs that require full cryptographic handshake completion before treating a connection as failed.
- MESA_inject_pkt permits arbitrary in-band payload injection into an already-established flow from the platform level — treat unexpected in-band data appearing mid-stream as a signal of active on-path tampering, not merely passive DPI.
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 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.
An official "Geedge Networks Confidential And Proprietary" sapp/mrzcpd operations manual documents the packet-injection API (MESA_kill_tcp / MESA_inject_pkt) used for both out-of-band mirror-tap RST injection (relies on the local box's own IP routing table to send) and inline in-path injection (requires mrtunnat.conf tunnel-tracking state -- use_recent_tunnel, use_link_info_table -- keyed on outer/inner MAC and link_id/link_dir), plus the Marsio DPDK-based driver's I/O sub-modes (marsio4, marsio_vxlan, pag_marsio, agent_smith) and its role extracting VXLAN/GTP encapsulation metadata and stamping link/circuit identifiers into mirrored packets' MAC field for session-log correlation.
SAPP's internal developer manual documents three generic "packet-send" interfaces exposed to every business plugin: MESA_kill_tcp (builds and sends a TCP RST matching the current flow's four-tuple/sequence numbers to forcibly terminate a connection), MESA_kill_tcp_synack (sends a forged SYN/ACK so the client can never complete a handshake with the real server), and MESA_inject_pkt (injects arbitrary application-layer payload toward either side of a flow). This confirms RST-injection and payload-injection are first-class, reusable platform primitives, not one-off code, and that mrzcpd is the mechanism that re-injects sapp-generated blocking packets into a mirrored/passive-tap link (consistent with taxonomy.yaml's mrzcpd note).
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).
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.