A Habra user Slava_B tested the desktop client of the MAX messenger on Windows to check whether it could recognize or bypass a VPN when traffic routing occurred at the router level rather than inside the operating system.
The experiment took place on 8 September 2026. A Windows computer was connected to a Keenetic router configured to send Russian resources directly while routing selected foreign connections through an OpenConnect tunnel to a European VPS. No VPN client, virtual adapter, or special routes existed inside Windows itself.
Researchers monitored the client using Process Monitor, Wireshark, and TCPView, while traffic on the remote server was captured with tcpdump. The application launched two processes, MAX.exe and MAX-service.exe, which communicated over a local port.
The client established connections to MAX/ONEME infrastructure, the AppTracer service, and systems used for calls. It repeatedly read the MachineGuid identifier, computer name, proxy and PAC settings, its own device IDs, and information about microphones and cameras.
These reads may serve legitimate purposes such as diagnostics, anti-fraud measures, corporate proxy support, and call functionality. Importantly, no connections from MAX appeared on the VPN interface of the VPS, and the application did not contact external IP detection services, Telegram, or WhatsApp.
The researcher stressed that TLS traffic content was not decrypted, so it remains unproven whether identifiers were actually sent to servers. The findings apply only to the tested router-based configuration and do not cover scenarios where a VPN client runs directly inside Windows.
