Catching a Rogue Client Red-Handed: Inside nekogram-proof-of-logging
How a lightweight Xposed module and a Python script exposed a silent data exfiltration ring hiding inside a popular open-source Telegram fork.
- Nekogram's release binaries contained malicious code that silently exfiltrated user phone numbers, bypassing public source scrutiny.
- The exploit weaponized Telegram's native Inline Query feature to disguise data theft as standard, encrypted app traffic.
- nekogram-proof-of-logging uses an Xposed module to hijack the exfiltration route at runtime, redirecting stolen data to a researcher-controlled bot.
- The incident highlights the critical gap between verifiable source code and unverified compiled binaries in the open-source ecosystem.
The Open Source Illusion
Nekogram built a reputation as a feature-rich, open-source alternative to the official Telegram client. For years, users trusted it because its source code was public and auditable on GitHub. Then, a security researcher named repinek dropped a bombshell: the public repository was clean, but the release binaries distributed to users were not.
The malicious logic was injected during the build process. This meant anyone auditing the GitHub repository would find nothing suspicious, while users downloading the compiled APK were silently compromised. To prove the theft, researchers needed more than static analysis; they needed a way to catch the app in the act.
Weaponizing the Host
The brilliance of the Nekogram exploit lay in its evasion tactics. A typical malicious app might send a suspicious HTTP POST request to an unknown server, which security analysts would quickly flag. Instead, the rogue code weaponized Telegram's own infrastructure.
It used Telegram's "Inline Query" feature—the same mechanism used to search for GIFs or YouTube videos within a chat. The app silently bundled the user's ID and phone number into a JSON payload, prefixed it with a secret key, and sent it as an inline query to a hidden developer-controlled bot (@nekonotificationbot). Because the traffic went to official Telegram servers, it looked identical to normal, encrypted app usage.
Enter the Interceptor
To definitively prove the data theft, a developer known as RomashkaTea built nekogram-proof-of-logging. This repository is a surgical forensic tool designed to hijack the hijacker. It consists of a Java-based LSPosed (Xposed) module for the Android device and a Python script for the backend.
Instead of trying to block the exfiltration, the tool lets it happen but redirects the payload. By monkey-patching the Android app at runtime, it forces the malicious code to send the stolen data to a bot controlled by the researcher.
Hooking the Ghost in the Machine
The core of the interceptor is the Xposed module, which targets the specific package tw.nekomimi.nekogram. The developer had to reverse-engineer the obfuscated APK to find the exact class responsible for the logging logic, identified as uo5$a.
XposedHelpers.findAndHookMethod("tw.nekomimi.nekogram.uo5$a", lpparam.classLoader, "a", new XC_MethodReplacement() {
@Override
protected Object replaceHookedMethod(MethodHookParam param) throws Throwable {
return "YOUR_BOT_USERNAME";
}
});
By overriding the methods that return the bot's username and ID, the module seamlessly replaces the malicious developer's credentials with the researcher's. The app is none the wiser, and the data flows into the trap.
The Python Catching Mitt
The second half of the equation is a simple Python script using the aiogram 3 framework. When the modified Nekogram app attempts to phone home, it hits this bot instead.
The script listens for incoming inline queries featuring the specific SECRET_KEY used by the rogue code. When it detects a match, it parses the JSON data and prints the stolen User ID and phone number to the console, providing undeniable, reproducible proof of the privacy violation.
The Binary vs. Source Reality
While nekogram-proof-of-logging is a highly specific diagnostic tool, its existence highlights a structural vulnerability in how we trust software. The incident proves that open source is not a guarantee of safety if the build process is opaque.
**NOTE:** source code for this data extraction logic is **missing** from the public GitHub repository, that shows the developer is injecting malicious code during the build process for releases.
Without reproducible builds—where anyone can compile the source code and verify that the resulting binary perfectly matches the official release—trust is merely an illusion. Tools like this Xposed module are necessary precisely because that trust was broken.