sapp's TCP RST-injection ('kill_tcp') subsystem is configurable per deployment with an auto-remedy retry count and a two-part numeric 'signature' embedded in injected RST packets (signature_seed1/signature_seed2), plus an option to have the reset instead issued via a separate inline device rather than from sapp itself. The low-level injection API (sapp_inject_pkt) explicitly supports excluding/including the IP header so a companion 'assistant' module can forge the TTL, IP ID, and TCP window to match the live flow before injection, and logs the exact spoofed ttl/ipid/checksum values it sent.
[stream.tcp.inject.rst] auto_remedy=1 number=1 signature_enabled=1 signature_seed1=65535 signature_seed2=13 remedy_kill_tcp_by_inline_device=0
Defense implications
- Treat unsolicited/spoofed TCP RSTs as untrustworthy at the transport layer where possible (e.g. require in-band confirmation before tearing down a session) since sapp's resets are deliberately crafted to match the live flow's TTL/IP-ID/window rather than being trivially distinguishable off-path resets.
- The constant per-deployment signature_seed1/seed2 values are a potential fingerprint of Geedge-originated RSTs across a censor's network if they don't vary by session — worth probing for in blocking-event telemetry.
Cited artifacts
mesalab_git—MESA_Platform/sapp.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 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.
Geedge Networks' official 'Confidential and Proprietary' sapp developer manual documents sapp's platform-provided packet-injection API available to any business plugin: MESA_kill_tcp (crafts and sends a TCP RST matching the current flow's 4-tuple/sequence to force-terminate a TCP stream), MESA_kill_tcp_synack (sends a forged SYN/ACK in response to a client's SYN so the client cannot complete a handshake with the real server), and MESA_inject_pkt (injects arbitrary application-layer data into either side of an established flow).
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.
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.