Здарова, братишка. Снова мы в деле. Сегодня на нашем операционном столе — мобильные приложения. Многие думают, что без рута или джейлбрейка там ловить нечего, мол, «песочница», «безопасность от вендора». Сказки для новичков. Мы-то с тобой знаем: где код — там и дыры. Просто нужно знать, куда копать.

Точка входа: Декомпиляция APK
Первое, что мы делаем, — вскрываем пациента. Нам нужно заглянуть ему под капот, изучить его анатомию. Для этого нет ничего лучше старого доброго apktool.

Что я вижу: У нас есть app.apk. Это просто ZIP-архив с ресурсами и скомпилированным кодом. Наша задача — превратить его обратно в читаемый вид.

Как я думаю: Мне не нужен весь Java-код. Мне нужны манифест, чтобы увидеть разрешения и компоненты, ресурсы (особенно строки, где могут быть ключи API), и smali-код, чтобы понять логику. Smali — это ассемблер для виртуальной машины Dalvik/ART, читается тяжело, но даёт полное представление о работе приложения.

Куда я лезу:

1. Сначала находим полный путь к пакету на устройстве, если он уже установлен. Это нужно, чтобы убедиться, что мы работаем с нужной версией, и чтобы потом вытаскивать данные.

2. Теперь декомпилируем сам APK-файл. Команда проста до безобразия:

1. На выходе получаем папку app со всей структурой. Особое внимание на AndroidManifest.xml (ищем android:allowBackup="true", экспортируемые activity, services), папку res/values/strings.xml (хардкод) и, конечно, папку smali.

Вектор атаки: Сетевой трафик и обход SSL-Pinning

99% приложений общаются с сервером. А где есть общение — есть что перехватить. Наш главный инструмент здесь — Burp Suite.

Что я вижу: Приложение при запуске ломится на свои API-эндпоинты. Если оно делает это по HTTP, мы победили сразу. Но сейчас все используют HTTPS. А умные разработчики прикручивают SSL-Pinning — приложение доверяет только своему, заранее вшитому сертификату, и посылает лесом наш сертификат от Burp.

Как я думаю: Сначала нужно направить трафик с эмулятора на мой Burp. Затем, если сработает пиннинг, нужно его обойти. Для этого есть Frida — швейцарский нож для инъекций в процессы.

Пошаговый разбор:

1. Настройка прокси в Burp Suite:
   • В Burp идём в Proxy > Options.
   • Добавляем новый listener на All interfaces и любой свободный порт (например, 8080). Это позволит эмулятору достучаться до нашего хоста.
2. Настройка прокси на эмуляторе Android:
   • Открываем настройки эмулятора (три точки сбоку), идём в Settings > Proxy.
   • Выбираем Manual proxy configuration, вводим IP-адрес нашего компьютера в локальной сети и порт 8080. Если эмулятор и Burp на одной машине, можно использовать специальный IP 10.0.2.2, который в эмуляторе является алиасом для localhost хост-машины.
   • Устанавливаем сертификат Burp на эмулятор, чтобы он в принципе мог работать с HTTPS.
3. Обход SSL-Pinning с помощью Frida:
   • Устанавливаем Frida на хост и frida-server на эмулятор (для этого, увы, чаще всего нужен рут на эмуляторе, но не на реальном устройстве, которое мы атакуем).
   • Запускаем frida-server на эмуляторе.
   • На хосте выполняем команду, которая запускает приложение и одновременно подгружает в него JavaScript-пейлоад для обхода пиннинга:

1. • • -U: подключаемся к USB-устройству.-f com.target.app: запускаем указанное приложение.-l ssl_bypass.js: загружаем наш скрипт. Готовые скрипты есть на Frida CodeShare.
   Теперь в Burp мы видим весь расшифрованный трафик. Можем анализировать запросы и подменять ответы сервера. Например, если сервер отвечает { "status": "fail", "balance": 0 }, мы можем через Proxy > Intercept или Proxy > Match and Replace подменить ответ на { "status": "ok", "balance": 9999 } и посмотреть, как приложение сбрендит.

Трюк: Автоматизация и поиск данных

Руками ковырять — это хорошо, но долго. Часть рутины можно и нужно автоматизировать.

Что я вижу: У нас есть APK, и мы хотим быстро получить отчёт о самых очевидных дырах: хардкод, небезопасные разрешения, уязвимые компоненты.

Как я думаю: Зачем делать работу, которую за меня сделает робот? Используем MobSF (Mobile Security Framework). Это комбайн для статического и динамического анализа.

Куда я лезу:

1. Разворачиваем MobSF локально (он есть на GitHub).
2. Загружаем в его веб-интерфейс наш app.apk.
3. MobSF сам его декомпилирует, проанализирует манифест, найдёт хардкоженные ключи, проверит настройки сетевой безопасности и выдаст красивый отчёт. Это экономит часы работы.

Поиск бэкапов:
Если в AndroidManifest.xml мы нашли android:allowBackup="true", это наш шанс. Эта опция позволяет делать резервную копию данных приложения через adb.

Полученный файл backup.ab можно распаковать и найти внутри много интересного: базы данных SQLite, файлы SharedPreferences (это XML-файлы с настройками, токенами, ключами) и другие кэшированные данные. Часто там лежат сессионные токены, логины и пароли в открытом виде.

Советы

1. Копай глубже в хранилище. Кроме SharedPreferences, приложения хранят данные в базах SQLite (/data/data/com.target.app/databases/) и на внешней карте памяти. Проверь всё.
2. Изучай Smali-код. Ищи в нём кастомные алгоритмы шифрования/обфускации. Часто разработчики пишут свои «велосипеды», которые легко сломать, зная алгоритм.
3. Используй Objection. Если не хочешь писать скрипты для Frida сам, используй Objection. Это готовый фреймворк поверх Frida, который позволяет на лету исследовать приложение, дампить память, обходить SSL-pinning одной командой (android sslpinning disable).
4. Фаззинг API. Когда ты перехватил запросы в Burp, не останавливайся на анализе. Отправь их в Intruder и начни фаззить параметры. Ищи SQLi, IDOR, XSS и прочую классику веб-уязвимостей.
5. Проверь экспортируемые компоненты. Если в манифесте есть activity, service или receiver с флагом android:exported="true", их можно дёргать из других приложений, что может привести к утечке данных или выполнению несанкционированных действий.

На этом все. Всем хорошего дня!