Geedge's VPN-app signature-extraction methodology (M22/Myanmar project, run weekly per-app) is primarily IP-address-list-based rather than protocol-fingerprint-based: automated scripts enumerate each VPN app's server IPs (extraction runs cited pulling 7-200+ IPs per test cycle for apps like BigMama VPN, Giti VPN, JumpJumpVPN), which are then pushed as blocking signatures and validated against a live test environment plus a separate false-positive ('误封') test environment before deployment.
编写自动化脚本，提取serverIP...2024/08/12在44.29环境中测试发现有CT节点，新增20个节点IP后，阻断成功 [wrote an automated script to extract server IPs ... found an undetected node in the test environment, blocking succeeded after adding 20 new node IPs]
Defense implications
- IP-list-based VPN blocking is inherently laggy against server rotation — a circumvention tool that rotates server IPs faster than Geedge's weekly extraction/patch cadence, or that fronts through shared/CDN IPs Geedge won't blanket-block, has a structural advantage over this specific detection method.
Related findings
Under the internal "M22" project (deployment site "YGN-MYTEL" confirms this is Myanmar, at the Mytel carrier), Geedge runs a continuous, individually-tracked signature-extraction pipeline against named commercial VPN apps (Super Unlimited VPN, NotVPN, Avira Phantom, Bitdefender VPN, Thunder VPN, Panda VPN, Mouse VPN, HaloVPN, GoFly VPN, Kiwi/Kuto/Greennet/Gulf Super/Hatunnel+ VPN, and a customer-provided list of 141 more): active probing of app refresh/connect behavior (including automated UI-driving scripts) extracts server IP/FQDN lists, separately for free vs. paid tiers and Android vs. iOS, which are then loaded as blocklist objects and validated against a false-positive ("CT"/穿透) test pass in a separate demo environment before deployment.
Geedge runs an ongoing, systematically-numbered VPN/app fingerprinting program for the M22 (Myanmar) deployment — a tracked "M22-VPN List" with 188+ sequentially numbered entries, and a separate non-VPN app catalog past entry 550 — with weekly-cadence re-testing (e.g. Quark VPN patches issued repeatedly through late 2024 as the target app's own infrastructure changed).
A security policy literally named "Lantern_vpn_test" was configured and actively enforced at the M22 (Myanmar) TSG deployment as of June 27 2024 — Lantern had a live, named blocking policy in production, not just a backlog research item.
Multi-week TSG engineering investigation of iTOP VPN (requested by an Ethiopia deployment, cross-tested in a Myanmar environment) found blocking only takes effect for VPN sessions established AFTER a detection policy is pushed; a VPN already connected before the policy loads is never blocked or logged, regardless of signature type (SNI or server-IP).
Geedge ran an ongoing, systematically-numbered program extracting detection fingerprints for individual VPN and non-VPN apps for the Myanmar (M22) deployment, tracked with weekly-cadence per-app tickets; methodology combined packet capture, DNS/domain analysis, and fixed-port protocol identification, validated in a live test environment before shipping, with results tracked as "CT" (successfully blocked) or not.
Sustained, systematic feature-extraction campaign against ~20+ named commercial VPN apps (Secure VPN, VPN Turkey-series regional apps, Cloudbric, Thunder VPN, Quark VPN, TowerVPN, SymlexVPN, Tenta, tigerVPN, TLS Tunnel, Tomato VPN, VPNlat, VPNMonster, VPNPro, WhiteHatVPN, WolfVPN, and an ISAKMP/IKE-based and an OpenVPN-based app) for the Myanmar (M22) deployment, 2024. Methodology: reverse-engineer app API via Fiddler/mitm to enumerate server IP/FQDN lists where possible; fall back to Wireshark protocol-signature ID (e.g. recognizing raw ISAKMP port 500 or OpenVPN ports 1194/80) when APIs are unavailable; automated 'dial testing' (自动化拨测) continuously discovers new server IPs; ongoing re-verification explicitly tracks 'CT' (circumvention/breakthrough) to catch when a blocked app resumes working and needs a fingerprint update.