A Government Messenger Detects VPNs and Reports Server IPs. Here's How I Protected My Infrastructure.

Credit First

Everything in this article about how Max's HOST_REACHABILITY module works is based on the research of others. I want to acknowledge them clearly:

• "runetfreedom" — published the original deep analysis on Habr (March 5, 2026, 485K+ views, 1055+ upvotes) documenting the HOST_REACHABILITY module through JADX decompilation
• RKS Global — independently verified the findings
• RigOlit — published a detailed security analysis on GitHub (August 2025), later deleted it under pressure. The original repo was preserved in Web Archive
• Denis Yagodin — conducted RAG analysis of decompiled code (Medium), discovered the fsb class and intentionally weakened TLS cipher suites
• Scamshot Telegram channel — confirmed clipboard access and installed app list exfiltration through dynamic analysis
• Novaya Gazeta Europe — verified RigOlit's analysis with technical experts before it was removed

These researchers took real personal risk to expose this. A security researcher in Russia who publishes critical analysis of a government-backed app faces genuine consequences — and one of them already had to delete their work.

My contribution is narrow but practical: I read their research, understood the threat to my VPN infrastructure, and built a working server-side protection system in one day.

---

What is Max and Why Should VPN Operators Care?

Max (formerly VK Messenger, ru.oneme.app) is developed by VK — Russia's largest social media company, controlled by Gazprom structures. Since September 2025, it's mandatory pre-installed on every smartphone sold in Russia. 100 million registered users (Of course, this is according to VK's own data, which cannot be verified in any way).

VK is run by Vladimir Kirienko — son of the First Deputy Chief of Staff of the Presidential Administration. Max has no end-to-end encryption and is legally required to integrate with SORM (FSB wiretapping infrastructure).

I run VPN infrastructure (VLESS+Reality with DPI bypass) for approximately 165 clients in Russia. When the HOST_REACHABILITY research was published, I realized my servers were directly at risk of being identified and blocked.

---

How HOST_REACHABILITY Works (Based on Published Research)

The following is a summary of findings published by "runetfreedom" on Habr and verified by RKS Global. I'm condensing it here for VPN operators who need to understand the threat model.

Step 1: VPN Detection

The module uses Android's NetworkCapabilities.TRANSPORT_VPN API to detect active VPN connections.

Step 2: IP Identification via 6 Services

If VPN is detected, the module queries six IP detection services simultaneously — three Russian, three foreign:

Service	Location
ipv4-internet.yandex.net	Russia
ipv6-internet.yandex.net	Russia
ip.mail.ru	Russia (VK-owned)
ifconfig.me	International
api.ipify.org	Cloudflare
checkip.amazonaws.com	AWS

The mix is deliberate: if a user has split-tunneling, Russian and foreign services return different IPs, revealing the VPN server address. For personal VPN servers where inbound and outbound IPs match — the server is directly exposed and tied to the user's identity.

Step 3: Censorship Bypass Test

The module tests reachability of blocked resources (Telegram, WhatsApp) using ICMP ping and TCP:443. If blocked resources are reachable — the user is bypassing censorship.

Step 4: Data Package

Everything is sent to api.oneme.ru via a proprietary binary protocol (10-byte header + MessagePack + LZ4), mixed with regular messenger traffic: VPN flag, server IP, host reachability results, carrier, userId, sessionId.

Step 5: Blocking Pipeline

Data flows: Max → api.oneme.ru → VK → Roskomnadzor → TSPU → IP blocked.

Critical Detail

The module is controlled by a server-side flag returned per-user during authentication — enabling targeted activation for specific accounts.

For full technical details — decompiled class names, opcode structure, ASN lists — read the original research on Habr.

---

What I Built: Two-Layer Server-Side Protection

After reading the research, I needed to protect my infrastructure without requiring any changes on the client side. Here's what I implemented in one day.

Layer 1: Domain Blocking via Xray Routing

Traffic to Max domains is dropped at the Xray level before leaving the VPN server. The HOST_REACHABILITY module can collect data on the device — but it can't send it home.

Domains blocked:

Domain	Reason	False positive risk
domain:oneme.ru	Core Max API — HOST_REACHABILITY payload channel	Zero
domain:max.ru	Max web platform	Zero
full:ip.mail.ru	VK-owned IP detection service used by the module	Minimal

Domains NOT blocked (to avoid breaking other apps):

• vk.com, mail.ru — used by other VK ecosystem apps
• ifconfig.me, api.ipify.org, yandex.net — legitimate services used by thousands of apps

Xray configuration:

{
  "outbounds": [
    { "protocol": "freedom", "tag": "direct" },
    { 
      "protocol": "blackhole", 
      "settings": { "response": { "type": "http" } }, 
      "tag": "block-max" 
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": [
          "domain:oneme.ru",
          "full:ip.mail.ru",
          "domain:max.ru"
        ],
        "outboundTag": "block-max"
      }
    ]
  }
}

Critical: Sniffing must be enabled on every inbound — without it, Xray can't see the domain in TLS ClientHello:

"sniffing": {
  "enabled": true,
  "destOverride": ["http", "tls"]
}

Layer 2: Real-Time Monitoring + Telegram Alerts

A Python daemon watches Xray access logs and sends instant Telegram alerts when a client's device tries to contact Max domains:

⚠️ MAX DETECTED
Client: [CLIENT_NAME]
Domain: api.oneme.ru:443
Server: xray-direct
Time: 2026-03-17 12:00:00
Traffic to Max blocked at Xray level.

Deduplication: one alert per client per hour. Runs as a systemd service.

Deployment

Applied to two Xray services:

• VLESS+Reality (direct connection)
• VLESS+WebSocket via Cloudflare

All ~165 clients protected automatically. Zero client-side changes. Hiddify, v2rayNG, Streisand continue working normally.

---

Limitations

1. DoH / Hardcoded IPs: If Max switches to DNS-over-HTTPS or hardcoded IPs, domain-based blocking fails. Fallback plan: iptables DROP for VK IP ranges (AS47541, AS47764).

2. Split-tunneling: If a user only routes foreign traffic through VPN, Max reaches api.oneme.ru directly. Server-side protection can't help. Recommendation: full tunnel.

3. Module updates: When Max changes domains or protocols, the blocklist needs updating. Monitoring helps detect new patterns.

4. The only guarantee: Don't install Max on a device that connects to VPN.

---

The Bigger Picture

After the Habr publication went viral, VK released an update removing the Telegram/WhatsApp checks — but the module code was not removed from the APK. It's dormant, waiting.

The researchers who exposed this took real risk. One deleted their work under pressure. The least we can do as infrastructure operators is take their findings seriously and build actual protections.

If you operate VPN infrastructure with users in Russia — the Xray configuration above takes 10 minutes to deploy and protects all your clients immediately.

---

References

• Original research by "runetfreedom" — Habr, March 5, 2026
• RKS Global — independent verification
• RigOlit — GitHub analysis (August 2025, deleted, preserved in Web Archive)
• Denis Yagodin — RAG analysis of decompiled code (Medium)
• Scamshot — dynamic analysis (Telegram channel)
• Novaya Gazeta Europe — investigative reporting
• Human Rights Watch, Reporters Without Borders, Access Now — policy analysis

---

I'm Creatman — I build solutions for problems I encounter. When researchers expose a threat, I build the defense.

GitHub: github.com/CreatmanCEO | Portfolio: creatman.site | LinkedIn: linkedin.com/in/creatman