Защита мобильного приложения от Jailbreak/Root-обнаружение

TRUETECH занимается разработкой, поддержкой и обслуживанием мобильных приложений iOS, Android, PWA. Имеем большой опыт и экспертизу для публикации мобильных приложений в популярные маркеты Google Play, App Store, Amazon, AppGallery и другие.
Разработка и поддержка любых видов мобильных приложений:
Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

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

Предлагаемые услуги
Показано 1 из 1 услугВсе 1735 услуг
Защита мобильного приложения от Jailbreak/Root-обнаружение
Сложная
~2-3 рабочих дня
Часто задаваемые вопросы
Наши компетенции:
Этапы разработки
Последние работы
  • image_mobile-applications_feedme_467_0.webp
    Разработка мобильного приложения для компании FEEDME
    756
  • image_mobile-applications_xoomer_471_0.webp
    Разработка мобильного приложения для компании XOOMER
    624
  • image_mobile-applications_rhl_428_0.webp
    Разработка мобильного приложения для компании RHL
    1052
  • image_mobile-applications_zippy_411_0.webp
    Разработка мобильного приложения для компании ZIPPY
    947
  • image_mobile-applications_affhome_429_0.webp
    Разработка мобильного приложения для компании Affhome
    862
  • image_mobile-applications_flavors_409_0.webp
    Разработка мобильного приложения для компании FLAVORS
    445

Защита мобильного приложения от Jailbreak/Root-обнаружение

Jailbreak и root снимают ограничения песочницы ОС. На jailbroken iOS приложение теряет гарантии изоляции Secure Enclave, Frida может хукать любые методы, файловая система читается без ограничений. На рутованном Android — аналогично, плюс возможность модификации системных библиотек через Magisk модули. Для банковских, медицинских и корпоративных приложений работа на таких устройствах — неприемлемый риск.

Что проверяем на Android

Три независимых уровня проверки дают лучший результат, чем один «серебряный» метод.

Файловые артефакты. Наличие /su, /system/bin/su, /system/xbin/su, /sbin/su — наиболее старый способ. Прячется через Magisk DenyList, но срабатывает на устройствах с более старыми root-решениями.

Попытка выполнить su. Runtime.getRuntime().exec("su") — если не бросает исключение и не возвращает ненулевой код сразу, процесс su существует. Надёжнее файловой проверки, хуже обходится.

Google Play Integrity API. Самый надёжный вариант на сегодня. Сервер запрашивает у Google вердикт по токену устройства:

  • MEETS_DEVICE_INTEGRITY — устройство прошло проверку целостности Android
  • MEETS_STRONG_INTEGRITY — аппаратная аттестация, труднее подделать
  • MEETS_BASIC_INTEGRITY — минимальный уровень

На рутованных устройствах с Magisk без дополнительной настройки Play Integrity часто возвращает MEETS_BASIC_INTEGRITY или ниже. С MagiskHide/DenyList современных версий — может пройти MEETS_DEVICE_INTEGRITY. Абсолютной защиты нет, но это серьёзный барьер.

RootBeer — популярная open-source библиотека, агрегирует несколько проверок. Подходит для базового уровня, но её наличие в APK само по себе сигнал для атакующих — легко ищется в jadx и отключается. Для серьёзных приложений — только как дополнение к нативным проверкам.

Что проверяем на iOS

Файловые признаки. /Applications/Cydia.app, /usr/sbin/sshd, /etc/apt, /private/var/lib/apt — артефакты Cydia и Sileo (пакетных менеджеров jailbreak). Checkra1n оставляет /var/checkra1n.dmg. Следует проверять через C API (stat(), access()), а не через FileManager Swift — Objective-C bridging легче хукается.

Sandbox escape тест. На jailbroken устройстве приложение может писать за пределы своего контейнера. Пробуем создать файл в /private/:

let path = "/private/jailbreak_test_\(UUID().uuidString)"
let result = FileManager.default.createFile(atPath: path, contents: nil)
// На чистом устройстве — false, на jailbroken — true

Наличие Cydia URL scheme. UIApplication.shared.canOpenURL(URL(string: "cydia://")!) — простая и часто обходимая проверка, но в связке с другими добавляет уровень.

Apple App Attest. Аналог Play Integrity для iOS. DCAppAttestService генерирует attestation key в Secure Enclave, сервер верифицирует через Apple API. На jailbroken устройстве App Attest часто не проходит — нарушена цепочка доверия.

Обход детектирования и контрмеры

Проблема в том, что все проверки в userspace обходятся инструментами уровня Frida — хукается возвращаемое значение метода. JailMonkey.isJailBroken() возвращает false независимо от состояния устройства за одну строчку Frida-скрипта.

Три принципа, усложняющих обход:

Проверки в нативном коде (JNI/NDK). Нативный код сложнее хукать из скрипта, чем Java/Kotlin. Помещаем критичные проверки в .so библиотеку. Имена функций обфусцируем.

Размазанная проверка. Не одна функция isRooted() которую патчат в одном месте, а десятки небольших проверок, разбросанных по коду, результаты которых XOR-комбинируются в runtime. Патчить дороже.

Серверная валидация. Клиент передаёт на сервер токен от Play Integrity / App Attest. Сервер принимает решение. Злоумышленник не может подделать подпись Google/Apple без физического доступа к HSM.

Что делать при обнаружении

Жёсткое завершение работы — плохая UX-практика и неэффективная безопасность (приложение просто не запустится, атакующий исправит проверку). Лучше: деградировать функциональность (скрыть чувствительные операции), логировать событие на сервере с device fingerprint, инвалидировать сессию при следующем сервер-запросе.

Сроки реализации базового набора проверок (файловые артефакты + native checks + Play Integrity/App Attest) — 2–3 дня на платформу. Интеграция серверной валидации с обработкой результатов — ещё 1–2 дня.