Yandex Apps Leak Pre-Trigger Audio Buffers, Payment Data, and Contacts via Reverse Engineering
Security researchers have reverse-engineered two Yandex Android applications and uncovered extensive surveillance capabilities that affect millions of users across Samsung, Xiaomi, Honor, and Realme devices. The findings, presented in a multi-part series, detail how Yandex Search and Yandex Browser collect audio, location, payment, and contact data with minimal user visibility.
Audio Pre-Trigger Buffer
The voice assistant Alice continuously records microphone input into a ring buffer. When the wake word is detected, the application sends the preceding audio segment to Yandex servers. The buffer size is not fixed in code but is controlled remotely through parameters such as HasPreroll, buffer-size-ms, and loggingSoundLengthBeforeTriggerMs. Default configuration uses 48000 samples at 16 kHz, equaling three seconds, yet the server can extend this window arbitrarily or disable the feature entirely.
Audio flows from AudioRecord through the circular buffer, Opus or AAC encoding, and WebSocket transmission to wss://uniproxy.alice.yandex.net. The pre-trigger content is also used for biometric voiceprint construction.
WiFi Fingerprinting and Passive Geolocation
Applications scan nearby WiFi access points, collecting BSSID, SSID, and RSSI values. These data are sent to startup.mobile.yandex.net for server-side geolocation accurate to 10-50 meters indoors. The same mechanism registers a passive location provider that intercepts coordinates obtained by any other application on the device and records cellular tower identifiers including MCC, MNC, Cell ID, and LAC/TAC.
Payment Data Handling
Before tokenization, primary account number (PAN) and CVV values are transmitted to mobpayment.yandex.net. Researchers contrast this server-side approach with client-side tokenization used by Stripe, Braintree, and Adyen, noting that any logging failure or compromise of intermediate servers could expose card details.
JavaScript Bridge and Contact Exfiltration
Twenty-one addJavascriptInterface calls expose 94 @JavascriptInterface methods. Any cross-site scripting vulnerability on a yandex.ru subdomain grants attackers direct access to native device functions. Contact data are monitored in real time via ContentObserver on ContactsContract.Contacts.CONTENT_URI. Names, phone numbers, emails, organizations, photos, and call logs are serialized with protobuf and uploaded over HTTP POST with OAuth authorization. The application also reads numbers from WhatsApp, Telegram, and Viber using MIME-type filters.
Additional Surveillance Mechanisms
Runtime.getRuntime().exec("logcat -d") attempts to capture system logs, which are AES-encrypted and exfiltrated. PackageManager.getInstalledApplications and shell commands enumerate all installed applications, including banking apps, VPN clients, and content blockers. Hardcoded DNS servers 77.88.8.8 and 77.88.8.1 bypass system, VPN, and DoH configurations. A native library, libquarkenstein_daemons.so, implements audio pipelines, process manipulation, and encryption routines.
Remote configuration flags exceeding seventy allow the server to enable map saving, force Alice activation, or delay permission requests for years. The analysis concludes that these practices operate within the bounds of the published terms of service yet rely on architecture considered outdated by modern payment and privacy standards.
Related articles
How to Detect and Remove Stolen Photos from Fake Profiles, Listings and Ads
Photos are frequently stolen from social networks, old listings, building chats and review sites, then reused in fake profiles, advertisements and rental scams. Russian law under Article 152.1 of the Civil Code protects the right to one's image, while separate copyright rules protect the photographer. Victims are advised to gather strong evidence including full-page screenshots, PDF copies and original files before contacting platforms. Search tools such as Yandex Images, Google Lens and TinEye help locate copies across multiple services. Complaints can be filed directly with site administrators on VKontakte, Odnoklassniki, Avito and Telegram, or escalated to Roskomnadzor and police when personal data or fraud is involved. Preventive steps include lowering image resolution, adding watermarks and restricting album visibility through privacy settings.
Configuration Drift Silently Breaks Multi-Hop Chains in sing-box Reality Fleet
A post-mortem analysis of a censorship circumvention network using sing-box and Reality revealed that four out of seven nodes were unreachable due to outdated allowlists, even though all monitoring reported green status. The fleet consisted of 14 endpoints across seven machines and four providers, with traffic routed in two hops where entry nodes only knew client identities and exit nodes only knew destinations. White-list rules on entry nodes permitted only five addresses instead of all required relays, causing urltest to silently discard most chains without logging failures. Canary checks, external probes, and the relay-lockdown.sh script all passed because none compared the allowlist against the full signed configuration. Two private paid nodes lacked any route section entirely, exposing them to potential abuse. The issue stemmed from configuration drift over time, with no single person maintaining an overview of the entire system. Automated fixes were implemented with safeguards to prevent fleet-wide lockouts.
Why Distributed Mesh Architectures Resist IP Blocking Better Than Centralized Servers
The article explains the fundamental limitations of single-server or small-server setups when facing IP-based censorship and DPI systems. A centralized infrastructure relies on a finite, relatively static list of addresses that can be discovered, tracked, and blocked over time. In contrast, a client-side mesh turns user devices into active transport nodes that relay traffic peer-to-peer, creating a constantly changing set of endpoints. This architectural shift transforms address blocking from a one-time list-maintenance task into an ongoing discovery problem. The design still requires an auxiliary trust and coordination layer called the backbone network, while anti-DPI techniques such as ClientHello rotation and decoy traffic protect individual connections. The approach carries real costs in battery life, bandwidth, and operational complexity on client devices.
Chrome Adds On-Device Gemini Nano While Ask Gemini Sends Page Content to Google Cloud
Google has introduced an 'AI on device' toggle in Chrome settings that enables local execution of the Gemini Nano model directly on the user's computer. Several gigabytes of Gemini Nano weights are now stored in the browser profile directory and can run on CPU or GPU for tasks such as initial analysis of suspicious pages. Despite the local model being present, the user-facing 'Ask Gemini' feature does not use it and instead routes page content, URLs, and up to ten additional tabs to Google's cloud infrastructure. The company uses two distinct systems under the Gemini name: the cloud-based Ask Gemini / Gemini in Chrome service and the on-device Gemini Nano accessed only through internal APIs or by websites and extensions. When Enhanced Protection is enabled, results from the local Safe Browsing analysis may still be transmitted to Google Safe Browsing servers. The naming and interface choices have created confusion, as users cannot directly invoke the downloaded Gemini Nano model for tasks like summarizing open pages.