The "stellar" DNS decoder plugin parses complete DNS messages including all standard resource-record types plus DNSSEC records (DS, RRSIG, NSEC, DNSKEY, NSEC3, NSEC3PARAM), and exports every answer/authority/additional RR as JSON per DNS transaction via a dedicated exporter, along with a separate CNAME-chain-only JSON exporter. This is full-content DNS resolution logging infrastructure feeding the wider "stellar" inspection pipeline; no DNS injection/poisoning/answer-rewriting logic is present in these two files, only passive parse-and-export.
yyjson_mut_val *answer=dns_resource_record_json_create(doc, answer_rr, n_answer_rr); if(answer!=NULL) { yyjson_mut_obj_add_val(doc, rr_array, "answer", answer); }
Defense implications
- Full DNS response content (not just query names) is captured and exported per session, including DNSSEC records — any DNS-over-plaintext resolution a circumvention client performs is fully logged at this vantage point, reinforcing the case for DoH/DoT/DNS-over-tunnel by default rather than as a special mode.
Cited artifacts
mesalab_git—stellar/dns_decoder.bundle:src/dns_decoder.cpp(source-code)mesalab_git—stellar/dns_decoder.bundle:src/dns_resource_record_exporter.cpp(source-code)
Provenance pointers only — no leak content is rehosted. Raw material: Enlace Hacktivista.
Related findings
Crash-dump stack traces reveal TSG's core packet-processing engine (sapp) architecture: a custom multi-threaded C engine using 'marsio' as the DPDK-style packet-I/O driver, a plugin system for protocol handlers (confirmed: plug/protocol/http/http.so), and a libdocumentanalyze component that actively decompresses gzip content and parses ZIP/document formats found inside HTTP bodies -- i.e. inspection goes beyond headers into reconstructed application content.
TSG implements heuristic tunnel-protocol detection distinguishing Teredo (IPv6-over-UDP, default port 3544) from GTP tunneling based on UDP payload inspection, used to decide 'innermost' session attribution for firewall matching.
Internal engineering docs detail MAAT's config/policy hierarchy (region/policy-unit -> group/policy-object -> compile/policy, a conjunctive-normal-form structure capped at 8 top-level groups), its Redis-backed one-master-many-replica config push ("MAAT Redis") with a rulescan fallback, and confirm MAAT runs non-distributed -- one instance per front-end traffic-scanning box -- invoked by sapp per-packet or per-stream (Maat_stream_scan_string_detail) with match-all-then-return semantics; recommended hardware is CentOS 7, 256GB RAM, 2TB disk, 48-core Xeon E5.
TSG runs two separate detection engines: a licensed third-party DPI engine for general app/protocol identification (requires per-environment authorization -- absent in a demo environment caused a detection gap), and a Geedge-built component ('glimpse_detector') specifically for VPN protocol identification (WireGuard, OpenVPN). App-ID numbering (e.g. built-in wireguard=3700) can be silently shadowed by environment-specific custom IDs, causing detection to fail even when the underlying protocol is correctly classified.
A crash/perf bug report reveals Geedge's MAAT rule engine (libmaatframe.so, using Intel Hyperscan for literal/regex matching) running with 545,441 FQDN blocking rules and 404,141 IP address blocking rules loaded in a single instance as of 2024; loading 500,000 new FQDN rules via the full Hyperscan path took ~95 minutes, addressed by an automatic fallback to a second engine ("Rulescan") above 50,000 rules.
TSG's 'APP' classification feature has named, purpose-built signatures for specific circumvention tools — the ticket explicitly configures active-client-IP tracking for the APP categories Freegate, Psiphon3, and Tor.