Взлом и внедрение своего кода в чужое iOS-приложение

В жизни хакеры не так всесильны и эффектны, как в голливудских фильмах. Но это не значит, что iOS-разработчик может вообще не думать о безопасности своего приложения. Пусть оно и не хранит тайны Пентагона, взломать его всё равно могут хотя бы для того, чтобы получить платные функции бесплатно.

На нашей конференции Mobius разработчик Мурад Татаев рассказывал о взломе iOS-приложений — и о том, что разработчики могут делать для защиты от него. А теперь мы расшифровали этот доклад (видеозапись также прилагаем). Далее повествование идёт от лица спикера.

Мы не будем говорить о защите сетевого слоя — о SSL Pinning и тому подобном, а рассмотрим только взлом приложения. Будет теоретическая часть, где мы разберемся с некоторыми понятиями, и практическая, где применим полученные знания.

Начнем с теории

Взлом

В моем понимании взлом — это изменение поведения приложения в интересах хакера. То есть приложение работает не так, как изначально задумывал программист. В основном поведение меняется в тех частях, что связаны с получением чего-то, обычно за деньги — хакер хочет получить это бесплатно.

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

Относительная безопасность означает, что затраты на атаку превышают полученную в результате выгоду. Допустим, у вас есть погодное приложение, в котором нет внутренних покупок. Вы пользуетесь открытым API, вам нет смысла париться о безопасности. И в результате взлома вы ничего не потеряете.

Но если вдруг у вас что-то серьезнее, например, фоторедактор, в котором через встроенные покупки можно открыть дополнительные фильтры, то стоит задуматься о безопасности.

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

Почему важно защищать приложение?

Чтобы это понять, нужно увидеть в этом смысл. И он в основном экономический, реже — репутационный.

Для примера возьмем YouTube Tools — твик для отключения рекламы в приложении YouTube. В чем проблема: из-за того, что вы не смотрите рекламу, YouTube недополучает денег. Разработчики YouTube знают об этом и часто борются с различными твиками.

Другой пример — получение платного бесплатно, как в игре Plague Inc. со взломанными покупками. В интернете лежит уже взломанный .ipa-файл, и из-за хакеров ребята теряют много денег, не уделяя достаточного внимания безопасности.

Еще один пример — обход платного скачивания Minecraft. В этом случае особенно не защитишься, потому что пользователь скачает приложение, расшифрует его, выложит файл, и его скачают другие.

Но в двух предыдущих вариантах (YouTube и Plague Inc.) есть способы бороться с хакерами, причем их довольно много.

Как защищаться?

Это главный вопрос. Есть несколько вариантов, которые я знаю:

• Проверка на джейлбрейк
• Проверка на дебаггер
• Обфускация кода (security through obscurity)
• Strip Swift Symbols — настройка в Xcode
• Валидация покупок на сервере
• Silent Push и Background Updates
• Написание кода на Swift и минимальное использование objc и dynamic

Совет: проверяйте, нет ли в интернете вашего взломанного приложения.

Проверка на джейлбрейк

Плюсы: легко и дешево использовать (достаточно скопировать и вставить код).

Минусы: во-первых, это очень легко пропатчить.

Во-вторых, страдают некоторые мирные пользователи, которые могли поставить джейлбрейк не чтобы получить что-то ваше бесплатно, а чтобы пользоваться различными другими твиками.

Есть и обратная сторона — джейлбрейк используется все реже, но есть и те, кто по-прежнему ставят его.

Ссылка на JailBreak.swift

Ссылка на DTTJailbreakDetection

Проверка на дебаггер

Плюсы: легко использовать, сложнее патчить.

Это хорошо работает с отложенными ошибками. Если вы узнали, что пользователь запустил ваше приложение с подключенным дебаггером или у него джейлбрейк и так далее, вы можете конкретно в каких-то критичных местах не давать ему проходить дальше. Такую ошибку нужно показывать не сразу, а делать это позже, чтобы код проверки не был в очевидном месте.

Минусы: это тоже патчится.

Примерный код проверки выглядит так:

Мы создаем структуру для информации о процессе, задаем размер этой структуры и с помощью утилиты systemctl пытаемся запросить флаги для текущего процесса. Если у нас получилось запросить их — идем дальше и проверяем, активен ли флаг P_TRACED. При помощи этого флага производится дебаггинг в iOS.

Если флаг стоит не в null, то нас дебажат.

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

Есть различные обфускаторы, один из популярных, насколько я понял по GitHub — это SwiftShield.

Плюсы: код превращается в лабиринт, в нем вообще не разберешься. Особенно классные обфускаторы создают дополнительные методы, мусор, чтобы запутать хакера. Насчет Swift не уверен, но в C#, Java и Kotlin есть такие.

Минусы: иногда этот лабиринт сказывается и на вас. И еще крэш-логи приходится каждый раз расшифровывать.

На скриншоте — крэш-лог одного из приложений.

Над зеленой полосой — крэш-лог до расшифровки, ниже — расшифрованный крэш-лог. Крэш-лог нужно расшифровывать через утилиту, которая идет вместе со SwiftShield. Это можно автоматизировать: засунуть в CI дополнительный job, чтобы подтягивать все крэш-логи, прогонять их через утилиту и что-то делать с ними дальше. Но это дополнительная работа.

Еще один большой минус — нет готовых решений, годных для энтерпрайза. Они опенсорсные. Это не плохо, но нужно быть осторожным, подтягивая что-то опенсорсное в ваш проект, особенно если он связан с безопасностью и обфускацией.

Я за свою практику не сталкивался с тем, чтобы кто-то в iOS пользовался обфускатором кода, поэтому это очень редкая практика.

Strip Swift Symbols

Плюсы: легко и дешево использовать, удаляется часть информации о Swift-классах. И это включено по умолчанию, то есть Xcode думает о вашей безопасности.

Минусы: информацию о классе можно найти другим способом.

Зачем нужно включать Strip Swift Symbols?

Допустим, у нас есть стандартный класс ViewController, label, viewDidLoad и так далее. Прошу обратить особенное внимание на статичную функцию buildScreen, о ней мы еще поговорим.

Если вы оставили Swift Symbols и после этого прогнали бинарник вашего приложения через специальную утилиту dsdump, вот что появится в логе:

Ниже можно увидеть, что есть некоторые свифтовые методы, и по названиям методов и переменных вы можете примерно понять, что здесь происходит и важен ли для вас этот класс. Что самое интересное, здесь нет статического метода buildScreen. Статические методы находятся в другом месте.

Вот что будет, если включить эту функцию: как вы видите, данных о свифтовых методах просто нет. Есть все, что связано с Objective-C и бриджингом для Objective-C.

Валидация покупок на сервере

Это очень хорошая практика, которой придерживаются не все. Среди топ-100 приложений я находил немало тех, у которых валидация все еще производится на девайсе, и при помощи одного твика можно обойти валидацию (подмена ответа сервера).

Плюсы: безопасность.

Минусы: вам придется покупать хостинг.

А если вы будете валидировать на клиенте?

Плюс: вам не нужен сервер.

Минус: потенциальная потеря денег. Твик LocaliAPStore будет вашим худшим врагом.

В качестве примера могу привести одно приложение, связанное с фоторедактированием. Название я, к сожалению, не могу сказать. Это приложение как раз не использует валидацию покупок на сервере. Приложение классное, но при помощи одного твика вы можете получить всё бесплатно.

Еще есть одна RPG-игра, она тоже находится в топах, там тоже валидация покупок на девайсе. Даже у известного раннера про подземки и бег с поездами такая же проблема — валидация идет на девайсе.

Инструменты — чем я пользуюсь каждый день

Filza — файловый менеджер, в котором скрыто очень много функций. С его помощью вы можете поднять сервер, FileDAV и обмениваться файлами с компьютером.

Unc0ver — это джейлбрейк, которым я пользуюсь. Он поддерживает версии вплоть до iOS 13.5.

Но с iOS 13.5 я бы посоветовал быть осторожней, потому что встроенный браузер в приложении, Safari View Controller, работает плохо. Лично у меня, когда я открываю ссылки, появляется окно внутреннего браузера (Safari View Controller), которое абсолютно пустое и ничего не грузит.

Cydia — это менеджер пакетов для взломанных устройств.

Наверное, некоторые из вас слышали, что Cydia — всё, закрыта, но нет, она поддерживается и вполне живет. Здесь есть куча разных твиков. Мы будем использовать Cydia в основном для того, чтобы устанавливать различные инструменты на устройство. С Cydia вы можете скачать ту же самую Filza.

NewTerm — это мобильный терминал. Он тоже доступен из Cydia и тоже полезная штука.

FLEXing — твик для поверхностного анализа приложения на устройстве. При помощи него можно посмотреть интернет-трафик, ваши файлы и тому подобное. Снифер трафика обходит SSL Pinning.

Я так проверял трафик в Instagram, а там есть SSL Pinning,

Можно посмотреть объекты в куче, которые есть сейчас, и вызвать различные методы в этих объектах. Есть общий список классов для приложения, можно поверхностно посмотреть, что там есть. Можно посмотреть UserDefaults и, неожиданно, Keychain.

Keychain — это, грубо говоря, тот же самый UserDefaults, только зашифрованный вашим паролем, то есть пин-кодом от вашего устройства. Если вы введете пин-код, Keychain разблокируется, и все, что там лежит, можно посмотреть. Так что я бы вам советовал не хранить ничего незашифрованного в Keychain, потому что до этого можно добраться и что-то поменять.

Как делать не надо

В AppDelegate есть строка isUnlocked:

То есть разработчик добавил в AppDelegate переменную, с помощью которой он смотрит, куплено приложение или нет.

Естественно, эта переменная легко меняется: вы жмете кнопку i, дергаете свитч, нажимаете «ОК». Поменяли переменную, закрыли меню флексинга, и у вас полностью «купленное» приложение.

Ghidra

Классная штука, дизассемблер от АНБ США, здесь можно вставить шутку про слежку от спецслужб.

Плюсы:

• Бесплатный
• Умеет в arm64, что нам как раз и нужно
• Умеет в псевдокод — вы можете посмотреть интерпретацию кода и понять, что ничего не поломали
• Позволяет бесплатно редактировать и экспортировать бинарники.

Переходим к практике

Мы будем практиковаться на тестовом проекте.

Как достать расшифрованное приложение?

• Необходимо клонировать репозиторий
• Установить на девайс Frida Tools, используя Cydia
• Запустить проект MobiusStep1 в режиме Release на взломанном устройстве
• Установить утилиту iProxy
• Запустить терминал, ввести код iproxy 2222 22
• Поставить Frida на компьютер, например, через Homebrew
• Ввести freeda-ps -Uai
• Если всё сделано правильно, то в терминале отобразится общий набор приложений на устройстве и в топе будут находиться включенные приложения. Будет написан их PID и так далее.
• Скачать скрипт frida-ios-dump для скачивания взломанных приложений
• Перейти в папку с этим скриптом (телефон подключен при помощи кабеля, iProxy запущен)
• Ввести ./dump.py “имя вашего приложения”

Есть ограничения — не дампятся extensions. Но за все время, что я этим пользовался, мне extensions и не были нужны.

Обход проверки на джейлбрейк

Патчим бинарник. Тот проект, что вы скачали ранее, выглядит так: простой белый экран, на нем — label с текстом: либо Hacked, либо Safe and sound в зависимости от того, джейлбрейкнуто устройство или нет.

• Достаем .ipa-файл, о котором говорили выше (он будет в папке со скриптом, по сути это .zip-архив)
• Разархивируем и переходим в папку Payload, далее — в .app-контейнер
• Копируем бинарник и содержимое папки Frameworks в отдельную папку. Тогда Ghidra подтянет все зависимости, ссылки и так далее. Это очень удобно, если вы проверяете многомодульное приложение: один метод находится в другом модуле, часть этого модуля — в третьем модуле и так далее. Можно разом все импортировать в Ghidra.
• Запускаем Ghidra, создаем новый проект и добавляем ранее скопированные файлы.

Если все сделали правильно, это будет выглядеть примерно так:

Как найти необходимый участок кода?

Так как у нас код не обфусцирован, нужно либо вручную, не давая методам слишком очевидные имена, либо утилитами обфусцировать код.

При помощи поиска ищем слово jail в настройках. Найдется пара методов. И если вы нажмете на один из них, как можно увидеть чуть выше, курсор прыгнет в нужную область памяти.

Патчим инструкцию

Здесь вы видите инструкцию bl (branch with link) — это по сути прыжок на функцию, которая ожидает, что из этой функции что-то вернется в регистре w0. Если мы знаем, в какой регистр вернется значение, мы можем выполнить команду mov (присваивание).

То есть в регистр w0 записывается как раз то, что возвращается с метода. Мы записываем 0 (то есть false), экспортируем бинарник. Так как мы не трогали остальные фреймворки, нам нужен только бинарник.

Экспортируем его.

Скорее всего, он будет экспортирован с припиской bin, ее нужно удалить и оставить только MobiusStep1. После этого открываем папку, откуда мы брали бинарник, то есть папку с приложением, папку с .app-контейнером, заменяем старый бинарник на новый.

После этого все подписываем, собираем и устанавливаем на устройство.

Готово — вы пропатчили приложение.

Подпись и установка приложения

Необходимые предварительные требования:

• Профиль разработчика. Можно воспользоваться бесплатным — на одно устройство и на неделю, но это намного проблемнее.
• Проще купить профиль и воспользоваться AdHoc provisioning profile, то есть создать AdHoc-профайл на портале разработчика.
• libimobiledevice — набор утилит, одна из которых — установка .ipa-файла на устройство через консоль вне зависимости от того, взломан телефон или нет (brew install libmobiledevice).
• Приложение, которое хотите установить
• Терпение и усидчивость — потому что все может пойти не по плану именно в этой части.

Копируем необходимые файлы

Создаем Adhoc Provisioning Profile и копируем его в папку с приложением. Дальше выполняем код:

security cms -D -i adhoc.mobileprovision > profile.plist

/usr/libexec/PlistBuddy -x -c 'Print :Entitlements' profile.plist > entitlements.plist

В итоге мы получим entitlements.plist, который нам нужен. Profile.plist уже не нужен. Система безопасности iOS построена вокруг этих entitlements.

security — утилита macOS, с помощью которой можно работать с сертификатами, паролями, keychains и всем, что связано с безопасностью.

После этого копируем Adhoc Provisioning Profile в контейнер приложения (папку Payload/*.app) и переименовываем его в embedded.mobileprovision. Это обязательно!

Находим ключ для подписи

Вводим код:

security find-identity -v -p codesigning

Этот код ищет сертификат, при помощи которого можно подписать приложение. В моем случае я выбрал iPhone Distribution, можно выбрать Developer, разницы я не заметил. Она может возникнуть, когда вы будете пытаться залить это все в App Store. Но в локальном тесте разницы нет.

Подписываем файлы

Это самое интересное. Вводим codesign, не забываем подписывать фреймворки. В моем случае там лежали только dylib, если лежат еще и фреймворки — обговорим этот кейс позже.

Не забывайте сначала подписать основной бинарник, а потом все приложение. В таком порядке у меня все работало отлично.

codesign -f -s "iPhone Distribution: Murad Tataev (….)” --entitlements "entitlements.plist" Payload/*.app/Frameworks/*.dylib

codesign -f -s "iPhone Distribution: Murad Tataev (….)” --entitlements "entitlements.plist"
Payload/*.app/MobiusStep1

codesign -f -s "iPhone Distribution: Murad Tataev (….)” --entitlements "entitlements.plist"
Payload/*.app

Дальше архивируем:

zip -qr resigned.ipa Payload

И устанавливаем. Не забывайте, чтобы устройство было подключенным через кабель, иначе работать не будет.

ideviceinstaller -i resigned.ipa

Cтавим через ideviceinstaller, а не Xcode — ideviceinstaller пишет логи в консоль, и вы сможете понять, на каком шаге допустили ошибку. Это довольно сильно облегчает дебаг.

Инъекция фреймворков и подмена реализации методов

Дальше начинается самое интересное, то есть настоящий взлом. Необходимые инструменты:

• otool (он поставляется из Xcode, вам ничего не нужно качать)
• dsdump (есть в интернете, можно найти)
• optool
• фреймворк, который нужно будет вставить в ваше приложение и в котором будет ваш дополнительный код.

Потренируемся!

Советую всем начинать с простого и только потом бежать взламывать пентагоны.

Выглядит тестовый проект так:

Приложение называется Mobius Conf. У вас есть 300 монет, можно добавить монеты, то есть их купить, но мы так делать не будем, либо можно что-то купить внутри приложения за 200 монет.

Порядок действий:

• Создайте проект, добавьте в него новый таргет, в меню выберите фреймворк.
• Во фреймворк добавьте новый ObjC-класс, дайте название по вкусу.
• В имплементационный файл MobiusStep2/MOBFramework/Injector.m добавьте код:

Скорее всего, большинству из вас код будет непонятен. Метод вызывается в момент. когда загружается ваш фреймворк. Стоит учитывать, что именно в этот момент приложения еще нет, оно только грузится.

Здесь нельзя сразу пытаться что-то менять. Именно поэтому здесь прописан dispatch_after. Через три секунды на экране появится алерт с текстом вроде «Вы это сделали, классно». Если вы скопировали, вставили, все заработало — прекрасно, это первый шаг в сторону взлома.

Поиграем с кодом

• Склонируйте Substrate и скопируйте фреймворк Substrate на рабочий стол.
• Во фреймворк MOBFramework добавьте фреймворк Substrate (переносится через drag and drop).
• Импортируйте заголовок “CydiaSubstrate/CydiaSubstrate.h”.

Cydia Substrate — это такой фреймворк для подмены реализации методов, другими словами, для хукания методов. Есть метод с изначальной реализацией, которую задумал программист, и есть ваш метод. Вы берете и подменяете эти методы. На этом фреймворке держатся все твики, которые лежат в Cydia.

Попробуем вызвать какую-нибудь функцию.

В навигаторе Xcode откройте папку Products. Вы можете открыть файл MobiusStep2.app в Finder, перейти в папку app через терминал, войти в app-контейнер и с помощью утилиты dsdump принтануть все символы, которые есть в приложении.
Все статичные методы в приложении тоже реализованы в виде символов.

dsdump -c MobiusStep2 | grep viewDidLoad

Вводите ViewDidLoad или то, что вам интересно. Здесь есть два метода, я выбрал второй, вы можете выбрать первый — по сути, это одно и то же.

Копируете всю строку, в Xcode удаляете весь предыдущий код и вводите команду MSFindSymbol.

Что такое MS? Изначально CydiaSubstate называлась MobileSubstate, и MS — дань уважения этому. MSFindSymbol делает то же, что и dsdump — идет поиск символа, копируется отступ по памяти, дополнительные данные. Всё это нужно для того, чтобы позже можно было что-то менять по этому символу.

Можно что-то вызвать по этому символу:

((void (*)(void)) symbol)();

Но имейте в виду, что в этом методе могут вызываться различные переменные, которые еще не инициализированы. И возможно, приложение будет просто крашиться. Поэтому будьте осторожны, и лучше всего через Ghidra заранее проверять метод, который вы хотите вызвать: посмотреть в интерпретаторе, не идут ли вызовы в какие-то локальные переменные, которые еще не инициализированы, и так далее.

Если вы так вызовете символ в этом проекте, вы увидите, что принтанется viewDidLoad. Из-за того, что вы сами вызвали viewDidLoad, и после этого вызвался «натуральный» метод, у вас в консоли продублируется текст viewDidLoad.

Давайте вызовем свой код после viewDidLoad.

Это уже что-то более боевое и интересное. Из предыдущего кода остается MSFindSymbol, но только вызов MSFindSymbol заменяется на MSHookFunction. Здесь оригинальный метод заменяется на засвизленный, то есть на наш.

В нашем методе мы сначала вызываем оригинальную имплементацию в виде Load, и после него идет наш код. Ничего оригинального не стал придумывать, просто через 2 секунды отображаю алерт.

Как насчет бесконечности денег?

Если вы будете бродить по символам, найдете интересный символ PurchaseManager spend. Из названия понятно, что этот метод будет вызван, если что-то нужно потратить, например, деньги. И этот метод можно захукать.

С помощью Ghidra можно понять и проверить, что этот метод на входе принимает аргумент в виде количества денег, и просто подменить оригинальную реализацию своей.

Разница в том, что мы не учитываем количество денег, которое потратил пользователь, — всегда передаем 1. Каждый раз, когда вы нажимаете кнопку покупки, единичка будет уходить. Можно передавать 0, и тогда у вас будет бесконечное количество денег (они не будут тратиться).

Потренировались? Будем инжектить в реальное приложение.

• Ранее созданный фреймворк копируем на рабочий стол или в отдельную папку. Его можно будет найти в папке Products.
• Собираем проект в режиме Release, предварительно удалив ранее созданный фреймворк из проекта. Так мы почистим следы вмешательства.
• Запускаем на устройстве, копируем .ipa-файл и разархивируем его.
• Копируем MOBFramework.framework в папку Frameworks (Payload/MobiusStep2.app/Frameworks)

Дальше добавим загрузку своего фреймворка. В консоли переходим в MobiusStep2.app, и при помощи otool -L MobiusStep2 проверяем, какие фреймворки и библиотеки добавлены на загрузку.

Здесь есть Foundation, Objective-C, UIKit, SwiftCore и так далее.

При помощи optool можно добавить свою дополнительную строку. Вводим код:

optool install -c load -p “@rpath/MOBFramework.framework/MOBFramework” -t MobiusStep2

Добавится новая строка. Это можно проверить, вызвав команду:

otool -L MobiusStep2

Вы увидите, что в конце добавлена новая строка на загрузку нового фреймворка. Обязательно после фреймворка написать / и путь до бинарника, иначе ничего не подгрузится и не будет работать.

Не забудьте подписать фреймворк!

codesign -f -s "identity” Payload/*.app/Frameworks/*.framework

Не забудьте скопировать фреймворк в папку с фреймворками — та строка, что мы писали, магическим образом не будет искать по всему проекту — только в папке Frameworks.

Можно объединить все в один shell-файл, чтобы не вводить каждый раз несколько команд. Можно добавить еще одну команду для подписи сразу всех фреймворков.

Готово!

Вы заинжектили свой фреймворк и свой код в чужое приложение.

Но! Хукать свифтовые методы можно только на взломанном устройстве.

Если хотите хукать не только на взломанных устройствах и карма смотрит на вас лицом, то вам повезет, и то приложение, которое вы будете исследовать, будет на Objective-C.

Это еще одна причина, почему я говорил, что писать надо на Swift. Вы сейчас увидите, почему не следует писать на Objective-С что-то безопасное.

Это приложение MobiusStep3. Здесь кнопка добавления денег пропала, есть только кнопка «Потратить». Наша цель — иметь бесконечное количество монет. В этом нам поможет Objective-C Runtime и тот же свизлинг методов.

Подготовка проекта

• Клонируем проект MobiusStep3
• Собираем (билдим) проект
• Переходим в папку с приложением, открываем его бандл (.app)

• Запускаем терминал в этой папке

Используя команду dsdump --objc MobiusStep3 -vvv, можно посмотреть, какие методы есть в приложении.

Их немного, и если присмотреться, можно заметить уязвимый метод spend. Мы его взламывали ранее, и он может принести потенциальные проблемы.

Будем свизлить как раз-таки его, здесь классический свизлинг методов. Находим класс по имени, находим селектор по имени и подменяем реализацию оригинального метода на неоригинальный.

Не забываем сохранять ссылку на предыдущую (оригинальную) реализацию. Можно заметить строку с переменной originalImplementation, так мы держим ссылку на оригинальную имплементацию. IMP — это сишная структура, просто так IMP-структуры не вызвать, приходится их кастить.

Внизу видно, как мы их закастили через swizzled_spend. id, SEL — это обязательно. Наконец, вы можете увидеть int в коде, который кастим. На следующей строке вызываем этот метод и передаем 0 или 1. Единица удобна для дебага.

Все работает без мам, пап, кредитов и Cydia Substrate. Причина — особенность гипердинамичного Objective-C Runtime, где связывание с методами происходит как можно позже.

Резюмируем

• Проверяйте на джейлбрейк и на дебаггер, потому что это дешево и просто.
• Не используйте Objective-C, либо используйте его по минимуму и не забывайте отрезать Swift Symbols.
• Обфускация в целом классная идея, но используется редко и приносит неудобства с крэш-логами.
• Привязывайтесь к хардварным особенностям системы. Если у вас есть какие-то токены, которые необходимо обновлять, то лучше всего построить логику обновления так. Через Silent Push к вам приходит некоторое уведомление, вы на него реагируете и запрашиваете обновленный токен заново с сервера. После того, как пришел Silent Push, у вас есть где-то 30 секунд на то, чтобы запросить новый токен, записать его и опять уйти в сон. Реализовать это не так сложно, зато в такой системе хакеру будет очень тяжело получать токены.
• Храните данные на сервере, потому что локальные хранилища (UserDefaults, Keychain, LokalDB) очень ненадежны. Даже локальные базы данных можно просмотреть при помощи Filza.
• Валидируйте покупки на сервере, а не на девайсе.

И помните — абсолютной безопасности не существует. Но можно сделать безопаснее, чем было раньше.

Если вам захочется обсудить с Мурадом его доклад, напишите ему:

• Telegram и Хабр: spartanrasul
• Email: spartanrasul@gmail.com

Если вы дочитали досюда и вы не злонамеренный хакер (фу таким быть) — тогда, скорее всего, вы мобильный разработчик. Тогда обращаем ваше внимание, что следующий Mobius пройдет 22-25 ноября, и там будет много новых докладов. Хакерский колорит в их случае не обещаем, а вот актуальность для мобильных разработчиков — вполне.