Termux — мощная среда для работы в Android, которая позволяет готовить инструменты и скрипты под задачи анализа приложений. В этой статье показан практический подход к разработке скриптов для автоматической реверс‑инжинирии Android‑пакетов: декомпиляция, статический анализ и подготовка YARA‑правил — но исключительно в правовых и этичных рамках РФ.
Важно: мы не рассматриваем инструкции, направленные на обход защит, взлом, несанкционированный доступ или подмену/вредоносное использование. Ниже — методики для исследования собственных сборок, анализа легально полученных образцов и повышения качества детектирования в рамках корпоративной ИБ/пентест‑процессов с разрешением.
Юридические рамки и корректные сценарии
Перед началом работ убедитесь, что вы имеете право анализировать конкретный APK/архив. Корректные сценарии включают:
- Анализ ваших приложений и модулей, а также приложений, на которые у вас есть договорные права;
- Исследование образцов, полученных законным способом (например, из собственных репозиториев или в рамках работ по обеспечению безопасности);
- Разработка сигнатур/правил для собственных систем мониторинга и защитных контуров (EDR/AV/локальные детекторы) без попыток несанкционированного применения.
Если задача связана с инцидентами, действуйте по установленным процедурам и согласуйте работы с юридическими/ИБ‑службами.
Подготовка Termux: базовая среда под анализ
Рекомендуется начинать с актуального набора пакетов и изолировать рабочие каталоги. Для некоторых инструментов может потребоваться Java, а также средства для работы с архивами и форматом APK.
pkg update
pkg upgrade -y
pkg install -y git python nodejs openjdk-17 termux-tools wget unzip zip fileПроверьте Java:
java -versionСтруктура проекта для автоматизации
Сформируйте папку проекта, где будут: входные APK, результаты декомпиляции, отчёты статического анализа и выходные YARA‑правила.
mkdir -p ~/apk-rev/{input,work,results,yara,logs}
cd ~/apk-revДекомпиляция APK: практический пайплайн
APK — это zip-архив, внутри которого находятся ресурсы (resources.arsc), классы Dalvik/ART (обычно classes.dex) и манифест AndroidManifest.xml. Для статического анализа часто нужно перевести код в представление, пригодное для чтения и сопоставления.
В Termux для распаковки можно использовать standard tools, а для перевода Dex в более читаемые формы — Java‑утилиты. Ниже показан универсальный скрипт: распаковка и извлечение ключевых артефактов.
cat > ~/apk-rev/scripts_unpack.sh <<'EOF'
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail
APK_PATH="${1:-}"
OUT_DIR="${2:-}"
if [ -z "$APK_PATH" ] || [ -z "$OUT_DIR" ]; then
echo "Usage: $0 /path/to/app.apk /path/to/output"
exit 1
fi
mkdir -p "$OUT_DIR"
cp "$APK_PATH" "$OUT_DIR/app.apk"
unzip -o "$APK_PATH" -d "$OUT_DIR/unpacked" >/dev/null
# Помечаем найденные файлы
file "$OUT_DIR/unpacked"/ 2>/dev/null || true
# Копируем наиболее интересное в рабочий корень
if [ -f "$OUT_DIR/unpacked/classes.dex" ]; then
cp "$OUT_DIR/unpacked/classes.dex" "$OUT_DIR/work.dex"
fi
if [ -f "$OUT_DIR/unpacked/AndroidManifest.xml" ]; then
cp "$OUT_DIR/unpacked/AndroidManifest.xml" "$OUT_DIR/AndroidManifest.xml"
fi
echo "[OK] Unpacked: $OUT_DIR"
EOF
chmod +x ~/apk-rev/scripts_unpack.shСкрипт статического анализа: извлечение артефактов и признаков
Статический анализ в рамках легитимных задач обычно включает сбор информации:
- размер APK и структура;
- строки (URLs, пути, ключевые токены, имена классов);
- разрешения и компоненты из манифеста;
- хэши для повторяемости;
- список dex‑признаков и ссылок.
Ниже пример скрипта, который собирает артефакты в отчётный каталог: хэши, извлечённые строки (через strings) и базовую сводку.
cat > ~/apk-rev/scripts_static_fingerprint.sh <<'EOF'
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail
IN_DIR="${1:-}"
OUT_DIR="${2:-}"
mkdir -p "$OUT_DIR"
# Хэши исходника
if [ -f "$IN_DIR/app.apk" ]; then
sha256sum "$IN_DIR/app.apk" > "$OUT_DIR/sha256.txt"
fi
# Расклад по содержимому
( cd "$IN_DIR" && find . -maxdepth 3 -type f -print > "$OUT_DIR/filelist.txt" ) || true
# Строки из unpacked/ или work.dex
# (В некоторых APK есть proguard-стиль данные; strings помогает получить потенциальные индикаторы.)
DEX_CANDIDATE="$IN_DIR/work.dex"
if [ -f "$DEX_CANDIDATE" ]; then
strings -n 6 "$DEX_CANDIDATE" | sort -u > "$OUT_DIR/strings.dex.txt" || true
fi
# Базовые признаки: манифест может быть бинарным; при наличии readable-версии — извлекаем строки.
if [ -f "$IN_DIR/AndroidManifest.xml" ]; then
strings -n 6 "$IN_DIR/AndroidManifest.xml" | sort -u > "$OUT_DIR/strings.manifest.txt" || true
fi
# Сводка по размерам
( du -ah "$IN_DIR" | sort -h > "$OUT_DIR/sizes.txt" ) || true
echo "[OK] Static fingerprint written to: $OUT_DIR"
EOF
chmod +x ~/apk-rev/scripts_static_fingerprint.shАвтоматизация в один командный запуск
Чтобы удобно запускать анализ партии APK, подготовьте “оркестратор”. Он создаёт рабочую директорию, распаковывает APK, затем собирает статические признаки.
cat > ~/apk-rev/run_pipeline.sh <<'EOF'
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail
APK_FILE="${1:-}"
if [ -z "$APK_FILE" ]; then
echo "Usage: $0 /path/to/app.apk"
exit 1
fi
BASENAME=
BASENAME="$(basename "$APK_FILE" .apk)"
WORK_DIR="~/apk-rev/work/$BASENAME"
RESULT_DIR="~/apk-rev/results/$BASENAME"
mkdir -p "$WORK_DIR" "$RESULT_DIR"
~/apk-rev/scripts_unpack.sh "$APK_FILE" "$WORK_DIR"
~/apk-rev/scripts_static_fingerprint.sh "$WORK_DIR" "$RESULT_DIR"
echo "[DONE] Pipeline completed for: $BASENAME"
EOF
chmod +x ~/apk-rev/run_pipeline.shГенерация YARA‑правил: подход без “магии”
YARA‑правила формируются из наблюдаемых признаков. В рамках статического анализа разумный путь:
- выбрать устойчивые индикаторы (строки, фрагменты, характерные байтовые последовательности);
- проверить, что признаки не слишком “общие” и не ведут к ложным срабатываниям;
- добавить условия по контексту (например, размер файла, наличие нескольких индикаторов сразу).
Ниже — пример скрипта, который берёт из списка строк кандидаты и создаёт черновую YARA‑заготовку. Это не замена валидации; это стартовая точка.
cat > ~/apk-rev/scripts_generate_yara_stub.sh <<'EOF'
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail
RESULT_DIR="${1:-}"
YARA_OUT_DIR="${2:-}"
if [ -z "$RESULT_DIR" ] || [ -z "$YARA_OUT_DIR" ]; then
echo "Usage: $0 /path/to/results/appName /path/to/yara_out"
exit 1
fi
mkdir -p "$YARA_OUT_DIR"
STRINGS_FILE="$RESULT_DIR/strings.dex.txt"
if [ ! -f "$STRINGS_FILE" ]; then
echo "Strings file not found: $STRINGS_FILE"
exit 1
fi
APP_NAME="$(basename "$RESULT_DIR")"
YARA_FILE="$YARA_OUT_DIR/${APP_NAME}.yar"
# Простая эвристика: берём первые N строк, содержащих URL/путь/маркер.
# В продакшене замените на более строгий отбор и валидацию.
CANDIDATES=$(grep -E -i 'http://|https://|/api/|/v[0-9]+/|token|secret|key' "$STRINGS_FILE" | head -n 30 || true)
# Формируем секцию strings
STRING_BLOCK=""
while IFS= read -r line; do
# Нормализуем: убираем непечатное и кавычки
safe=$(echo "$line" | tr -d '\r' | sed 's/"/\\"/g')
# Пропускаем слишком короткие
[ ${#safe} -lt 6 ] && continue
STRING_BLOCK+=" \"$safe\" ascii nocase
"
done < <(printf "%s
" "$CANDIDATES")
cat > "$YARA_FILE" <<EOF_YARA
rule ${APP_NAME}_autogen {
meta:
description = "Auto-generated stub from Termux static strings"
source = "${APP_NAME}"
strings:
$STRING_BLOCK
condition:
uint16(0) == 0x4d5a or any of ($ )
}
EOF_YARA
echo "[OK] YARA stub generated: $YARA_FILE"
EOF
chmod +x ~/apk-rev/scripts_generate_yara_stub.shПримечание: условие в примере намеренно “черновое” и включает проверку формата. Для практической работы вместо any of ($* ) лучше использовать точные имена строк и пороги (например, “не менее 3 из N”), но финальные условия всегда должны проверяться на наборах “белых/серых/вредных” образцов.
Валидация YARA‑правил на контрольных выборках
Правильная разработка детектов требует сравнения:
- на образцах, где вы ожидаете срабатывание;
- на фоновых/легитимных приложениях, чтобы оценить ложноположительные;
- на вариантах одной и той же семьи (чтобы оценить устойчивость).
В Termux можно прогонять YARA по файлам и собирать статистику. Если YARA у вас установлен, используйте базовую проверку.
# Пример (если yara установлен):
# yara -r ~/apk-rev/yara/appName.yar ~/apk-rev/inputЕсли YARA нет — установите только легитимные инструменты из репозиториев Termux и проверьте корректность сборки под вашу среду.
Типовые улучшения пайплайна (безопасная “профессионализация”)
- Повторяемость: фиксируйте версии скриптов и зависимостей, сохраняйте хэши входных файлов.
- Нормализация данных: приводите извлечённые строки к единому виду (кодировки/пробелы/обрезки).
- Пороговые условия: в YARA используйте условия “N из M” для снижения ложных срабатываний.
- Контекст: комбинируйте статические признаки (например, наличие строк + особенности DEX/манифеста).
- Отчётность: сохраняйте промежуточные артефакты (filelist, strings, sha256) для последующей экспертизы.
Точки контроля и требования к качеству
Чтобы результаты были пригодны в работе аналитика ИБ или разработчика защитного контура:
- отмечайте, на какой стадии какие признаки были извлечены;
- не полагайтесь на единичную строку — ищите ансамбли;
- проверяйте правила на разных сборках и минимизируйте “пустые” срабатывания;
- не используйте полученные знания для обхода мер защиты или злоупотреблений.
Заключение
Автоматизация реверс‑инжиниринга Android‑пакетов в Termux возможна и практична: распаковка APK, сбор статических признаков, подготовка черновых YARA‑правил и последующая валидация на контрольных выборках позволяют превратить “ручной разбор” в воспроизводимый пайплайн. Ключ к успеху — законные основания на анализ конкретных образцов, аккуратный отбор индикаторов и обязательная проверка ложных срабатываний.
Если вы хотите собрать промышленно‑подобный пайплайн под ваши форматы отчётов, корпоративную инфраструктуру или требования SOC/DFIR, команда РыбинскЛАБ поможет: аудит процесса анализа, разработка скриптов и подготовка детектов с учётом качества и валидации.