Динамический анализ (Frida) и защита от эмулятора: что такое RASP

В экспертизе нашего собственного приложения одна находка повторилась дважды: и на Android, и на iOS — «нет защиты от инструментов динамического анализа», оба раза с высоким уровнем риска. Кроме того, на Android была находка «не реализовано обнаружение эмулятора» (средний риск). Эти находки связаны между собой и закрываются одним подходом — RASP. В этой статье разберём, что такое Frida, что с ней делает эксперт и как приложение может защитить себя.

Статический и динамический анализ

Эксперт изучает приложение двумя способами:

• Статический анализ — APK или IPA распаковывается, код, ресурсы и конфигурация читаются без запуска. Ему противостоит обфускация.
• Динамический анализ — приложение запускается и наблюдается во время работы: какие функции вызываются, какие значения возвращаются, что лежит в памяти.

Основной инструмент динамического анализа — Frida. Она внедряет свой код в процесс приложения и может перехватить (hook) любую функцию, прочитать или изменить её входные и выходные значения.

Что можно сделать с помощью Frida

Практические примеры — именно это эксперт и проверяет:

• Отключить обнаружение root — функция isRooted() начинает всегда возвращать false.
• Обойти SSL pinning — функция проверки сертификата всегда отвечает «успешно», и трафик раскрывается.
• Изменить бизнес-логику — например, пропустить проверку внутри приложения.
• Прочитать данные из памяти — увидеть открытые данные до шифрования или после расшифровки.

Поэтому защита от динамического анализа защищает все остальные защиты. Обнаружение root или pinning, которые можно отключить хуком, для экспертизы недостаточны.

Это относится к группе RESILIENCE в MASVS и к категории M7 (Insufficient Binary Protections) в OWASP Mobile Top 10 2024.

Почему эмулятор — отдельный вопрос

На эмуляторе анализировать приложение гораздо удобнее: легко делать снапшоты, управлять сетью, получать root и ставить Frida. Кроме того, на эмуляторах приложение можно многократно запускать автоматически, что удобно для фейковых аккаунтов или автоматизированных атак. Поэтому экспертиза ожидает, что релизное приложение обнаруживает эмулятор.

Что такое RASP

RASP (Runtime Application Self-Protection) — защитный слой, встроенный в приложение и наблюдающий за окружением во время работы. Обычно он обнаруживает:

• root и jailbreak;
• эмулятор и симулятор;
• инструменты перехвата (Frida, Xposed, Substrate и подобные);
• подключённый отладчик;
• нарушение целостности приложения (пересобранный или подписанный другой подписью APK или IPA);
• установку не из официального магазина.

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

Как мы внедрили это на практике

В нашем Flutter-приложении использована библиотека freeRASP. Схематично (точный API может отличаться в зависимости от версии библиотеки, сверяйтесь с официальной документацией):

final config = TalsecConfig(
  androidConfig: AndroidConfig(
    packageName: 'uz.example.app',
    signingCertHashes: ['<хеш релизного сертификата подписи>'],
  ),
  iosConfig: IOSConfig(
    bundleIds: ['uz.example.app'],
    teamId: '<TEAM_ID>',
  ),
  watcherMail: 'security@example.uz',
  isProd: true,
);

final callback = ThreatCallback(
  onHooks: () => showThreatScreen(),
  onPrivilegedAccess: () => showThreatScreen(),
  onSimulator: () => showThreatScreen(),
  onDebug: () => showThreatScreen(),
  onAppIntegrity: () => showThreatScreen(),
);

Talsec.instance.attachListener(callback);
await Talsec.instance.start(config);

На что мы обратили внимание:

1. Хеш подписи берётся из релизного сертификата. На нём держится проверка целостности: если APK подписан другим ключом, срабатывает onAppIntegrity. Если используется Google Play App Signing, указывайте хеш ключа подписи приложения из Play Console, а не ключа загрузки.
2. Блокирующий экран спокойный и понятный. Пользователю объясняется, что приложение не может работать в небезопасной среде, и что можно сделать.
3. isProd включается только в release-сборке. При разработке нужны эмулятор и отладчик.
4. Проверка начинается до входа в систему и продолжается во время работы.

RASP не работает в одиночку

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

• Обфускация. R8 minify для Android и для Dart-кода:

flutter build apk --release --obfuscate --split-debug-info=build/symbols

Сохраняйте папку split-debug-info — без неё отчёты о сбоях не прочитать.

• Меньше открытых строк в коде. Адреса API и другие важные значения не должны храниться в коде обычными строками, иначе их легко найти командой strings.
• Проверка на стороне сервера. Важные решения (платежи, права доступа) должны приниматься только на сервере. Любая проверка в приложении — вспомогательный слой, а не последняя линия защиты.

Проверьте сами

1. Запустите frida-server на рутованном устройстве и попробуйте подключиться к приложению — приложение должно это обнаружить.
2. Запустите release-сборку на эмуляторе Android и симуляторе iOS.
3. Распакуйте APK через apktool, пересоберите и подпишите другим ключом — приложение должно заметить нарушение целостности.
4. Попробуйте подключить отладчик.
5. Убедитесь, что на обычном устройстве нет ложных блокировок.

Вывод

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

Если хотите узнать, как ваше приложение реагирует на Frida и эмулятор, оставьте заявку на сканирование. Claude AI агент и наш специалист проверят приложение и помогут подготовить его к экспертизе.