На аудите финтех-приложения три часа ушли не на поиск IDOR в API, а на борьбу со стендом: Android 14 монтировал
/system в read-only, сертификат Burp не попадал в системное хранилище доверия, а Frida-сервер падал из-за несовпадения архитектуры с эмулятором. Знакомо? Мобильный пентестер тратит на настройку среды больше времени, чем на эксплуатацию. Это не преувеличение - это статистика по десяткам проектов.Стандартный workflow мобильного аудита идёт по цепочке: статический анализ APK (jadx, apktool) -> настройка перехвата трафика (Burp Suite) -> динамическая инструментация (Frida) -> тестирование API-бэкенда. Первые три этапа требуют правильно настроенной лаборатории для мобильного пентеста, и именно тут горит время. Ниже - рабочая конфигурация, обкатанная на финтехе и e-commerce.
Требования к окружению для настройки среды пентеста мобильных приложений
Прежде чем ставить первый инструмент - оцените ресурсы. Android-эмулятор с Burp Suite и Frida одновременно жрёт больше, чем кажется.| Параметр | Минимум | Рекомендуется |
|---|---|---|
| RAM | 16 ГБ | 32 ГБ |
| CPU | Intel i5 / Ryzen 5 с VT-x / AMD-V | Intel i7 / Ryzen 7 |
| Диск | 50 ГБ SSD | 100 ГБ NVMe |
| ОС | Windows 10/11, macOS 12+, GNU/Linux | Windows 11 или macOS |
| Сеть | Доступ к интернету для загрузки SDK | Доступ к интернету для загрузки SDK |
Программный стек: Android Studio (актуальная версия с AVD Manager), Burp Suite Community или Pro, Python 3.x,
adb из Android SDK Platform Tools. Для рутирования - скрипт rootAVD (GitHub: GitHub - newbit1/rootAVD: Script to root AVDs running with QEMU Emulator from Android Studio, community-проект). Для динамического анализа - Frida (GitHub: GitHub - frida/frida: Clone this repo to build Frida, более 20 тыс. звёзд, активная разработка) и objection (GitHub: GitHub - sensepost/objection: На 16 ГБ RAM эмулятор с 4 ГБ выделенной памяти плюс Burp плюс IDE будут заметно свопить. Если параллельно держите jadx или MobSF (GitHub: GitHub - MobSF/Mobile-Security-Framework-MobSF: Mobile Security Framework (MobSF) is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing, malware analysis and security assessment framework capable of performing static and dynamic analysis., активно развивается) - 32 ГБ не роскошь, а рабочий минимум. Проверено на собственном нервном тике от зависающего эмулятора.
Эмулятор Android для пентеста: AVD vs Genymotion
Для лаборатории мобильного пентеста два основных варианта виртуализации: Android Virtual Device (AVD) из Android Studio и Genymotion. Выбор зависит от проекта.
Android Studio AVD - актуальный стандарт
Открываем Android Studio -> More Actions -> Virtual Device Manager -> Create Virtual Device. Для пентеста выбирайте модель с Google Play (Pixel 9 или аналог) и актуальную версию API - уровень 34–36. Это даёт рабочий Play Store для установки целевых приложений прямо из маркета.Критический момент: AVD с Google Play по умолчанию не рутован, а файловая система смонтирована как read-only. Для root используется скрипт rootAVD - он автоматически интегрирует Magisk в образ эмулятора. Скачиваем репозиторий с GitHub, запускаем
rootAVD.bat ListAllAVDs через cmd.exe (не PowerShell - скрипт с ним конфликтует, подтверждено в документации проекта). После завершения работы скрипта перезапускаем AVD - в списке приложений появляется Magisk Manager. Проверка: adb shell su должна отдать root-шелл.По данным blog.lrvt.de, Android Studio AVD значительно быстрее Genymotion и поддерживает все актуальные версии Android с нативным Google Play Store.
Genymotion пентест настройка - быстрый старт
Genymotion - коммерческий эмулятор на базе VirtualBox. Главный плюс: образы идут предрутованными из коробки. Не нужен rootAVD, не нужен Magisk - root доступен сразу. Экономия 15–20 минут на первичной настройке.Ограничения (и они существенные): бесплатная версия (Personal Edition) урезана, максимальная версия Android может отставать от актуальной. Для коммерческих проектов нужна лицензия. ARM-трансляция требует отдельной настройки - без неё часть приложений из Play Store просто не запустится.
Сравнение: реальное устройство vs эмулятор пентест
| Критерий | AVD (Android Studio) | Genymotion | Реальное устройство |
|---|---|---|---|
| Root из коробки | Нет (нужен rootAVD) | Да | Нужна разблокировка загрузчика |
| Актуальность API | API 36 | Зависит от тарифа | Зависит от модели |
| Google Play | Нативно | Через OpenGApps | Нативно |
| Аппаратный Keystore | Нет | Нет | Да |
| Биометрия | Эмуляция | Эмуляция | Реальная |
| Стоимость | Бесплатно | Бесплатно / платно | $100–300 (б/у Pixel) |
| Снапшоты | Да | Да | Нет |
Ни AVD, ни Genymotion не воспроизводят TrustZone, hardware-backed Keystore, BLE/NFC и поведение вендорских прошивок (Samsung Knox, MIUI). Если приложение использует аппаратную аттестацию SafetyNet / Play Integrity - эмулятор провалит проверку даже с Magisk. Тут без физического девайса никуда.
Замечание про iOS
Полноценного бесплатного эмулятора для iOS-пентеста не существует. Xcode Simulator запускает приложения в упрощённой среде - это не настоящая iOS, динамический анализ через Frida на нём невозможен. Corellium предлагает облачную виртуализацию реальной iOS, но стоит от $99/мес. Для большинства проектов используется jailbroken iPhone: checkra1n для чипов A8–A11, palera1n для более новых (с ограничениями по версиям iOS). Burp Suite и Frida на jailbroken iOS настраиваются аналогично Android.Burp Suite настройка для Android: перехват трафика мобильного приложения
Начиная с Android 7 (Nougat) приложения по умолчанию доверяют только сертификатам из системного хранилища.
📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме
Frida - инструмент динамического анализа мобильных приложений
Frida перехватывает и модифицирует вызовы функций в рантайме. По месту в цепочке аудита - это этап динамического анализа: после статического реверса через jadx, но до полноценного тестирования API-бэкенда через Burp. Основное применение в мобильном пентесте: обход SSL pinning, модификация логики проверок (root detection, integrity checks), извлечение ключей и токенов из памяти.
Установка и типичные ошибки
Bash:
# Хост-машина: клиентская часть
pip install frida-tools frida objection
# Устройство/эмулятор: серверная часть
# Скачать frida-server нужной архитектуры
# с https://github.com/frida/frida/releases
adb push frida-server /data/local/tmp/
adb shell "chmod 755 /data/local/tmp/frida-server"
adb shell "/data/local/tmp/frida-server &"
# Проверка: список процессов устройства
frida-ps -U
frida-ps -U зависает или выдаёт «unable to connect to remote frida-server» - проверьте архитектуру: adb shell getprop ro.product.cpu.abi. На одном проекте я полчаса ковырял firewall, а проблема была в arm-сборке на x86-эмуляторе.Альтернатива ручной установке: Magisk-модуль MagiskFrida - автозапуск frida-server при каждой загрузке. Экономит время на повторных перезагрузках эмулятора.
Обход SSL pinning мобильного приложения
objection (надстройка над Frida от sensepost) автоматизирует типовые задачи. Командаobjection --gadget "com.target.app" explore запускает интерактивную сессию, внутри которой android sslpinning disable перехватывает стандартные реализации pinning - OkHttp, TrustManager, Conscrypt - и подменяет проверку.Ограничение: если приложение использует кастомную реализацию pinning (нативная библиотека на C++/Rust с собственной проверкой сертификата), objection не поможет. Потребуется ручной Frida-скрипт, нацеленный на конкретную функцию - её адрес находят через jadx или Ghidra при статическом анализе. Это уже не 5 минут работы, а полноценный реверс.
Flutter и React Native - отдельная головная боль
Flutter-приложения не используют системный прокси и не проходят через стандартный HTTP-стек Android. Настройка прокси через Wi-Fi их трафик не перехватит. Решения: ProxyDroid или redsocks на рутованном устройстве для принудительного проксирования через iptables, либо Frida-скрипт для подмены SecurityContext в Dart-рантайме.React Native в большинстве случаев работает через стандартный HTTP-стек и поддаётся обычной прокси-конфигурации. Тут повезло.
Что видит SOC: detection-чеклист при анализе безопасности мобильных приложений
Если вы выстраиваете мониторинг API-бэкенда мобильного сервиса - вот артефакты, по которым фиксируется пентестерская или вредоносная активность:Сетевой уровень:
- User-Agent с сигнатурами эмулятора:
sdk_gphone,Android SDK built for x86_64,Genymotion - Всплеск запросов с одного IP с нетипичными паттернами - характерно для Burp Intruder/Repeater
- TLS-хендшейки с нестандартной цепочкой сертификатов (подменённый CA Burp в цепочке)
- Запросы с модифицированными параметрами, которые штатный клиент не генерирует
- Обращения к неопубликованным API-эндпоинтам (найденным при декомпиляции APK)
- Отсутствие стандартных телеметрических заголовков (Firebase, Crashlytics), которые Frida-хуки могут подавить
Инструментов в мобильном пентесте прибавляется каждый год, но базовая связка «эмулятор + Burp + Frida» покрывает около 80% типичных проектов. Оставшиеся 20% - edge cases: кастомные протоколы поверх WebSocket, gRPC с mutual TLS, аппаратные токены.
Заключение
Моя позиция: слабое место мобильного аудита сейчас не в инструментарии, а в подготовке стенда. Пентестер, который разворачивает лабораторию за 30 минут вместо трёх часов, находит больше уязвимостей не потому, что он талантливее - а потому что у него остаётся время на анализ бизнес-логики и API. Именно API-уровень, а не клиентская часть, содержит критические проблемы: IDOR (A01:2021 Broken Access Control по OWASP Top 10), отсутствие rate-limiting, утечки данных через verbose-ответы. Клиентские проверки вроде root detection и obfuscation - это speed bumps, а не стены. Обходятся за минуту через objection.Для тех, кто выстраивает защиту: фокусируйтесь на API-аномалиях, а не на попытках детектировать Frida на клиенте. Frida-детект обходится одним скриптом, а вот необъяснимый перебор
?id=1, ?id=2, ?id=3 по эндпоинту профилей - это то, что SIEM должен ловить первым. Если адаптируете правила мониторинга мобильного API-трафика под конкретный SIEM - на codeby.net коллеги разбирают подходы к корреляции клиентских device fingerprint с серверными access-логами для разных стеков.
Последнее редактирование модератором: