Как провести аудит приватности приложений на Android через ADB: права, трекеры и сетевые эндпоинты
TL;DR
- Время выполнения: 40–60 минут на одно приложение
- Уровень сложности: Intermediate
- Понадобится: ПК (Windows/macOS/Linux), Android platform-tools (
adb), тестовое Android-устройство с включённой отладкой по USB, прокси-перехватчик mitmproxy, USB-кабель, ~1 ГБ свободного места под выгрузку APK и логи. Версии platform-tools и mitmproxy сверьте с документацией — здесь они не фиксируются.
Требования и подготовка
- ADB (Android Debug Bridge) — утилита, которая даёт ПК доступ к служебным командам телефона. Установите platform-tools и проверьте, что
adbесть в PATH. - Режим разработчика на телефоне. Настройки → О телефоне → 7 тапов по «Номер сборки» → Настройки → Система → Для разработчиков → включить «Отладка по USB».
- Тестовое устройство или тестовый профиль. Аудит ставит HTTP-прокси глобально — на рабочем телефоне это ломает часть приложений.
- mitmproxy на ПК — прокси, который показывает HTTPS-запросы приложения в открытом виде. Нужен для шага 2.
- Свободное место ~1 ГБ — для выгруженного APK и файлов логов.
- Пакет-цель. Узнайте package id приложения заранее: он понадобится во всех командах. Пример:
com.example.app.
Если adb ещё не связан с телефоном, сначала пройдите подключение по инструкции Как подключить Android к Windows через ADB: команды, список устройств и ошибки — в этом гайде предполагается, что adb devices уже показывает устройство в статусе device.
Проверка готовности:
adb devices
adb shell getprop ro.build.version.releaseОжидаемый вывод: строка <серийный-номер> device (именно device, не unauthorized) и номер версии Android, например 14.
Шаг 1. Инвентаризация: пакет, версия, разрешения
Что сделать: собрать базовый паспорт приложения — версию, targetSdk и полный список запрошенных разрешений.
Зачем: без базовой линии вы не отличите «приложение просит доступ к контактам» от «приложение уже получило его и пользуется». dumpsys package — это дамп внутренней базы пакетного менеджера, он показывает и запрошенные, и фактически выданные разрешения.
adb shell pm list packages -3 -f | grep -i exampleОжидаемый вывод — строка вида package:/data/app/~~xxxx==/com.example.app-yyyy==/base.apk=com.example.app. Флаг -3 оставляет только сторонние (не системные) приложения, -f показывает путь к APK.
adb shell dumpsys package com.example.app | grep -A 100 "requested permissions"На Windows без Git Bash то же самое делается через findstr:
adb shell dumpsys package com.example.app | findstr /C:"requested permissions" /C:"install permissions" /C:"targetSdk"Ожидаемый вывод: блок requested permissions: со строками вида android.permission.CAMERA, android.permission.ACCESS_FINE_LOCATION, android.permission.READ_CONTACTS и блок install permissions:, где у части строк стоит granted=true.
Пример: приложение-фонарик с targetSdk=33, у которого в requested permissions есть ACCESS_FINE_LOCATION и READ_CONTACTS, — уже повод для вопросов: фонарику эти данные не нужны.
Дальше снимите «операционные разрешения» (appops) — отдельную подсистему Android, которая решает, разрешён ли конкретный тип доступа прямо сейчас:
adb shell cmd appops get com.example.appОжидаемый вывод — список вида CAMERA: allow, LOCATION: ignore, READ_CONTACTS: deny. Значение ignore/deny при granted=true в dumpsys — нормальная ситуация: разрешение выдано, но операционно заблокировано.
Как проверить: сохраните оба вывода в файлы и убедитесь, что список пакетов содержит именно ваш package id, а не похожий (com.example.app vs com.example.app.lite).
mkdir -p audit && adb shell dumpsys package com.example.app > audit/package.txt && adb shell cmd appops get com.example.app > audit/appops.txt && wc -l audit/*.txtШаг 2. Трекеры и сетевые эндпоинты
Что сделать: найти в приложении сторонние SDK-трекеры (аналитика, реклама, краш-репортинг) и зафиксировать домены, к которым оно обращается.
Зачем: разрешения показывают потенциал, а трекеры и трафик — фактическое поведение. Трекер — это встроенная библиотека разработчика, которая собирает события и отправляет их на свой сервер.
2.1. Выгрузите APK и посмотрите, какие SDK внутри.
adb shell pm path com.example.app
adb pull /data/app/~~xxxx==/com.example.app-yyyy==/base.apk audit/base.apk
unzip -l audit/base.apk | grep -iE "com/facebook|com/google/android/gms/analytics|com/appsflyer|com/adjust/sdk|com/onesignal"Ожидаемый вывод — пути классов, например classes2.dex внутри не покажет имена, поэтому надёжнее искать по строкам:
unzip -p audit/base.apk classes.dex | strings | grep -iE "appsflyer|adjust|onesignal|firebase-analytics"Если строки нашлись — соответствующий SDK в приложении есть. Если вывод пустой, проверьте остальные dex-файлы: unzip -l audit/base.apk | grep "classes.*dex".
2.2. Включите HTTP-прокси и перехват.
Запустите mitmproxy на ПК (порт по умолчанию 8080) и направьте на него трафик телефона:
adb shell settings put global http_proxy <ip-ПК>:8080<ip-ПК> — локальный адрес компьютера в той же Wi-Fi-сети, например 192.168.1.10. Почему это работает: Android применяет системный прокси ко всем приложениям, которые используют стандартный сетевой стек.
Затем откройте приложение и пройдите типовой сценарий: запуск, регистрация, переход по 3–4 экранам, сворачивание. В окне mitmproxy появятся запросы вида GET https://api.example.com/v1/config.
2.3. Продублируйте проверку через logcat.
adb logcat -c
adb logcat | grep -iE "http://|https://|SSLHandshake|UnknownHost"adb logcat -c очищает буфер, чтобы в отчёт попали только события после запуска приложения. Ожидаемый вывод — строки с доменами или сетевыми ошибками; отсутствие строк тоже результат: приложение может не логировать сеть.
Пример: в перехвате видно POST https://api.example.com/collect сразу после старта, до нажатия любых кнопок, — это телеметрия запуска. В отчёте фиксируйте: домен, метод, время относительно запуска, отправляемые поля (без значений).
Как проверить: в mitmproxy в списке потоков есть хотя бы один запрос от приложения, а adb shell settings get global http_proxy возвращает заданный адрес.
Шаг 3. Проверка результата и отчёт
Что сделать: свести данные в таблицу, отключить прокси и убедиться, что настройки устройства вернулись в исходное состояние.
Зачем: аудит без отчёта и без отката изменений бесполезен: следующий запуск приложения будет вести себя иначе, а коллега не сможет повторить замер.
Сведите результаты в таблицу:
| Что проверяли | Команда | Что нашли у `com.example.app` |
|---|---|---|
| Запрошенные разрешения | `dumpsys package` | CAMERA, ACCESS_FINE_LOCATION |
| Операционные разрешения | `cmd appops get` | LOCATION: ignore |
| Сторонние SDK | `strings` по APK | найден рекламный SDK |
| Сетевые эндпоинты | mitmproxy | `api.example.com`, `cdn.example.com` |
Как проверить: выполните откат и убедитесь, что прокси снят.
adb shell settings put global http_proxy :0
adb shell settings get global http_proxyОжидаемый вывод: null — прокси отключён. Если остался адрес, повторите команду: пока прокси активен, приложения без интернета будут вести себя некорректно.
Чек-лист приёмки аудита:
- [ ] Вывод
dumpsys packageсохранён в файл и содержитrequested permissions - [ ] Вывод
cmd appops getсохранён и сопоставлен с разрешениями - [ ] Список сторонних SDK зафиксирован с указанием, в каком dex найден
- [ ] Для каждого домена указан метод и триггер (запуск, экран, кнопка)
- [ ] Прокси отключён,
http_proxyравенnull - [ ] Отчёт не содержит персональных данных из перехваченных запросов
Пример готовой строки отчёта: api.example.com — POST /collect — сразу после cold start — поля: app_version, device_model, event.
Возможные проблемы и решения
Проблема. Устройство видно, но команды не выполняются.
- Ошибка:
error: device unauthorized. Please check the confirmation dialog on your device. - Причина: на телефоне не подтверждён RSA-ключ отладки, либо подтверждение было отозвано.
- Решение: разблокируйте телефон, нажмите «Разрешить» в диалоге (включите «Всегда разрешать с этого компьютера»), затем перезапустите сервер:
adb kill-server && adb start-server && adb devicesПроблема. mitmproxy не видит HTTPS-запросы приложения.
- Ошибка в mitmproxy или в логах приложения:
SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found. - Причина: certificate pinning — приложение доверяет только своему вшитому сертификату и отвергает подмену от прокси.
- Решение: проверьте остальной трафик (часто часть доменов не запинена) и зафиксируйте в отчёте сам факт пиннинга как положительную практику:
adb logcat | grep -i "Trust anchor"Обход пиннинга требует модификации APK или тестовой сборки — это отдельная задача и для продакшен-сборки не выполняется.
Проблема. Команда с grep не работает.
- Ошибка:
'grep' is not recognized as an internal or external command, operable program or batch file. - Причина: команда запущена в
cmd.exe, гдеgrepотсутствует. - Решение: используйте
findstrили запустите Git Bash:
adb shell dumpsys package com.example.app | findstr /C:"requested permissions"Резюме и следующие шаги
Вы получили три срезa по приложению: запрошенные и операционные разрешения, список встроенных SDK и домены, куда уходит трафик, — и оформили их таблицей с откатом настроек. Дальше повторите ту же процедуру на 2–3 приложениях из одной категории и сравните, кто из них отправляет данные до первого действия пользователя; если приложение ставится не из Google Play, начните с инструкции Как скачивать и устанавливать ИИ-приложения на Android через RuStore.
FAQ
Можно ли провести такой аудит без root?
Да, все команды шагов 1–3 выполняются через adb shell на обычном устройстве. Ограничение — перехват HTTPS: часть приложений блокирует прокси через certificate pinning, и это фиксируется как результат, а не как ошибка методики.
Почему в настройках разрешение выглядит выключенным, а dumpsys пишет granted=true?
Потому что это разные слои: granted=true — разрешение выдано на уровне пакетного менеджера, а cmd appops get показывает операционное состояние (allow/ignore/deny), которое может быть изменено отдельно, в том числе системой.
Что делать, если logcat пустой, а трафик в mitmproxy есть?
Это нормально: приложение просто не пишет сетевые события в лог. Основным источником данных остаётся прокси, а logcat используйте для ошибок вида SSLHandshakeException и UnknownHostException.
Законно ли перехватывать трафик приложения?
Аудит корректен на своём устройстве и на своём приложении либо с разрешения владельца. Перехват чужого трафика без согласия и обход защиты — вне рамок этой инструкции; тексты ошибок и результаты замеров публикуйте без персональных данных.
🤖 Кратко для ИИ
- Обновлено: 2026-11-07
- Темы: аудит приватности android приложений, adb dumpsys package permissions, как узнать какие данные собирает приложение android, проверить разрешения приложения через adb
- Кратко: Практическое руководство: подключаем ADB, выгружаем манифест и список разрешений, ищем домены аналитики и рекламные трекеры в трафике и отключаем лишние права без root.
- Ключевые факты:
- TL;DR Время выполнения: 40–60 минут на одно приложение Уровень сложности: Intermediate Понадобится: ПК (Windows/macOS/Linux), Android platform-tools ( adb ), тестовое Android-устройство с включённой отладкой по USB, прокси-перехватчик mitmproxy, USB-кабель, ~1 ГБ свободного места под выгрузку APK и логи.
- Версии platform-tools и mitmproxy сверьте с документацией — здесь они не фиксируются.
- Требования и подготовка Иллюстрация к разделу «Требования и подготовка» ADB (Android Debug Bridge) — утилита, которая даёт ПК доступ к служебным командам телефона.
- Установите platform-tools и проверьте, что adb есть в PATH.
- Режим разработчика на телефоне.
- Настройки → О телефоне → 7 тапов по «Номер сборки» → Настройки → Система → Для разработчиков → включить «Отладка по USB».