Защита от Jailbreak/Root в мобильном приложении: обнаружение и контрмеры

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

Jailbreak и root снимают ограничения песочницы ОС — для банковских, медицинских и корпоративных приложений работа на таких устройствах неприемлемый риск. На jailbroken iOS приложение теряет гарантии изоляции Secure Enclave, Frida может хукать любые методы, файловая система читается без ограничений. На рутованном Android — аналогично, плюс возможность модификации системных библиотек через Magisk модули. Мы более 5 лет помогаем компаниям защищать мобильные приложения от таких угроз. Реализуем обнаружение jailbreak/root «под ключ»: от анализа архитектуры до интеграции серверной валидации. Оценим ваш проект бесплатно — напишите нам. За годы практики мы накопили опыт выявления и обхода типовых ошибок в реализации защиты — от неправильного выбора проверок до уязвимостей в серверной валидации. Предлагаем комплексное решение, снижающее финансовые риски утечки данных.

Как работает обнаружение jailbreak/root?

Детектирование строится на нескольких уровнях: проверка файловых артефактов, попытка выполнения привилегированных команд, использование аппаратных средств аттестации (Play Integrity, App Attest). Ни один метод не даёт 100% гарантии, но их комбинация создаёт серьёзный барьер для атакующего.

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

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

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. Абсолютной защиты нет, но это серьёзный барьер.

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

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

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

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

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

Файловые признаки. /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://")!) — простая и часто обходимая проверка, но в связке с другими добавляет уровень.

Сравнение методов на iOS и Android

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

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

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

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

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

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

extern "C" JNIEXPORT jboolean JNICALL Java_com_your_app_NativeUtils_checkRootNative(JNIEnv* env, jobject thiz) { // Проверка наличия /system/bin/su через stat struct stat st; int result = stat("/system/bin/su", &st); // XOR с константой для усложнения статического анализа return (result == 0) ^ 0x1A; } 

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

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

Что входит в работу

При заказе услуги вы получаете:

• Аудит текущей архитектуры безопасности приложения;
• Реализацию набора проверок (файловые артефакты + native checks + Play Integrity/App Attest);
• Интеграцию серверной валидации (токены проверяются на бэкенде);
• Обфускацию нативного кода (JNI) для усложнения реверс-инжиниринга;
• Документацию по поддержке и доработке;
• Тестирование на реальных jailbroken/rooted устройствах;
• Поддержка в течение месяца после сдачи.

Сроки реализации базового набора — 2–3 дня на платформу. Интеграция серверной валидации — ещё 1–2 дня. Стоимость рассчитывается индивидуально под ваш проект. Мы работаем более 5 лет, реализовали более 50 проектов в сфере мобильной безопасности.

Google Play Integrity Documentation