An internal sapp platform developer manual reveals sapp's full name ("Stream Analyse Process Platform") and documents a stream.tcp.inject.signature_enabled config option that embeds an identifiable pattern into TSG/sapp-injected TCP RST packets via the ip_id, ip_ttl, and tcp_win fields, explicitly so that RST packets originating from sapp can be verified with Wireshark or a standalone tool. The same section documents the platform's default RST-injection count ("first 3, then 1" per blocked connection).
是否开启RST包指纹，开启后，会在数据包的ip_id, ip_ttl, tcp_win等字段增加指纹信息，用于识别哪些RST包是来自sapp平台，可使用wireshark插件或独立工具验证。即使此项开启，因字段长度有限，召回率是100%，准确率不一定保证100%
Defense implications
- sapp's optional RST fingerprint (ip_id/ip_ttl/tcp_win) is a documented, if imperfect, way to attribute an observed GFW/TSG RST injection specifically to the sapp engine; a non-match doesn't rule it out since the feature is opt-in per the vendor's own caveat.
- The documented default RST-burst pattern (3 packets, then 1 per subsequent packet) is a further correlatable signature worth checking against field measurements of GFW resets.
Related findings
sapp's plugin API exposes explicit enforcement primitives -- MESA_kill_tcp()/MESA_rst_tcp() to inject a single RST, and MESA_set_stream_opt() with MSO_TCP_RST_REMEDY/MSO_DROP_STREAM to make RST-injection or packet-dropping persist for the remaining lifetime of a flow -- with a global sapp.toml auto_remedy toggle and a per-stream option controlling whether a lone RST is reinforced repeatedly for as long as the flow keeps sending data.
sapp's internal architecture guide documents three deployment topologies (mirror/passive-tap, inline, dual-arm transparent) and four distinct methods for injecting blocking packets back onto the wire, including a MAC-in-MAC scheme that extracts device/link IDs from mirrored traffic's source MAC field to route an injected packet to the correct physically separate inline device over VXLAN when multiple injection points exist.
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.
Commit history in the core sapp DPI engine repo (MESA_Platform/sapp) shows its RST-style blocking/injection path is internally called "欺骗包" (literally "deceptive/spoofed packet") injection, implemented via a sapp_inject_ctrl_pkt function that sends forged control packets to all devices opened through the marsio packet-I/O layer; ticket TSG-20317 documents active, ongoing optimization of "inject packet duplicate traffic detection" performance in this code path as of 2024.
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.