sapp's packet_io configuration exposes three deployment topologies (mirror, inline, transparent) and, for non-mirror modes, four packet-injection paths for delivering blocked/modified traffic: default system routing, VXLAN encapsulation to an inline device over UDP, or raw Ethernet delivery to a single or multiple next-hop gateways (with configurable spoofed source/destination MAC). This confirms the same sapp codebase backs both passive-tap (RST-only) and fully in-line (drop-capable) TSG deployments.
deployment.mode options: [mirror, inline, transparent] ... inject_pkt_mode options: [sys_route, vxlan_by_inline_device, raw_ethernet_single_gateway, raw_ethernet_multi_gateway]
Defense implications
- Circumvention protocol testing should assume a target deployment may be either passive-mirror (blocking limited to RST injection / rule pushes to a separate inline box) or fully in-line (can silently drop packets), since both are first-class, config-selectable modes of the same engine — don't infer 'inline-only' countermeasures are absent just because RST injection is observed.
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
The gdev_block sapp plugin decouples DPI classification from enforcement: once sapp identifies a stream it wants blocked, it dynamically loads /opt/MESA/lib/libc3client.so and sends a 5-tuple (src/dst IP, src/dst port, protocol) block rule with action GRULE_ACTION_ADD to an external 'c3' rule-distribution server over a licensed connection (auth_data license key from etc/gdev_block.conf), rather than dropping the packet itself. This is a distinct blocking path from sapp's own in-process RST injection, pushing enforcement out to a separate gateway device ('gdev').
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.
A 2023 MESA Lab monthly report describes the 'TF' project's active-defense work: test cases for serial ('串联') HTTP hijack/tamper and parallel ('并联') DNS race-injection ('DNS抢答'), performance tuning that scaled active-defense capacity from 3 to 5 units, converting two existing TSG boxes to active-defense mode, and rewriting the active-defense flow-control logic to no longer depend on sapp.
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.
MESA Lab internal debugging notes give the concrete sapp/MAAT config paths and JSON rule schema used for IP-based blocking: /home/mesasoft/sapp_run/TF_conf/TF_tableinfo.conf defines an IP_REGION_INFO table type (ip_plus) with a do_blacklist flag, matched against src/dst IP+port ranges.
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).