OSINT Anatomy / Does MAX Messenger track VPN users?
Reverse engineering says: yes
This headline isn’t clickbait. By reverse engineering the Russian MAX messenger (https://max.ru/) client, we were able to confirm our worst fears.
Reports of strange requests from the MAX messenger to Telegram and WhatsApp have begun to appear online, prompting speculation about the nature and purpose of these requests. But it’s one thing to suspect, another to know. It could be some kind of integration or a random analytics module. So, to understand it myself and share it with you, I decided to look inside the client and figure out what it does and why.
TL;DR - it contains a spy module created by the MAX developers to monitor VPN users. They made sure to make this module unblockable and added remote control.
Preparation
Since the MAX client doesn’t contain debugging information and is difficult to reverse engineer, I decided to first simply look at the network requests the client makes. For this, we’ll need:
mitmproxy. I used wireguard mode (--mode wireguard) because it allows me to intercept all traffic.
Android emulator. I used the Android Emulator that comes with Android Studio.
Upload the mitmproxy root certificate to the emulator’s system store.
WireGuard client for Android. I used the official one. When launched, mitmproxy/mitmweb displays a QR code and configuration for the WG client.
The MAX messenger itself. In my research, I used version MAX_(RS)_v.26.4.3(6552)(8.0-15.0)(arm7a,arm64-8a,x86,x86-64), which I found on 4pda.
JADX for APK analysis.
In this article, I will omit the instructions for downloading the root certificate, configuring the emulator, and connecting to WireGuard, as there are thousands of instructions for this online.
Traffic Interception
So, let’s launch mitmweb, connect the emulator, and see what requests are being sent to the internet.
Well, we see the requests we’re interested in, but for some reason, the data exchange with api.oneme.ru (the messenger’s API domain) is displayed as a TCP stream, not HTTP(S)/WebSocket.
Initially, I thought it was gRPC, since the traffic looked like a binary mess with some strings interspersed, but protoc - decode_raw showed nothing.
Protocol Analysis
Protocol analysis took me several hours, but in the end, I discovered that each message consists of a header (10 bytes) and a payload (optionally compressed). Here’s an example header.
