Защита мобильного приложения от 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 дня.







