Мобильная безопасность

За 40 минут статического анализа IPA — три захардкоженных API-ключа, endpoint внутреннего микросервиса и HMAC-секрет. Ключи работали в продакшене восемь месяцев. Потенциальный ущерб: доступ к данным 200+ тысяч клиентов и оборотные штрафы по 152-ФЗ.

Цепочка атаки: unzip IPA → otool + strings для поиска секретов → class-dump для карты методов (isJailbroken, setupCertificatePinning, apiSecret прямо в интерфейсах) → Hopper для анализа логики → Frida-хук на loginWithUsername:password: перехватывает credentials до шифрования. Медиана «времени до первого секрета» для корпоративных iOS-приложений — 25 минут.

Серверная детекция для SOC: аномальный User-Agent после обхода pinning, всплеск 4xx/5xx с одного токена, запросы с отозванными hardcoded-ключами, отсутствие App Attest-маркера. Hardening-чеклист из 10 пунктов по OWASP MASVS-RESILIENCE.

Прогоните strings и class-dump на своей production-сборке прямо сейчас — если в выводе мелькнул ключ, атакующий...

На аудите финтех-приложения трёхслойная jailbreak detection роняла objection за 200 миллисекунд — кастомные inline C-проверки вместо стандартных ObjC-методов. Liberty Lite мимо. Четыре часа на разбор механики и рабочий хук.

Анатомия проверок: файловые (NSFileManager + fopen/access), sandbox-тесты (запись в /private, вызов fork()), DYLD-анализ на frida-agent и FridaGadget. iOS Security Suite — восемь проверок, метод amIJailbroken() агрегирует результат. Frida ObjC-хук через Interceptor.attach с retval.replace(0x0): плюс vs минус в имени метода — класс vs инстанс.

Swift-модули: name mangling блокирует ObjC runtime, нужен offset через radare2 → Module.getBaseAddress + Interceptor.attach. Flutter-плагин flutter_jailbreak_detection обходится одним хуком на нативный IOSSecuritySuite.amIJailbroken(). Decision tree из четырёх шагов: objection → spawn → смена порта → бинарный патч.

Клиентский bypass без серверной валидации — декорация...

Клиент прислал OWASP MASVS v1.5.0 и попросил «пройтись по всем пунктам». Треть чеклиста помечена N/A: часть контролей непроверяема без исходного кода, часть дублирует ASVS для бэкенда. Ситуация повторяется на каждом втором engagement — версия 1.5.0 не чеклист для black box.

Маппинг восьми групп контролей на MITRE ATT&CK: STORAGE→T1552, CRYPTO→T1552.004, NETWORK→T1573, RESILIENCE→T1027. Frida-скрипт для перехвата Cipher.getInstance — если в логе DES или AES/ECB, контроль MASVS-CRYPTO не пройден. Decision tree уровней L1/L2/R: L1 для всех, L2 для финтеха, R для IP-защиты.

Что меняется в v2.0.0: MASVS-ARCH удалена, оверлапы с ASVS устранены, уровни L1/L2/R заменены на MAS Testing Profiles. Переход не решает главную проблему — клиент без threat model.

В scope-документе указывать версию явно: не «по OWASP MASVS», а «по OWASP MASVS v1.5.0».

На пентесте финтех-приложения auth-токены вытащились из Keychain одной командой — разработчики выставили kSecAttrAccessibleAlways, и токены читались на заблокированном устройстве. Обход Face ID занял шесть строк Frida-кода. Ребята полагались на безопасность iOS и не закрепили её в архитектуре.

Полный цикл: jailbreak через checkra1n/palera1n (decision tree по чипу и версии iOS), расшифровка FairPlay DRM через frida-ios-dump, проверка бинарных защит через otool (PIE, stack canaries, cryptid). SSL Pinning bypass через objection, дамп Keychain с поиском kSecAttrAccessibleAlways-элементов.

Механика обхода биометрии через хук LAContext.evaluatePolicy — почему boolean-флаг в userland всегда патчится. Где обход не работает: Keychain + kSecAccessControlBiometryAny с валидацией в Secure Enclave. Jailbreak detection bypass: от objection до кастомных Frida-скриптов.

Пока защита сводится к isJailbroken() и boolean от LAContext —...

На аудите банковского приложения ios sslpinning disable вернул хуки на семь методов — трафик в Burp не появился. Разработчики зашили проверку через нативную обёртку над BoringSSL, которую Objection не покрывает. Три часа на кастомный Frida-скрипт через SecTrustEvaluateWithError — и в первых же запросах refresh-токены с TTL 90 дней без привязки к устройству.

Методика от простого к сложному: Objection → Frida-скрипт SecTrust API → SSL Kill Switch 2 → hotspot с pf.rules для Flutter/Xamarin → реверс кастомных TLS-стеков через Ghidra. Frida Gadget для устройств без jailbreak через пересборку IPA. Таблица решений из шести методов с границами применимости.

Jailbreak через palera1n + checkm8: A9–A11, iOS 15–16.7. A12+ — только Gadget. Keychain dump через Objection: токены с kSecAttrAccessibleAlways, staging-среда с Basic Auth прямо в NSUserDefaults.

Компании вкладываются в многослойный pinning и оставляют Keychain с флагом Always. Pinning усложняет работу на пару часов, а реальный...

На пентесте финтех-приложения экспортированный ContentProvider без permission вытаскивал полную историю транзакций любого пользователя. От скачивания APK до рабочего PoC — двадцать минут. MobSF и внутренний аудит проблему пропустили: оба проверяли манифест паттернами, не анализируя логику Java-кода провайдера.

Методика от статики до динамики: jadx для анализа манифеста и поиска hardcoded-секретов, Frida для hooking и SSL pinning bypass, objection для runtime exploration. OWASP MASVS по категориям с реальными паттернами 2026 года: SharedPreferences с токенами в открытом тексте, WebView + addJavascriptInterface с @JavascriptInterface методом getAuthToken(), deeplink hijacking через кастомную URI-схему без App Links.

Decision tree из 10 условий: какой вектор выбрать под конкретные условия — от debuggable APK до нативного NDK кода. Ограничения: RASP, Play Integrity API, Flutter/Dart AOT.

Реальные баги сместились в бизнес-логику и...

На Pixel 9 с Android 16 eBPF-трассировщик перехватил на 33% больше системных вызовов, чем штатный ftrace. Overhead — не выше 3.6%. И параллельно — декодировал имена методов и типизированные аргументы из сырых Binder-транзакций. Без патчей ядра, без пересборки AOSP, без инъекций.

Binder IPC — единственный штатный канал между приложением и системными сервисами Android. Ядро видит только ioctl() с хэндлом и сырыми байтами Parcel. Малварь через прямой native ioctl() минует Framework API и все user-space хуки (Frida, BPFroid) — полностью невидима.

WOOTdroid решает это: eBPF перехватывает в ядре (обход невозможен), signature table из AIDL-интерфейсов реконструирует семантику вне процесса приложения. ISms.sendTextMessage("+7XXXXXXXXXX") вместо ioctl(7, 0xc0306201, 0x7fc3a12000).

Единственный способ увидеть что приложение реально делает — собрать стенд и трассировать руками.

Стандартный Frida-скрипт не обошёл SSL pinning — приложение использовало OkHttp3 с CertificatePinner плюс кастомную проверку целостности APK. Четыре часа на декомпиляцию и точечный хук. IDOR в платёжном API нашёлся за 15 минут после этого.

80% времени мобильного пентеста уходит на подготовку окружения, а не на поиск уязвимостей. Статья закрывает именно это: эмулятор vs физический девайс, frida-server той же версии что frida-tools, сертификат Burp в системном хранилище на Android 7+.

Decision tree SSL pinning bypass: network_security_config.xml → Objection → Frida-скрипт для OkHttp/TrustKit → frida-trace для идентификации кастомного метода → Flutter отдельно. Три уровня обхода root-detection. Таблица Frida vs Objection vs Xposed по задачам.

Root-detection и SSL pinning останавливают ленивого атакующего. Серверное API остаётся дырявым.

CVSS 9.8 в Telegram: zero-click RCE через стикер, который вы даже не открывали

Вам прислали стикер. Вы его не открывали. Вы даже не заходили в чат. Но код уже выполнился — Telegram распарсил медиа в фоне, и этого хватило.

В статье — полный технический разбор ZDI-CAN-30207: декомпозиция CVSS-вектора, реконструкция kill chain через медиа-парсеры (libwebp, rlottie, libvpx), анализ поверхности атаки по платформам и разбор спора между ZDI и Telegram, который отрицает наличие бага. Внутри — готовые Sysmon-конфиги, YARA-правила для кеша стикеров, Frida-хуки для перехвата парсинга и Wireshark-фильтры.

Практическое руководство: от немедленных мер защиты до самостоятельного фаззинга — для security-инженеров, пентестеров и исследователей уязвимостей.

[size] Сколько защиты нужно мобильному приложению, чтобы его не разобрали за один вечер? Вопрос неприятный, но очень прикладной. Если клиент после релиза слишком хорошо читается, спокойно цепляется во время выполнения и без особой боли ставится под сетевое наблюдение, дальше его уже начинают разбирать по слоям.

В тексте собран нормальный защитный контур для мобильного клиента: модель угроз, проверки на root и jailbreak, обфускация, контроль целостности, RASP, pinning, работа с хранилищем и самопроверка. Без воды и без иллюзий про одну волшебную защиту, которая всё закроет.

По пути разберём, где приложение обычно сыпется под нормальным разбором, почему отдельные меры часто живут слишком недолго и как собрать защиту так, чтобы клиент не слишком охотно объяснял, как он устроен, что проверяет и где у него слабые места.[/size]