Сколько защиты нужно мобильному приложению, чтобы его не разбирали за один вечер?
Обычно к этому моменту команда уже что-то сделала. Включили R8, добавили pinning, раскидали проверки на root и jailbreak, убрали часть чувствительных строк с поверхности. На показе всё выглядит аккуратно. Потом приложение попадает в руки человеку с jadx, Frida и нормальным запасом времени - и быстро становится ясно, что защиты в клиенте много, а стойкости мало.
Такое приложение редко ломают одним приёмом. Его разбирают по слоям. Сначала смотрят, что осталось в релизной сборке. Потом цепляются к выполнению, трогают проверки, читают трафик, смотрят, где клиент лишнего доверяет устройству и где внутри лежит то, чему там делать нечего. В финтехе это быстро упирается в платёжные сценарии, токены, клиентскую логику и удобную площадку для автоматизации. В играх - в читы, ботов, подмену поведения клиента, обход ограничений и серую монетизацию.
Поэтому защиту мобильного клиента почти бесполезно собирать как набор разрозненных мер. Если приложение держится на двух-трёх точках, его и расковыряют по этим же двум-трём точкам. Рабочая схема начинается там, где клиент сопротивляется целиком: код после сборки читается хуже, сетевой слой не раскрывается с наскока, рантайм трогать дороже, а чувствительные куски не лежат в удобном виде.
Regulatory: ЦБ требования
Для банковского контура этот разговор давно стал прикладным. Когда мобильный клиент участвует в аутентификации, подтверждении операций и доступе к данным пользователя, к его целостности относятся уже без поблажек. Смотрят не только на сервер и прикладной интерфейс, но и на сам клиент: насколько легко его разобрать, перепаковать, отладить, подменить и использовать как обходной путь к прикладной логике.Threat Model
У мобильного реверса цель обычно довольно приземленная. Не "взломать приложение целиком", а быстро ответить на три вопроса: что лежит в клиенте, что можно подменить на рантайме и где перехватывается сетевой контур. Если на эти три вопроса приложение отвечает слишком охотно, дальше его уже начинают разбирать по кускам - без особой спешки, но вполне уверенно.Чтобы не расползаться в десяток частных сценариев, модель угроз здесь удобнее держать в трёх плоскостях:
| Плоскость | Что пытаются вытащить | Где обычно проседает защита |
|---|---|---|
| Static | код, строки, ключи, API-маршруты, фичи | слабая обфускация, болтливая сборка, секреты в клиенте |
| Dynamic | проверки на root/jailbreak, бизнес-логику, антифрод, pinning | хрупкие runtime-проверки, слабая защита от подмены вызовов |
| Network | токены, запросы, серверную логику, удобные точки для повтора запросов | формальный pinning, лишнее доверие к клиенту |
Static analysis: jadx, Ghidra
Статический разбор почти всегда идёт первым. Просто потому, что это дёшево и быстро. Если apk после сборки всё ещё нормально читается, названия классов торчат, строки не спрятаны, сетевые маршруты видны, а клиентская логика раскладывается без особого напряга, у приложения уже плохой старт.
Ссылка скрыта от гостей
до сих пор рассматривает reverse engineering и static analysis как базовую часть оценки устойчивости mobile-клиента.jadx здесь полезен тем, что быстро даёт читаемую картину Android-клиента: структура пакетов, ресурсы, строки, сетевые вызовы, флаги функций, логика проверок. Ghidra чаще подключают там, где нужно лезть глубже - в native-часть, библиотеку, криптографический код, JNI-мосты, куски, которые уже плохо видны на уровне обычного декомпила. И вот тут обычно выясняется неприятное: приложение может выглядеть защищённым, но при этом слишком много о себе рассказывать. В коде остаются маршруты, сообщения об ошибках, внутренние имена, ветки антифрода, условия блокировок, ключевые строки и всё то, что потом сильно помогает уже на следующем этапе.Для защиты из этого вытекает простая вещь. Обфускация нужна не ради галочки и не ради красивого слова в чеклисте. Её задача - сломать дешёвое чтение клиента. Если приложение после сборки всё ещё объясняет свою внутреннюю механику с первого взгляда, дальнейшие слои защиты уже стартуют в плохой позиции.
Dynamic: Frida, Xposed, Magisk
Динамика начинается там, где статический разбор уже дал карту местности. Дальше атакующему не обязательно понимать весь клиент. Ему достаточно понять, какие проверки можно обойти, где зацепиться за рантайм и как подменить поведение без полной пересборки приложения.Frida для этого до сих пор остаётся одним из главных инструментов: это полноценный фреймворк динамической инструментации, который умеет работать с Android и iOS и встраиваться в живое приложение во время выполнения. Xposed в исходном виде уже не центр вселенной, но сам класс zygote-based и module-based подмен никуда не делся - в Android-мире он давно живёт через производные и соседние механизмы. Magisk здесь важен не как "root ради root", а как удобный рантайм-контур, в котором приложение начинают проверять на устойчивость к модифицированному устройству и дополнительным модулям. Актуальная документация самого Magisk по-прежнему описывает его как systemless root solution.Самая частая ошибка у команд здесь одна и та же: защитные проверки живут слишком локально. Один метод проверил root. Второй посмотрел на debugger. Третий попытался найти Frida-сигнатуру. Если каждая такая проверка живёт отдельно и легко снимается хуком, приложение в рантайме быстро теряет жёсткость. Поэтому anti-tampering на этом уровне всегда упирается в то, насколько дорого обойдётся подмена поведения, а не в сам факт наличия одной проверки.
Network: Burp, mitmproxy
Сетевой слой часто недооценивают, потому что он кажется внешним по отношению к клиенту. На деле это одна из самых полезных точек разборки приложения. Если трафик читается, если pinning сделан формально, если клиент перегружен доверием к собственным параметрам, дальше становится проще всё: от понимания API до replay, автоматизации и выноса клиентской логики наружу.OWASP MASTG отдельно держит interception proxy и network monitoring как базовые техники мобильного тестирования. Там логика простая: как только приложение встаёт в удобный для анализа сетевой контур, его поведение начинает читаться гораздо лучше.
Burp и mitmproxy в этой модели нужны не как "инструменты атаки", а как способ увидеть, что клиент реально отправляет, как он оформляет запросы, где держит токены, насколько полагается на локальные проверки и как переживает попытку встать посередине канала.Здесь, кстати, у команд часто ломается интуиция. Многим кажется, что одного pinning уже достаточно, чтобы закрыть сетевой слой. На практике pinning сам по себе закрывает далеко не всё. Он может быть хрупким, локальным, легко снимаемым на рантайме или вообще жить в одном месте, пока половина сетевой логики ходит по другому стеку. Поэтому network threat model в мобильной защите нужен не отдельно от anti-tampering, а внутри него. Если приложение легко ставится под наблюдение на проводе, остальные слои защиты быстро начинают светиться сильнее, чем хотелось бы.
Root/Jailbreak Detection
С проверками на root и jailbreak обычно одна беда: от них ждут слишком многого. Переоценивают, когда ждут, что одна проверка сама отсечёт весь грязный рантайм. Недооценивают, когда держат её как формальную галочку рядом с pinning и обфускацией. Это полезный слой, но его ценность целиком зависит от того, как он встроен в клиент и что сервер делает с этим сигналом.
SafetyNet → Play Integrity API
На Android старую линию с SafetyNet уже всерьёз не обсуждают. Google давно перевёл акцент на Play Integrity API, а SafetyNet Attestation уже считается устаревшим. Это важная точка, потому что до сих пор полно мобильных клиентов, где защита осталась на старой логике, а в голове у команды всё ещё живёт устаревшая модель attestation.Play Integrity возвращает не один флаг, а набор признаков. На практике интересны три зоны: целостность приложения, состояние устройства и контекст установки. То есть проверяется не только условный root, а более широкая связка - тот ли это бинарь, в каком окружении он запущен и насколько эта среда вообще похожа на нормальный Android-клиент из экосистемы Google Play. Отсюда и нормальная инженерная логика: такой сигнал надо разбирать на сервере и привязывать к риску конкретного действия, а не просто падать локально с тостом про compromised device.
Именно здесь у многих приложений и начинается просадка. Сам API подключён, verdict приходит, а дальше приложение почти ничего с ним не делает. Или делает слишком грубо: рубит весь поток на одном результате, не различает обычный low-trust рантайм и реально опасный сценарий, не учитывает чувствительность операции. В итоге защита либо шумит и мешает нормальным пользователям, либо живёт как декоративный сигнал, который никто особенно не уважает.
iOS DeviceCheck
На iOS разговор уже странно вести вокруг одного DeviceCheck. Сам по себе DeviceCheck нужен, но если цель - именно доверие к экземпляру приложения, почти всегда приходится смотреть шире и подтягивать App Attest. Apple прямо описывает DeviceCheck как механизм для снижения мошеннического использования сервиса и отдельно даёт App Attest как способ подтверждать легитимность конкретного инстанса приложения перед сервером. Проще говоря, без App Attest этот слой сегодня выглядит уже слабее, чем от него обычно ждут.На iOS это важно по одной причине: локальный jailbreak detection сам по себе быстро упирается в пределы надёжности. Можно собрать десяток признаков, проверить файловую систему, окружение, динамические библиотеки, отладку, странное поведение sandbox. Всё это имеет смысл. Но если решение живёт только в клиенте, оно слишком близко к тому же рантайму, который и пытаются подменить. Поэтому в нормальной схеме DeviceCheck и App Attest полезны именно как мост к серверу, где уже можно принимать решение по сессии, действию и риску.
Bypass и counter-bypass
У root/jailbreak detection старая проблема: любая отдельная проверка живёт недолго, если она изолирована и читается с первого взгляда. Это касается и поиска артефактов root, и проверок debugger, и сигнатур на Frida, и локального поведения при подозрительном окружении. Как только защита слишком линейна, её начинают снимать по одному слою - где-то статикой, где-то рантаймом, где-то просто переигрывая клиент на стороне сервера. Поэтому нормальный counter-bypass начинается не с увеличения числа эвристик, а с более неприятной для атакующего сборки всей схемы.Рабочий подход здесь обычно выглядит так:
- локальные проверки дают быстрый сигнал и поднимают цену грубому разбору;
- attestation уходит на сервер;
- чувствительные действия получают отдельную политику;
- одно срабатывание не решает всё, но и не пропадает в пустоту;
- признаки компрометированного рантайма коррелируются с pinning, integrity checks и поведением сессии.
Code Obfuscation
Обфускацию в мобильной разработке часто либо переоценивают, либо используют слишком лениво. В первом случае от неё ждут, что она сама закроет реверс. Во втором - включают дефолтный минимум и успокаиваются. Оба варианта плохие. Нормальная обфускация не делает клиент неразбираемым. Она ломает дешёвый разбор, режет читаемость, путает карту приложения и заставляет тратить на анализ уже не вечер, а заметно больше. Для мобильного anti-tampering это вполне практичная задача.
Android: R8 → DexGuard
На Android базовая линия давно начинается с R8. Это штатная часть нормальной сборки, если приложение вообще пытаются прятать от дешёвого декомпила. R8 вычищает лишний код, переименовывает сущности, ужимает то, что можно ужать, и в целом делает картину после сборки менее разговорчивой. Но здесь важно не обманываться: дефолтный R8 чаще всего даёт именно базовый шум, а не серьёзную защиту. Если приложение большое, логика читается через архитектурные слои, а чувствительные точки лежат слишком явно, одного этого мало.Дальше обычно и начинается развилка. Если задача ограничивается тем, чтобы не светить внутреннюю структуру с первого взгляда, R8 хватает. Если нужно поднимать цену реверса заметно выше - особенно в финтехе, играх, SDK и приложениях с дорогой клиентской логикой, - одной штатной минимизации уже мало. Там и появляются тяжёлые инструменты вроде DexGuard, где речь идёт уже не просто о переименовании, а о более плотном hardening: string encryption, усложнение control flow, работа с ресурсами, native-частью и слоями рантайм-защиты.
Здесь есть неприятный факт: плохая обфускация почти всегда хуже, чем кажется команде. Пока приложение после сборки всё ещё нормально читается в jadx, пока сетевые маршруты лежат в строках, а критичные классы угадываются по названию, никакой "у нас обфускация включена" особенно не помогает. Для Android этот слой работает только тогда, когда его собирают под реальную карту приложения, а не под дефолтный чекбокс в build-конфиге.
iOS: Swift obfuscation
На iOS разговор обычно сложнее, потому что там меньше ощущения, будто всё решается одним инструментом. Swift сам по себе уже даёт другой профиль сборки, чем Android-мир с apk, dex и Java/Kotlin-кодом. Из-за этого у команд часто рождается ложное чувство, что приложение и так достаточно "неудобное" для чтения. На практике это быстро заканчивается, если в бинаре слишком хорошо читаются символы, строки, внутренняя логика и точки принятия решений.У Swift-обфускации поэтому задача та же, что и на Android, просто решается она более кусочно. Нужно сокращать читаемость бинаря, вычищать лишнюю семантику из символов, не оставлять приложение слишком разговорчивым на уровне строк, логики ветвлений и чувствительных имён. Здесь почти всегда нет одной серебряной кнопки, которая всё сделает за команду. Обычно собирают комбинацию: дисциплина по символам, работа с релизной сборкой, вынос лишней информации из клиента и отдельный контроль того, что реально осталось видно после сборки.
У iOS здесь старая проблема: команды часто думают про безопасность исходников, а не про безопасность конечного бинаря. А реверсер смотрит именно на то, что уехало на устройство. Если приложение после релиза всё ещё спокойно раскрывает структуру экранов, сетевые имена, внутренние проверки и куски чувствительной логики, значит слой anti-tampering уже стартует с плохой позиции.
String encryption
Строки - это вообще один из самых дешёвых путей внутрь приложения. Пока код ещё толком не прочитан, строки уже дают полкарты: URL, флаги функций, сообщения об ошибках, заголовки, внутренние имена, части бизнес-логики, признаки антифрода, название SDK, куски pinning, локальные проверки, условия блокировок. Из-за этого string encryption - не декоративная надстройка, а вполне рабочий слой защиты.Здесь важен баланс. Если шифровать всё подряд без разбора, приложение можно превратить в тяжёлую и хрупкую сборку, которую потом сама команда будет чинить неделями. Если не шифровать ничего, клиент слишком много расскажет о себе в первые же минуты разбора. Поэтому нормальный подход обычно идёт от приоритета: что именно нельзя оставлять в читаемом виде, какие строки дают слишком хороший контекст для реверса, какие фрагменты прямо подводят к чувствительным проверкам и сетевой логике.
Integrity Checks
Signature verification
С проверкой подписи у мобильных клиентов старая проблема: её часто держат как локальную формальность. Приложение один раз сравнило сертификат, ничего подозрительного не увидело и пошло дальше. Для реальной защиты этого мало. Подпись здесь нужна не ради самой подписи, а как точка контроля целостности сборки. Если клиент перепаковали, пересобрали под другой сертификат или подменили путь доставки, приложение и сервер должны это увидеть не как косметический сбой, а как смену доверенного экземпляра.На Android эта логика особенно важна. Если приложение само не знает, каким релизным сертификатом оно должно быть подписано, защита быстро превращается в декорацию. Нормальный сценарий здесь простой: клиент проверяет свой signing certificate, сервер отдельно знает, какой подписи он доверяет, а рискованные операции не должны спокойно выполняться при несовпадении. Иначе перепакованный клиент живёт слишком долго.
Код:
val pm = context.packageManager
val pkgInfo = pm.getPackageInfo(
context.packageName,
PackageManager.GET_SIGNING_CERTIFICATES
)
val signingInfo = pkgInfo.signingInfo
val signatures = signingInfo.apkContentsSigners
val cert = signatures.first().toByteArray()
val digest = MessageDigest.getInstance("SHA-256")
.digest(cert)
.joinToString("") { "%02x".format(it) }
if (digest != EXPECTED_CERT_SHA256) {
throw SecurityException("Unexpected app signature")
}Anti-debugging:
Anti-debugging почти всегда ломается в одном и том же месте: от него ждут, что одна проверка сама выключит весь динамический разбор. На деле он работает только как слой трения. Задача здесь не в том, чтобы сделать отладку невозможной. Задача в том, чтобы она стала дороже, шумнее и менее удобной.На iOS базовая линия обычно крутится вокруг ptrace, проверки флагов процесса, нетипичного поведения task ports и косвенных признаков дебаггера. На Android набор другой, но логика та же: флаги debuggable, трассировка, остановки, подозрительные свойства среды, следы instrumentation. Проблема начинается там, где все проверки собраны в один аккуратный блок и живут слишком линейно. Такой слой снимается быстро.
Поэтому anti-debugging имеет смысл только в нормальной сборке:
- несколько разных проверок;
- разнесение по коду, а не одна точка входа;
- реакция не только локально, но и в серверной логике;
- связка с integrity checks и runtime-сигналами.
Emulator detection
С эмуляторами история ещё более грязная. Простая эвристика вроде одного свойства устройства или пары строк в build-профиле давно ничего не стоит. Нормальный эмуляторный контур умеет маскироваться, а плохая проверка быстро начинает бить по тестовым устройствам, QA и внутренним стендам.Из-за этого emulator detection почти никогда не стоит делать жёстким и одиночным. Он полезен как сигнал, но плох как единственный критерий блокировки. Обычно смотрят на набор признаков: модель устройства, свойства окружения, сенсоры, файловые артефакты, сетевую картину, поведение telephony-слоя, consistency между системными полями. Смысл не в том, чтобы найти один идеальный флажок. Смысл в том, чтобы понять, насколько среда похожа на реальное устройство, и привязать это к риску операции.
RASP
RASP в мобильной защите обычно вспоминают в тот момент, когда команда уже поняла неприятную вещь: статический hardening сам по себе не дожимает рантайм. Приложение можно неплохо спрятать на уровне сборки, но если его потом спокойно цепляют вживую, снимают проверки, переигрывают контрольные точки и смотрят, как оно работает изнутри, одного слоя обфускации уже мало.Ровно здесь и появляется RASP. Его задача не в том, чтобы заменить весь остальной hardening, а в том, чтобы жить внутри самого приложения и следить за тем, что происходит с ним во время выполнения. Подцепили инструментирование, пошли в дебаг, устройство выглядит слишком грязно, integrity поплыл, память или кодовая ветка ведут себя не так, как ожидалось - приложение должно хотя бы заметить это раньше, чем поздно.
Promon, Guardsquare
Promon и Guardsquare здесь обычно всплывают не случайно. Это уже не история про "добавили пару проверок руками", а про тяжёлый промышленный слой защиты, который встраивается в мобильный клиент и работает именно на уровне рантайма. Их имеет смысл обсуждать там, где приложение уже перешло из обычного hardening в зону, где нужно не просто усложнить реверс, а постоянно держать защиту внутри исполняемого клиента.С инженерной точки зрения оба класса решений решают похожую задачу. Они пытаются закрыть самые неприятные зоны рантайма:
- инструментирование;
- отладку;
- подмену логики;
- hooking;
- tampering сборки;
- работу на подозрительном устройстве;
- часть попыток снять или обойти защитные проверки на ходу.
Из-за этого RASP особенно хорошо ложится в финтех, gaming, супераппы, SDK и вообще в те мобильные клиенты, где бизнес-логика или антифрод на стороне клиента стоят дорого. Если приложение простое, чувствительного в нём мало, а клиент не держит на себе критичных решений, такой слой может оказаться слишком тяжёлым. Если же клиент реально является частью доверенной логики продукта, RASP уже выглядит вполне уместно.
Inline protection
Самая частая ошибка с RASP - воспринимать его как отдельный внешний модуль, который "добавили" в приложение. Тогда защита живёт сбоку и снимается примерно так же: нашли слой, поняли его границы, начали обходить как отдельный компонент. Нормальная схема работает иначе. Защита должна быть вплетена в приложение так, чтобы рантайм-проверки не выглядели одной аккуратной дверью, через которую проходит весь контроль.Отсюда и смысл inline protection. Проверки на tampering, debugger, instrumentation, root/jailbreak, integrity и сетевой контур должны жить не в одном демонстрационном блоке, а в нескольких местах сразу, рядом с важными участками логики. Там, где приложение принимает чувствительное решение, там же должен жить и кусок контроля. Иначе получается слишком удобная картина: приложение само честно показывает, где у него лежит весь защитный слой.
Хорошая inline-защита обычно держится на трёх вещах.
Во-первых, проверки размазаны по клиенту и не читаются как один общий центр управления.
Во-вторых, реакция на срабатывание не обязана быть прямой и мгновенной. Иногда полезнее не падать в лоб, а ломать критичную ветку, деградировать часть сценария или поднимать риск на сервере.
В-третьих, она живёт в связке с остальными слоями. Если inline protection не опирается на obfuscation, integrity checks, attestation и сетевую политику, её быстро начинают разбирать как отдельную механику.
SSL Pinning
Pinning любят включать как быстрый ответ на перехват трафика. На демо это часто выглядит убедительно: подложили свой сертификат, приложение не пустило, значит сеть закрыта. В реальной жизни слой полезный, но хрупкий. Если pinning живёт в одном месте, если он завязан только на клиент, если вокруг него нет integrity checks и нормальной реакции на грязный рантайм, его начинают разбирать как обычную runtime-проверку.Нормальный смысл pinning простой: клиент должен доверять не любой системной цепочке, а конкретному серверу или конкретному набору публичных ключей. Тогда обычный прокси с подложенным CA уже не даёт читаемый трафик. Но и здесь есть старая ловушка: pinning защищает канал только до тех пор, пока сам клиент не удаётся подменить, зацепить или переписать в рантайме.
Certificate pinning implementation
Самая здравая схема - пинить не листовой сертификат, а публичный ключ или его отпечаток. Тогда ротация сертификата не превращается в немедленный кирпич для клиента. На Android это часто собирают поверх OkHttp, потому что там pinning уже встроен в сетевой стек и не требует городить свой велосипед в каждом запросе.
Код:
val certificatePinner = CertificatePinner.Builder()
.add("api.example.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")
.add("api.example.com", "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=") // backup pin
.build()
val client = OkHttpClient.Builder()
.certificatePinner(certificatePinner)
.build()Первая - pin должен жить не в виде одной строки, которую легко найти и выдрать из клиента вместе с остальной сетевой логикой.
Вторая - нужен запасной pin под ротацию, иначе приложение само создаст тебе инцидент при нормальной замене сертификата.
Третья - pinning должен закрывать именно чувствительные домены, а не существовать как красивая настройка рядом с основным сетевым стеком, который ходит по другому пути.
На iOS логика та же, просто реализация обычно уходит в URLSession и проверку trust chain в delegate. Ошибка там обычно одна и та же: команда вроде бы добавляет pinning, но часть запросов всё равно проходит через другой сетевой клиент, SDK или вспомогательный канал, где этот слой не живёт. После этого весь разговор про "у нас включён pinning" теряет смысл.
Anti-bypass: Frida detection
Вот здесь и начинается неприятная часть. Сам по себе pinning закрывает сеть от грубого MITM. Он почти ничего не гарантирует против человека, который уже сидит в рантайме и может трогать клиент изнутри. Поэтому pinning без anti-tampering часто живёт ровно до первого нормального hook'а.Отсюда и рабочий вывод: pinning нельзя держать отдельно. Если приложение не следит за instrumentation, не замечает подозрительный рантайм, не связывает сетевой слой с integrity checks и не умеет реагировать на грязную среду, защиту начинают снимать по месту. Не обязательно полностью. Иногда хватает подменить один критичный участок, чтобы клиент снова стал удобным для перехвата.
Что обычно помогает:
- не держать всю pinning-логику в одной функции;
- разносить проверки по нескольким точкам;
- связывать сетевой контур с integrity-сигналами;
- не ограничиваться одной локальной реакцией;
- поднимать риск на сервере, если клиент выглядит грязно.
Подведем итоги
Мобильный клиент всё равно будут разбирать. Вопрос не в том, получится ли это сделать вообще, а в том, сколько это займёт времени, сколько даст полезного материала и насколько далеко удастся зайти без нормальных затрат. Если приложение после сборки хорошо читается, pinning снимается без возни, рантайм спокойно цепляется, а чувствительные куски логики живут в клиенте слишком открыто, дальше всё развивается довольно предсказуемо.Из-за этого защита мобильного приложения почти никогда не держится на одном слое. Обфускация сама по себе не спасает. Pinning сам по себе тоже. Root detection, anti-debugging, secure storage, integrity checks, RASP - всё это начинает работать только в связке. Один слой режет дешёвый статический разбор, другой усложняет жизнь в рантайме, третий не даёт спокойно встать на провод, четвёртый мешает перепакованному клиенту выглядеть нормальным. Когда эта схема собрана криво, приложение раскладывают по частям. Когда собрана плотно, цена разбора заметно растёт.
Для финтеха, gaming и любого клиента с чувствительной логикой этого уже достаточно, чтобы смотреть на anti-tampering без иллюзий и без формальных галочек. Нормальная цель здесь простая: клиент не должен слишком охотно объяснять, как он устроен, что проверяет и где у него слабые места. Всё остальное уже упирается в дисциплину команды - как собирается релиз, как проверяется рантайм, как устроен серверный контроль и насколько регулярно приложение прогоняют не по чеклисту, а под реальный разбор.
Последнее редактирование:
