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').
libc3client_so_handle = dlopen("/opt/MESA/lib/libc3client.so", ...); grule.action = GRULE_ACTION_ADD; grule.m4.sip = sip_net; grule.m4.dip = dip_net; grule.m4.sport = sport_net; grule.m4.dport = dport_net; grule.m4.proto = protocol;
Defense implications
- Because this blocking path is a rule push to a physically separate device over a network connection (not an in-process drop), there is likely a nonzero propagation delay between sapp's classification decision and the block taking effect at the gateway — worth measuring empirically as a potential brief-window evasion opportunity for short-lived flows.
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
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.
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).