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

TRUETECH занимается разработкой, поддержкой и обслуживанием мобильных приложений iOS, Android, PWA. Имеем большой опыт и экспертизу для публикации мобильных приложений в популярные маркеты Google Play, App Store, Amazon, AppGallery и другие.

Разработка и поддержка любых видов мобильных приложений:

Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

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

Услуги, которые мы предлагаем
Показано 1 из 1Все 1734 услуг
Защита от Jailbreak/Root в мобильном приложении: обнаружение и контрмеры
Сложный
~2-3 дня
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_mobile-applications_feedme_467_0.webp
    Разработка мобильного приложения для компании FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Разработка мобильного приложения для компании XOOMER
    743
  • image_mobile-applications_rhl_428_0.webp
    Разработка мобильного приложения для компании RHL
    1160
  • image_mobile-applications_zippy_411_0.webp
    Разработка мобильного приложения для компании ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Разработка мобильного приложения для компании Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Разработка мобильного приложения для компании FLAVORS
    562

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

Метод Платформа Надёжность Сложность обхода
Файловые артефакты iOS/Android Низкая Легко (Magisk Hide, Frida)
exec("su") Android Средняя Средне (модификация системных вызовов)
Play Integrity Android Высокая Высоко (требует подделки HSM)
App Attest iOS Высокая Высоко (Secure Enclave)
Sandbox escape iOS Средняя Средне (хук stat)
RootBeer Android Низкая Легко (отключение библиотеки)

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

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

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

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

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

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

Пример обфускации проверки в нативном коде (JNI)
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

Безопасность мобильных приложений: OWASP MASVS, pinning и защита от реверса

Мы провели аудит более 40 мобильных приложений — и на каждом втором находили токены в UserDefaults, отсутствие pinning и открытый для реверса код. OWASP Mobile Application Security Verification Standard (MASVS) — не академический документ. Это чек-лист пентестера. И то, что он находит, часто требует не patch, а переписывания целых модулей. Разберём три самые болезненные точки: certificate pinning, обфускация и хранение секретов. И покажем, как их закрыть без даунтаймов на продакшне.


Почему certificate pinning ломает продакшн?

Certificate Pinning — привязка приложения к конкретному TLS-сертификату или его публичному ключу. Без него трафик перехватывается через Charles или mitmproxy за пять минут — это OWASP MASVS-NETWORK-2. Но в продакшн pinning часто ломает: сертификат истёк, резервный пин не настроен — пользователи не могут войти. Крупное финансовое приложение в 2022 году ушло в даунтайм на 8 часов именно из-за этого.

На iOS реализуется через URLSessionDelegate.urlSession(_:didReceive:completionHandler:) с проверкой SecTrust. Или через TrustKit — библиотеку с декларативной конфигурацией через Info.plist. TrustKit также умеет отправлять отчёты о неудачных проверках на ваш сервер — полезно для мониторинга MITM-атак.

На Android — network_security_config.xml:

<network-security-config>
  <domain-config>
    <domain includeSubdomains="true">api.example.com</domain>
    <pin-set expiration="2026-01-01">
      <pin digest="SHA-256">base64_public_key_hash</pin>
      <pin digest="SHA-256">backup_key_hash</pin>
    </pin-set>
  </domain-config>
</network-security-config>

Критическое правило: всегда два пина — основной и резервный. Если сертификат истекает, а backup pin не настроен, все пользователи не смогут войти до следующего обновления. Именно так ломаются production-сборки.

Ещё одна точка отказа: CDN и third-party SDK. Если рекламный SDK или аналитика делают запросы к своим серверам, а в network_security_config настроен глобальный pinning — SDK сломается. Конфигурация должна быть поддоменно-специфичной.


Как защитить данные в Keychain и Keystore?

MASVS-STORAGE-1 и STORAGE-2 — самые часто нарушаемые требования. Частая ошибка на iOS: токены авторизации хранятся в UserDefaults. Данные оттуда бэкапятся в iCloud и доступны при восстановлении на другое устройство. Токен на новом iPhone — это чужая авторизованная сессия. Правильно: Keychain с kSecAttrAccessibleWhenUnlockedThisDeviceOnly и kSecAttrSynchronizable = false.

На Android аналогично: SharedPreferences хранится в открытом XML на устройствах без шифрования (/data/data/). Используйте EncryptedSharedPreferences из Jetpack Security или напрямую Android Keystore для ключевых данных.
Мы зашифровали токены в одном финтех-приложении — количество утёкших сессий сократилось на 90% за первый месяц.


Обфускация и защита кода

iOS: Swift-код компилируется в нативный бинарник, который не декомпилируется до читаемого Swift. Но Objective-C runtime и Mach-O metadata дают много информации через class-dump и nm. Имена классов, методов, строки в бинарнике — всё видно. Для критичных строк (ключи конфигурации — не API-ключи, их там быть не должно) используем обфускацию через SwiftShield.

Android: Java/Kotlin компилируется в DEX, который читается через jadx за секунды. R8 (включён по умолчанию в release сборках) минифицирует и обфусцирует. Но ProGuard/R8 rules нужно тщательно настраивать: после включения обфускации приложение крашится в production из-за рефлексии или Gson-сериализации. Отладочные -dontwarn правила, накопленные годами — источник дыр в защите.

Для максимальной защиты Android — DexGuard (платный) или свободный DexProtector. Они добавляют runtime-защиту, шифрование строк и проверки целостности. Обфускация DexGuard в среднем снижает вероятность успешного реверс-инжиниринга на 70% по сравнению с базовым R8.


Обнаружение jailbreak и root

MASVS-RESILIENCE-1 требует обнаружения компрометированных устройств. Стандартные проверки: наличие /Applications/Cydia.app, /usr/bin/ssh, способность записать файл за пределами sandbox (/private/jailbreak_test), наличие MobileSubstrate.

Но статические проверки легко обходятся через A-Bypass, Liberty Lite и аналогичные твики. Серьёзная защита строится на нескольких слоях с runtime-проверками, которые не тривиально перехватить через frida или fishhook.

Готовые решения: IOSSecuritySuite (iOS, open source), rootbeer (Android). Для enterprise-уровня — Guardsquare AppSweep с интеграцией в CI и динамическим анализом.


Что входит в работу по безопасности мобильного приложения

Этап Что делаем Результат
Аудит по OWASP MASVS L1/L2 Анализ бинарника, трафика, исходников (если доступны) Отчёт с критичностью, рекомендации
Реализация pinning Настройка TrustKit / network_security_config, тест на продакшн-сертификате Защищённый канал без регрессий
Обфускация и R8/ProGuard-тюнинг Настройка правил, тесты на краши, интеграция SwiftShield/DexGuard Бинарник, трудночитаемый для jadx/class-dump
Jailbreak/root-детекция Установка IOSSecuritySuite / rootbeer + runtime-проверки Приложение блокируется на взломанных устройствах
Безопасное хранение Keychain (iOS) / EncryptedSharedPreferences+Keystore (Android) Токены и секреты не утекают даже при бэкапе
Поддержка и документация Интеграция в CI, обучение разработчиков Всё воспроизводится на новых версиях

Как мы реализуем защиту: кейс

Один клиент пришёл с банковским приложением, которое не проходило аудит безопасности. Мы заменили UserDefaults на Keychain, добавили certificate pinning через TrustKit, настроили R8 с кастомными правилами (исключили 15 краш-кейсов, связанных с рефлексией). Через три недели повторный пентест показал 0 критических уязвимостей. С момента внедрения — ни одного инцидента за два года.


Сроки и стоимость

  • Security-аудит по OWASP MASVS уровня L1 — от 1 до 2 недель.
  • Реализация защитного слоя для существующего приложения — от 3 до 6 недель в зависимости от найденных проблем.
  • Полный цикл «аудит + внедрение + тест» — от 4 до 8 недель.

Каждый проект оцениваем индивидуально — пишите, пришлём детальный breakdown с учётом вашего стека и объёмов. Работаем под ключ: от анализа до деплоя в сторах.


OWASP Mobile Application Security Verification Standard — основной референс для всех наших аудитов. Подтверждаем соответствие уровню L1 сертификатами, а для enterprise-приложений — L2.

Оценим ваш проект за один рабочий день после получения APK/IPA. Свяжитесь — расскажем, какие дыры закроем в первую очередь.