Яндекс - 69,9% поискового рынка РФ, 110+ млн пользователей в месяц, десятки сервисов: поиск, браузер, карты, маркет, такси, музыка, почта, диск, алиса, еда, погода, кинопоиск, плюс... Если у вас андроид - Яндекс.Поиск и Яндекс.Браузер почти наверняка стоят с завода. На Samsung, Xiaomi, Honor, Realme...

Мы взяли два APK Яндекса и отреверсили их.

Там прям плохо. Настолько, что MAX и РУСТОР на их фоне выглядит как детский сад.

В одну статью все это не влезает, придется разделить на несколько, а конкретно на 3.

Кстати подарочек - нейросеть от яндекса для т9 в виде GGUF.

• Аудио-претриггер буфер - микрофон пишет звук до того как вы сказали Алиса, и этот кусок звука улетает на сервер. При этом размер окна управляется с сервера - может быть 3 секунды, а может и больше.

• WiFi-сканирование - Яндекс сканирует все точки вокруг, собирает BSSID/SSID/RSSI и шлёт на свой сервер для геолокации.

• Платёжные данные (PAN + CVV) до токенизации - до того как карта затокенизируется, PAN и CVV уходят на mobpayment.yandex.net.

• 94 JavaScript Bridge метода - 17 addJavascriptInterface() мостов. XSS на любом поддомене yandex.ru = компрометация устройства.

• Адресная книга в реальном времени - ContentObserver на всё устройство, любые изменения контактов улетают на сервер.

• Logcat эксфильтрация с AES шифрованием - костыльный код.

• Remote config (70+ флагов) - сервер может включить сохранение карт, форсировать Алису, отложить запрос разрешений на 3 года.

Голосовой помощник Алиса работает так: микрофон пишет звук постоянно, но не отправляет его пока не услышит «Алиса». Когда вы говорите «Алиса» - вы уже сказали это слово. То что было до слова «Алиса» - попадает в буфер.

И Яндекс этот буфер забирает на свои сервера.

Называется pre-trigger buffer. Кольцевой буфер куда микрофон пишет звук непрерывно. Когда wake word срабатывает - приложение вычитывает буфер и отправляет всё что было ДО ключевого слова вместе с командой.

Казалось бы ну ладно, что с того, может быть это для дебага или серверной валидации, только вот почему то ( а почему нам ответят в коментариях разработчики яндекса на что я очень надеюсь ) размер этого окна не фиксирован. Он управляется с сервера через параметры HasPreroll, buffer-size-ms, loggingSoundLengthBeforeTriggerMs. по умолчанию оно стоит 3 секунды, если бы так и было я бы не добваил пункт в статью... только вот его можно регулировать с сервера, сервер может выставить любое. Или вообще выключить pre-trigger.

Смотрим utw.java:42 - там конфигурация буфера Алисы. 48000 семплов при 16kHz = 3 секунды. Это дефолт.

В BaseAudioSource.java:303 создаётся объект захвата с микрофона. audioSource = 1 = MIC, 16kHz, моно, 16 бит.

BaseAudioSource.java:345-367. Работает пока сервис жив. Читает пачки звука, пробрасывает подписчикам.

Шаг 1: Микрофон -> AudioRecord (PCM 16kHz)
Шаг 2: Кольцевой буфер 48000 сэмплов (pre-trigger)
Шаг 3: Wake word -> PhraseSpotter триггер
Шаг 4: Opus/AAC кодирование
Шаг 5: WebSocket.sendData() -> wss://uniproxy.alice.yandex.net/uni.ws
Шаг 6: Сервер Яндекса (расшифровка + биометрия + хранение)

Разумеется без pre-trigger буфера современный голосовой помощник не может нормально работать - ему нужно слышать контекст до команды. Но моя претензия не к этому, а вот к чему:

1. Размер буфера управляется с сервера - а не фиксирован кодом. Сервер Яндекса в любой момент может выставить 30 секунд, минуту, сколько угодно.

2. Pre-trigger включает биометрию - голосовой отпечаток строится в том числе по pre-trigger контенту.

3. Пользователю не сообщается что pre-trigger активен, какого он размера, и что запись уже идёт.

4. Наверное вы даже не знали что pre-trigger там вообще существует.

Яндекс сканирует все WiFi точки рядом, собирает MAC роутера, имя сети, силу сигнала и отправляет на сервер. У Яндекса есть база расположения WiFi точек - зная какие рядом, вычисляет ваши координаты с точностью до 10-50 метров. Работает внутри зданий, где GPS не ловит. Заходите в торговый центр - Яндекс знает в какой вы магазин зашли.

BuildConfig.java - основной endpoint: https://startup.mobile.yandex.net. Резервные: startup-mobile.ap.yandex-net.ru, startup.mobile.webvisor.com.

G2.java - SynchronizedDataCache с именем "wifi". Данные кэшируются и отправляются пачками.

В пользовательском соглашении (ToS) всё это официально прописано - мол, это нужно для обучения их алгоритмов, ( на деле для рекламы ). Да и не стоит забвать Google занимается ровно тем же самым. Становится ли от этого легче? Вообще ни капельки.

Решать тут вам, но я думаю у вас есть право знать что делает приложение на вашем телефоне ( не стоит забывать что ваша геолокация моментально уходит сторонним компаниям, а базы данных сливают до сих пор ) .

Когда вы вводите карту в приложении Яндекса, PAN (номер карты) и CVV летят на сервер до токенизации. Но не волнуйтесь, это абсолютно легально и соответствует PCI DSS. Яндекс же сертифицирован, все под контролем - примерно так же, как в 2023 году под полным контролем находился их исходный код до того, как утек на торренты.

Проблема в том что весь цивилизованный мир уже давно использует архитектуру на порядок элегантнее и безопаснее:

• Client-side токенизация (iFrames / Hosted Fields, как у Stripe Elements или Braintree): Данные карты вообще не касаются ваших серверов. Поля ввода физически изолированы на стороне провайдера, приложение видит только готовый токен. Поверхность атаки на вашей стороне = ноль. Радиус поражения при взломе бэкенда = ноль.

• Device-level токенизация (Apple Pay / Google Pay / EMVCo): Пользователь вообще не светит картой. Девайс генерирует одноразовую криптограмму на уровне железа (Secure Enclave). Даже если хакер перехватит этот токен по пути, он будет абсолютно бесполезен для любых других транзакций.

• И, для сравнения, Server-side токенизация (как у Яндекса): Данные карты послушно летят через твой бэкенд, API-гейтвей, балансировщики, проходят через SIEM, ELK-stack и вообще через всё, что может в один прекрасный момент упасть с ошибкой и радостно плюнуть {pan, cvn} в файлик с логами.

• Логи. Сервер упал с 500-й ошибкой ровно в момент передачи карты? Поздравляю, {pan: "4276..., cvn: "123"} уже в логе. А лог читают 150 человек. Откуда мы это знаем? из 7e0ac90b489baee8a823381792ec67d465488fef

• Промежуточные сервера. startup.mobile.yandex.net - это не крепость, это обычный бэкенд с кучей эндпоинтов, аналитикой, экспериментами.

• Инсайдер. Охранять один микросервис легко. Охранять всю инфраструктуру приложения, через которую транзитом проходят PAN+CVV - нужно, чтобы 100500 разработчиков, devops'ов и тестировщиков были в PCI DSS scope.

Юридически легально. Есть сертификат, есть изолированный CDE-контур.

Но архитектурно это код образца 2012 года. Stripe, Braintree, Adyen уже 10 лет назад доказали, что можно сделать так, чтобы сервер приложения вообще не видел карту.

Если mobpayment.yandex.net взломают - всё, данные утекли. Яндекс взламывали. VK взламывали. АНБ взламывали

За это их уже забуллили все, но грех упустить

Приложение проверяет наличие интерфейса tun0 (стандартное имя для VPN). Если найден - блокирует авторизацию.

Думаю не секрет что Яндекс заставляет отключать VPN и светить реальный IP, потому что полностью прогнулся под требования Роскомнадзора и Кремля по тотальной слежке и цензуре.

Приложение использует 77.88.8.8 и 77.88.8.1 в обход системного DNS, VPN DNS, DoH и Tor. Это DNS Яндекса. Даже если вы настроили Cloudflare DoH или используете Tor - Яндекс делает запросы к своим DNS напрямую.

Проще говоря, они видят абсолютно все домены куда вы ходите, и есть огромная вероятность, что вся эта «история браузинга» по первому требованию улетает прямо в нужные руки - ну а выводы делайте сами.

Самое сладкое разработчики спрятали в native-библиотеке libquarkenstein_daemons.so.

Внутри зашито всё: пайплайны записи аудио с микрофона (с прямой отправкой на сервера), манипуляции с процессами в обход security-модели Android, нативная геолокация и шифрование. Это полноценный движок слежки, заботливо упакованный в один тяжело читаемый файл (в котором, кстати, по классике забыли затереть внутренние debug-пути сборки, денис опять ты?) вообщем это я так, чтобы вы не забывали о том что выйдет 2/3 часть, новости есть тут.

21 addJavascriptInterface() мостов. 94 @JavascriptInterface метода. Файл assets/api.js - 30+ функций.

Любая XSS-уязвимость на поддоменах yandex.ru - это мгновенный билет к контролю над вашим устройством. Злоумышленникам нет смысла пробивать лбом неприступные главные серверы с их WAF и круглосуточным мониторингом. Достаточно найти одну незапертую форточку на заднем дворе экосистемы.

XSS - неизбежнен:

• Кладбище поддоменов: У IT-гигантов их сотни, если не тысячи. От заброшенных промо-акций пятилетней давности до дев-песочниц, где выполнение пользовательского кода - это вообще основная функция.

• Человеческий фактор: В инфраструктуре такого колоссального размера забытого, устаревшего или криво написанного кода невозможно избежать ( без формальной верификации ) . Уязвимый эндпоинт, позволяющий исполнить произвольный веб-скрипт, появится со стопроцентной вероятностью ( или уже тихо существует и ждет своего часа, без намека ).

• Слепой Фейсконтроль" Как только хакерский скрипт запускается на таком уязвимом поддомене, мобильное приложение видит знакомое окончание .yandex.ru и после чего радостно распахивает перед ним все 94 JS-моста, пропуская веб-пейлоад прямиком к нативным функциям.

Приложение читает полную адресную книгу (имена, телефоны, email, почтовые адреса, организации, фото), а также журнал звонков. Установлен ContentObserver на ContactsContract.Contacts.CONTENT_URI - любое добавление, удаление или изменение контакта вызывает перечитывание данных. Контактные данные сериализуются через protobuf и отправляются на сервер Яндекса через HTTP POST (с OAuth-авторизацией).
VoIP / мессенджеры

Читает не только обычные телефоны, но и номера из WhatsApp, Telegram, Viber через фильтр MIME-типов phone_v2, viber, telegram, whatsapp.

павла Дурова причислили в РФ к "террористам и экстремистам"

Отправка на сервер

Ссобирает все контактные данные в UploadContactsRequest - протобаф-структуру с полями:

• ContactInfo (ID контакта, id, lookup, displayname, account_type, account_name, times_contacted, timestamps)

• PhoneInfo (номер, тип, приложение-источник)

• LookupInfo (lookup-ключи)

Затем данные сериализуются через ae10.b(serializer, request) и отправляются HTTP POST на сервер Яндекса с заголовком Authorization: OAuth <token>.

Приложение регистрирует пассивного провайдера геолокации - это позволяет перехватывать координаты, полученные другими приложениями на устройстве. Дополнительно собираются данные о сотовых вышках: MCC, MNC, Cell ID, LAC/TAC, что позволяет триангулировать положение устройства с точностью до 100-500 метров даже в помещениях. Пассивный провайдер доставляет обновления от любого приложения, уже имеющего координаты.

Под капотом дёргается Runtime.getRuntime().exec("logcat -d") - попытка снять полный дамп системных логов. Дальше всё это пакуется, шифруется AES и летит к ним на сервер.

В теории, Logcat - это проходной двор, куда пишут логи вообще все приложухи на телефоне. То есть Яндекс должен пылесосить логи вашего банка, VPN, секретных чатов, историю URL-ов и краши

ситуация тут прям как с RuStore, повторяться не буду. Звучит страшно, но по факту это так только для юзеров старых ОС (ну или если вы сидите с кастомным рутом и выдаете права направо и налево).

Современный Android давно прикрыл эту лавочку на уровне песочницы: без системных привилегий (READ_LOGS) приложение может читать только свои собственные логи. Так что на актуальных прошивках Яндекс через этот логкат успешно соберет данные только о том, как забаговал сам Яндекс.

Если бы в Яндексе работали тру-профи, они бы изначально на уровне кода ограничили сбор логов только своим приложением. А попытка тянуть logcat -d целиком, в расчете на то, что «ОС сама обрежет лишнее» - это просто наглядный показатель того, как там пишется архитектура

Приложение собирает полный список установленных пакетов на устройстве через два механизма: PackageManager.getInstalledApplications() и, как fallback, Runtime.getRuntime().exec("pm list packages"). Список приложений позволяет идентифицировать банки, VPN, мессенджеры, магазины, антивирусы и другие приложения пользователя.

Основной метод: getInstalledApplications()

Собирает все packageName установленных приложений.

Fallback: shell-команда

Резервный механизм при TransactionTooLargeException или DeadObjectException:

Парсит вывод package:com.example.app, извлекая имена пакетов.

Детектор контент-блокеров

После сбора всех пакетов v000.x() проверяет каждый на наличие meta-data:

• "com.samsung.android.sbrowser.contentBlocker.interfaceVersion" - если "API_1.0", проверяется ContentProvider

• Для подходящих приложений собирается signatureHash и displayLabel

• Результат - список ej40{packageName, displayLabel, signatureHash}

СБП ( платежи, все вроде легально )

использует getInstalledApplications() для поиска установленных банковских приложений. Сверяет packageName со списком известных банков, результат показывается в UI оплаты.

VK Push SDK

При отсутствии master-host приложения шлёт аналитический ивент "vkcm_sdk_client_no_master_host_found" с параметром "installed_apps", содержащим список packageName всех установленных приложений. Этот ивент уходит на серверы аналитики VK.

CLID-детекция

Сохраняется в SharedPreferences и используется для аналитики/аттрибуции.

«Но покроет ли это ограничения Android 11+, где Google ввёл Package Visibility и запретил приложениям просто так видеть чужие пакеты?»

Ещё как покроет! Разработчики Яндекса не дураки, чтобы просить у Google Play опасное разрешение QUERY_ALL_PACKAGES (за которое их выкинули бы из стора). Они поступили технически изящнее: захардкодили гигантский список целевых приложений прямо в тег <queries> своего AndroidManifest.xml.

В Android 11+ если пакет явно объявлен в <queries>, приложение имеет полное официальное право проверять его наличие через PackageManager.

Что именно Яндекс внес в свой список «разрешённого наблюдения»:

1. Вся экосистема Яндекса и дочек: Такси, Карты, Лавка, Диск, Почта, Еда, Маркет, Дзен, Плюс, Яндекс Банк, Кинопоиск, Драйв, Мессенджер.

2. Абсолютно ВСЕ конкурентные браузеры: Google Chrome (включая Beta/Dev/Canary), Mozilla Firefox, Opera (Mini/Beta/Touch), DuckDuckGo, Vivaldi, Samsung Internet, UC Browser, Via, Mi Browser.

3. Все популярные мессенджеры и соцсети: Telegram, WhatsApp (+ Business), Viber, VKontakte, Instagram, Twitter, Reddit, Facebook (+ Lite/Messenger), ICQ, OK.ru.

4. Все почтовые клиенты: Gmail (+ Lite), Mail.ru, Outlook, Spark, MyMail, Yahoo Mail, Samsung Email, BlueMail.

5. Измерители аудитории и трекеры: Mediascope AppMeter (com.cifrasoft.mpm.medфiascope.appmeter) - главная российская система панели аудитории и телеизмерений.

Пытаясь втихую обойти приватность Android 11+, Яндекс сам же выдал себя: захардкодив в <queries> сторонние браузеры, мессенджеры и Mediascope, они открыто выложили доказанный факт целенаправленного шпионажа за пользователем - были бы там только банки и сами Yandex-приложения, вопросов бы не было.

Приложение управляется с сервера. Сервер может включить сохранение карт, форсировать Алису, отложить запрос разрешений на 3 года, включить pre-trigger на полный буфер, отключить валидацию TLS.

alice_proxy, alice_reader, CommittedOriginTracking_fix, delay_notification_first_permission_request, default_search_promo_on_serp, geo_settings, mobile_ads_sdk, morda_feed_ads, send_bidder_token_to_morda, features_onboarding, tab_folders, morda_force_alice, video_summarization, video_tutorial, common_mobile_menu, manage_cpu_affinity, flex_ntp, morda_modes, ssdk_searchapp_buttons_theme, ssdk_theme, alice_solver, turkish_redesign, force_show_neuro_entry_points, video_translation, video_translation_alice_shortcut, alice_videotranslation, video_translation_international, video_translation_target_kz, video_translation_direct_upload, yandex_href_translate, alice, website_reviews, feature_suggest, div_sovetnik, trust_cards_autofill, save_trust_cards_to_yandex, smart_camera, alice_language, alice_pro, image_search, book_reader, readability_ajax_delay, new_default_popup, turbo_apps, morda_update_on_start, tweak_searchapp_controls, search_2_bro, thumbnail_database, searchapp_user_agent, voice_search_2024, facebook_sdk, books_div_banner, modern_voice_search, voice_search, summarization, div_stories_tutorial, external_applinks, sections_v2, omnibox_visibility, ssdk_serp_line, ai_chat_alice, alice_v2, custom_nav_bar, context_search_serp, safe_browsing_delay_verify_local_database, transsion_widget_promo, xiaomi_widget_promo, widget_promo_environment, image_translator, searchapp_profile_login

Remote config - это стандартная технология. Но набор флагов говорит сам за себя. Это не A/B-тестирование кнопок. Это удалённое управление механизмами слежки и разрешениями. Сервер Яндекса может раздать разный набор слежки разным пользователям - одним 3 секунды pre-trigger, другим 30, третьим off.

Давайте подведём цифры того, что нам удалось раскопать ( многое в статью не влезло, но я подведу итоги того что будет в 2/3 частях ) :

• 60+ механизмов слежки (из них 11 критических и 38 высокого риска).

• 387+ сетевых эндпоинтов, 1500+ JNI-точек, 94 JavaScript Bridge API, 587 доменов.

Яндекс собирает абсолютно всё:

1. Звук вокруг вас - ещё до того, как вы произнесли «Алиса» (через pre-trigger буфер).

2. Звонки и контакты - через ContentObserver адресной книги.

3. Локацию - через сканирование Wi-Fi сетей, GPS и триангуляцию по сотовым вышкам.

4. Окружение - полный список ваших приложений (банки, VPN, мессенджеры).

5. Платежи - данные карт (PAN/CVV) до токенизации.

И самое ироничное: вы за это ещё и платите, покупая подписку «Яндекс Плюс». Оплачивая из своего кармана тотальную слежку за собой же.

Яндекс, если вы это читаете (а вы точно это читаете) - я провёл для вас
бесплатный публичный аудит! На одну только лицензию IDA для
реверс-инжиниринга я потратил $1 000 из своего кармана. Так что искренне жду от
вас занос за выявление архитектурных дыр!

Это была только первая часть из масштабного цикла из 3 статей про экосистему
Яндекса. Впереди ещё много интересного.

Обязательно подписывайтесь на мой Telegram-канал openlibrecommunity - именно
благодаря поддержке сообщества этот материал увидeл свет.

Проголосовали 70 пользователей. Воздержались 15 пользователей.