Инструментальная цепочка для динамического анализа Android‑приложений в Termux: Frida + radare2 + Ghidra с CI/CD‑потоками

Динамический анализ Android‑приложений всё чаще становится регулярной инженерной задачей: быстро проверить гипотезу, локализовать проблему, собрать артефакты трассировок и сделать результат воспроизводимым. В этом материале описана инструментальная цепочка для работы в Termux на стороне аналитика и подготовлена логика CI/CD‑потоков, чтобы обработка APK, трассировки и последующий разбор в radare2 и Ghidra были стандартизированы.

Важно: ниже рассматривается безопасный и легитимный подход — анализ приложений в рамках разрешённых работ (собственное ПО, тестовые стенды, договорённости с владельцем). Ядро процесса строится вокруг инженерии, воспроизводимости и контроля качества.

Целевая архитектура: что и зачем

Предлагаемая цепочка состоит из трёх взаимодополняющих слоёв:

Frida (динамика): перехват функций/методов, трассировка вызовов, снятие артефактов поведения, сбор диагностических данных из живого приложения.
radare2 (прагматичная статика/быстрые правки): быстрый обзор бинарников/DEX‑структур, поиск по сигнатурам, навигация по графам, выгрузка фрагментов.
Ghidra (глубокая статика): более удобная и масштабируемая аналитика, декомпиляция/разметка, управляемое накопление знаний.

Termux выступает как единая “операционная среда”: установка зависимостей, запуск сценариев, сбор отчётов и генерация артефактов для последующего анализа в CI‑процессах.

Подготовка Termux: базовый рабочий контур

Начинаем с системной подготовки и фиксации окружения. В реальной практике помогает закрепить версии пакетов и вести журнал команд для повторяемости.

pkg update -y
pkg upgrade -y

pkg install -y git wget curl unzip tar clang make python ndk-toolchain-tool python-pip

Для удобства сборки скриптов заведите структуру проекта на устройстве:

mkdir -p ~/android-rtlab/{apps,bin,logs,artifacts,configs,workdir}
cd ~/android-rtlab

Дальше выстраиваем пайплайн: вход — APK/артефакты, выход — трассы Frida и материал для radare2/Ghidra.

Установка Frida в Termux (и организация “инъекции”)

Frida в Android‑аналитике обычно используется совместно с сервером на устройстве/эмуляторе. Терминологически это “Frida server” на стороне Android и “frida tools” на стороне вашей рабочей среды. В рамках данной статьи описывается инженерный подход к автоматизации и сбору данных; конкретные шаги зависят от архитектуры устройства и вашей модели развертывания.

Как минимум, вам понадобятся CLI‑утилиты и возможность запускать сценарием сбор данных.

pip install --user frida frida-tools

Дальше — место для сценариев. Создайте каталог с агентами:

mkdir -p ~/android-rtlab/frida-scripts
touch ~/android-rtlab/frida-scripts/trace.js

Пример минимального “трейсера” (шаблон). Он демонстрирует идею: запускать скрипт, собирать события и сохранять в файл. Точные точки перехвата лучше подбирать под конкретное приложение (Java/Kotlin или native компоненты).

// ~/android-rtlab/frida-scripts/trace.js
// Шаблон. Заполните под ваши цели (например, интересующие методы или классы).
Java.perform(function () {
  // Пример: можно печатать события по конкретному классу/методу,
  // либо собирать общую телеметрию.
  console.log("Frida trace agent started (template).");
});

Чтобы корректно запускать агента, нужен канал к процессу приложения. Практика обычно выглядит как: находите PID процесса, присоединяетесь, запускаете скрипт и подписываетесь на stdout/сообщения.

Шаблон команды (на уровне идеи):

frida -U -n com.example.app -l ~/android-rtlab/frida-scripts/trace.js --output ~/android-rtlab/logs/frida-session.log

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

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

Для CI/CD важнее не “один успешный запуск”, а набор повторяемых артефактов. Поэтому организуйте формат хранения:

Трассы Frida: logs/frida-.log
Снимки окружения (версия устройства/архитектура, параметры запуска): artifacts/env.json
Плейбук анализа: configs/runplan.yaml или JSON
Отдельный каталог на каждый билд/версию приложения: workdir/<app>/<version>/

Пример простого “контейнера запуска” (концептуальный скрипт):

APP_PKG="com.example.app"
RUN_ID="$(date +%Y%m%d_%H%M%S)"
OUT_DIR="$HOME/android-rtlab/workdir/$APP_PKG/$RUN_ID"
mkdir -p "$OUT_DIR"

frida -U -n "$APP_PKG" 
  -l "$HOME/android-rtlab/frida-scripts/trace.js" 
  --output "$OUT_DIR/frida.log"

# Здесь добавьте сбор env/метаданных вашего стенда (по вашей политике).
echo "{"app":"$APP_PKG","run_id":"$RUN_ID"}" > "$OUT_DIR/env.json"

Переход к радare2: быстрый обзор и ориентирование по коду

Динамика отвечает на вопрос “что делает приложение”, а статика — “где это находится” и “как устроено в деталях”. radare2 хорош, когда нужно быстро:

получить карту секций/символов (для нативной части или преобразованных компонентов);
сделать поиск по строкам/подозрительным паттернам;
быстро понять контуры и сформировать “следующую гипотезу” для Ghidra.

Для старта в Termux установите radare2:

pkg install -y radare2

Если у вас APK, то для статического анализа обычно нужен извлечённый контент (например, classes.dex или нативные библиотеки из lib/). После извлечения можно анализировать подходящие артефакты.

Пример извлечения APK в рабочую директорию:

APK_PATH="$HOME/android-rtlab/apps/app.apk"
RUN_DIR="$HOME/android-rtlab/workdir/static/$(date +%Y%m%d_%H%M%S)"
mkdir -p "$RUN_DIR"

unzip -q "$APK_PATH" -d "$RUN_DIR"
ls -la "$RUN_DIR"

Далее — выбор “чего анализировать” в radare2. Для нативных библиотек часто есть смысл запускать анализ прямо по .so:

SO_PATH="$(find "$RUN_DIR" -type f -name ".so" | head -n 1)"
echo "Using: $SO_PATH"

r2 -qc "iI; iS; iz; /x" "$SO_PATH" > "$RUN_DIR/radare2-index.txt"

Результаты radare2 фиксируйте в артефактах пайплайна — это ускоряет итерации и позволяет CI сравнивать изменения.

Переход к Ghidra: структурированный разбор и накопление разметки

Ghidra удобна для углубления анализа: декомпиляция, именование, трассировка вызовов, документирование находок. Терминал Termux — не обязательно “место для GUI”, но вполне подходит для подготовки:

подготовить входные файлы (извлечение, нормализация);
сформировать пакеты артефактов для загрузки/открытия в среде Ghidra;
выгружать экспортные отчёты.

На практике частая модель такая:

Frida даёт “места/методы/участки”, которые подтверждают гипотезу поведения.
radare2 помогает найти смежные куски и быстро оценить структуру.
Ghidra используется для полноценного понимания и документирования, а затем результаты возвращаются в репозиторий как отчёты и заметки.

Чтобы CI/CD приносил пользу, договоритесь о едином формате артефактов: например, “пакет разбора” = извлечённые бинарники + json/markdown‑отчёт + ссылки на фрагменты из логов.

CI/CD для аналитики в Android‑контуре: как сделать воспроизводимость

CI/CD для динамического анализа — это не только “сборка”, но и повторяемое воспроизведение процесса. Типовой подход:

Repository содержит: Frida‑скрипты, конфиги целей, шаблоны запуска, правила именования артефактов.
Pipeline запускается на заранее подготовленном стенде (эмулятор/устройство в пределах разрешённых рамок), выполняет запуск и сбор логов.
Статические шаги (radare2/Ghidra) выполняются уже в CI‑контуре либо на отдельном аналитиесервере.

С точки зрения практики важно обеспечить:

Версионность входа: версия APK/хэши.
Версионность инструментов: фиксировать версии Frida tools, radare2, JDK (для Ghidra‑среды).
Стабильные пути в артефактах.

Ниже приведён концептуальный пример пайплайна (YAML‑шаблон). Его можно адаптировать под GitLab CI, GitHub Actions или Jenkins.

# .ci/pipeline.yml (шаблон)
stages:
  - dynamic
  - static-radare2
  - static-ghidra
  - report

variables:
  APP_PKG: "com.example.app"

dynamic:
  stage: dynamic
  script:
    - echo "Run dynamic analysis"
    - ./scripts/run-frida.sh "$APP_PKG" --out "artifacts/dynamic"
  artifacts:
    paths:
      - artifacts/dynamic

static-radare2:
  stage: static-radare2
  script:
    - echo "Run radare2 quick scan"
    - ./scripts/run-radare2.sh artifacts/input/apk artifacts/static
  artifacts:
    paths:
      - artifacts/static

static-ghidra:
  stage: static-ghidra
  script:
    - echo "Prepare Ghidra package"
    - ./scripts/prepare-ghidra.sh artifacts/static artifacts/ghidra
  artifacts:
    paths:
      - artifacts/ghidra

report:
  stage: report
  script:
    - ./scripts/build-report.sh artifacts/dynamic artifacts/static artifacts/ghidra --out artifacts/report

Компоненты скриптов фиксируйте в репозитории. Например, ./scripts/run-frida.sh — отвечает только за запуск и сбор логов, а не за “понимание” данных. Понимание — в отчётах и отдельном шаге аналитики.

Сетевой аспект: локальная лабораторная сеть (опционально)

Если вы используете несколько узлов (например, аналитический сервер для Ghidra и стенд для эмулятора), иногда требуется связывать компоненты по сети. В таком случае корректный подход — организовать локальную лабораторную сеть для взаимодействия сервисов, без привязки к “обходу” ограничений.

Примерно это означает: поднять локальные адреса, убедиться, что контролируемый трафик доступен только внутри вашей среды, и только затем запускать обмен артефактами.

Модель работы аналитика: цикл гипотеза → трасса → разметка → отчёт

Чтобы цепочка не превращалась в “набор разрозненных инструментов”, используйте единый цикл:

Гипотеза (из требований, баг‑репорта или сигнала).
Динамика в Frida: зафиксировать сигналы поведения, собрать примеры контекстов (параметры, стек вызовов, идентификаторы).
Ориентация в radare2: найти приближённое место в бинарной/нативной составляющей или подтвердить паттерны.
Глубина в Ghidra: разметить, именовать, описать компоненты.
Отчёт и артефакты: положить результаты в репозиторий/CI‑артефакты так, чтобы следующий анализ начинался быстрее.

Практический чек‑лист качества

Именование: единые префиксы для логов, трассировок и пакетов анализа.
Матчасть: фиксируйте, какие классы/методы вы трейсите и почему.
Ограничение шумов: делайте фильтрацию событий в сценариях, чтобы логи были полезны.
Согласование форматов: один формат отчёта и одно дерево артефактов для всех проектов.
Рецензируемость: добавляйте небольшие “отчёты‑промежуточные состояния”, чтобы команда могла быстро оценить прогресс.

Заключение

Инструментальная цепочка для динамического анализа Android‑приложений в Termux может быть не хаотичным набором команд, а инженерной системой: Frida для поведения, radare2 для быстрых статических подсказок и Ghidra для глубокой разметки — связаны едиными артефактами и поддержаны CI/CD‑потоками для воспроизводимости. Такой подход ускоряет итерации, снижает риск потери контекста и делает результаты анализа проверяемыми.

Если вам нужна помощь с внедрением процесса под ваш стенд, настройкой пайплайнов, подготовкой сценариев Frida и стандартизацией отчётности, обращайтесь в РыбинскЛАБ — мы поможем выстроить практичную и безопасную цепочку анализа.