Анализ Android с REA: куда APK отправляет запросы?

01. Выберите один экран или действие

«Перечисли все API» — обычно слишком широкий запрос. Начните с видимой операции, например загрузки общедоступного каталога. Запишите версию APK и название экрана. Вам нужен код построения этого запроса, а не все похожие на URL строки пакета.

Это статический анализ. APK не запускается. Встроенные строки могут содержать заброшенные хосты, тестовые среды или пути, объединяемые с конфигурацией во время выполнения.

Исследуй /absolute/path/app.apk с REA. Найди код загрузки общедоступного каталога. Проследи путь от вероятного класса экрана или репозитория до сетевого метода. Укажи возможные хост, путь, HTTP-метод и параметры с подтверждением в классах и методах. Отдели статические объявления от подтверждённого трафика при выполнении.

02. Подключите провайдер Android

Используйте полный JDK, включая модуль компилятора. Укажите REA путь к уже установленному JAR провайдера. Если REA запускается через агента, настройте ту же среду для этого сервера и перезапустите его; переменная в другом терминале не обновляет существующий процесс.

export REA_JADX_MCP_JAR="/absolute/path/jadx-headless-mcp-0.7.1-all.jar"
npx -y [email protected] inspect-android-package "/absolute/path/app.apk" --json
npx -y [email protected] search-android-classes "/absolute/path/app.apk" Catalog --json

03. Изучите класс, затем выберите метод

Поиск классов сопоставляет имена классов, а не произвольные строки в телах методов. Попробуйте названия функций и распространённые сетевые имена: Api, Service или Repository. Для обфусцированных пакетов может потребоваться другая точка входа, например activity из манифеста с переходом к её зависимостям.

Замените класс ниже точным именем из результатов поиска. Изучите его члены перед выбором метода. Если несколько перегрузок имеют одно имя, используйте индекс перегрузки из списка членов класса.

npx -y [email protected] inspect-android-class "/absolute/path/app.apk" com.example.CatalogRepository --json
npx -y [email protected] inspect-android-method "/absolute/path/app.apk" com.example.CatalogRepository loadCatalog --json

04. Отдельно проследите построение запроса и вызывающий код

Изучите место построения запроса и места вызова метода. Постоянный базовый URL — только часть картины: построитель может заменить его, перехватчик — добавить параметры, нативная библиотека — скрыть часть процесса. Зафиксируйте каждую границу.

Входящие ссылки показывают статические связи, известные движку анализа. Рефлексия и динамически загружаемый код могут не попасть в этот набор. Если результат содержит smali вместо Java, считайте его другим представлением того же метода и изучите явно.

npx -y [email protected] trace-android-references "/absolute/path/app.apk" com.example.CatalogRepository --method-name loadCatalog --json

• Какой вызывающий код связывает этот метод с выбранной функцией?
• Базовый URL — литерал, ресурс, значение конфигурации или результат выполнения?
• Какие поля действительно добавляются в запрос?
• Где заканчивается статическое прослеживание?

05. Превратите выводы в небольшую спецификацию

Составьте таблицу с предполагаемым методом, построением URL, именами параметров и подтверждающими ссылками на методы. Значения, доступные только при выполнении, оставьте неизвестными. Используйте локальный сервер-заглушку для прототипа своего клиента по этой спецификации.

Не считайте статический список адресов API успешным перехватом запросов. Для такого утверждения нужна отдельно записанная работа соответствующей версии приложения в подходящей тестовой среде. Это руководство описывает порядок анализа; оно не заявляет о проверенном APK или перехваченном ответе API.