Защита приложений от обратной разработки - сложный процесс, который может отнимать много сил и нервов. Статья расскажет о нескольких подходах защиты приложений под операционную систему iOS с использованием разных методов запутывания кода и сокрытия данных.
Методики анализа приложений
Первый метод, который применяется для анализа приложения - статический. При этом виде анализа организуется просмотр файлов приложения, их расположение в пакете установки и локализация тех данных, которые настраивают окружение для корректной работы приложения. Завершающим этапом исследования является просмотр дезассемблированного и, возможно, декомпилированного листинга приложения. Для этого метода очень важно, чтобы стандартные структуры данных оставались в их первоначальном виде. Первоначальный вид - это вид, который приобрел исходный код приложения после компиляции в Xcode. Для файлов в первоначальном виде, как правило, уже существуют коммерческие и open source инструменты анализа. В случае же, если вмешивается дополнительное преобразование данных и кода в целях их сокрытия, то алгоритм становится читать очень сложно, а при грамотном подходе - иногда невозможно.
Как это можно реализовать? Обычно подход к запутыванию кода применяют на этапе компиляции. Достигается это за счет использования мусорных конструкций, которые могут не выполнять основного алгоритма приложения, но занимать процессорное время. Также применяются методы для запутывания графа выполнения команд. Например, код слева - до преобразования, код справа - после:
Весьма эффективный метод: над разбором такого защищенного приложения можно провести большое количество часов, но оборотной стороной таких преобразований могут стать проблемы с производительностью и поддержкой полученного кода, а также большое количество времени на проведение отладки, поиска проблем.
Для платформы iOS open source инструмента, к сожалению, нет, но можно воспользоваться проектами, которые реализуют похожий функционал и просто использовать основную идею.
Дополнительное усложнение статического анализа возможно при учете основных методов, которые применяются для анализа приложений:
Использование названий методов и классов для поиска фрагментов алгоритма;
Использование констант для определения кода, который выполняет основные проверки;
Локализация библиотечных функций, которые задействованы в алгоритме.
Все перечисленные выше подходы применяются для начала анализа. Обычно это просто отправная точка, но что если попытаться убрать эту точку из приложения? В этой области разработка под iOS ушла довольно далеко. Большое количество проектов предлагают подходы для обфускации названий классов, методов и констант внутри файла приложения. Реализация работает в основном за счет создания огромного файла в проекте с большим количество "define" директив, но основную задачу выполняет. Пример обфускации из репозитория:
class Sample: UIViewController {
var value = 42
override func viewDidLoad() {
super.viewDidLoad()
configure()
foo(bar: 1)
}
func foo(bar baz: Int) {
value += baz
}
}
class aqoxMfcPUXffEuurviH_ZPMDW2hCmXDR: UIViewController {
var a0vLRcFFAQ1Lvw2sf4ZIigWKjXjpJpug = 42
override func viewDidLoad() {
super.viewDidLoad()
A6PP2E5mcmjEsgOvTeXwy2G44vzYLa6H()
xG1qrXIMEJC1Eoma2Qbp_ZWJ5y2lrGYX(KuT5vOLIISvSJyju6bYxsHO_vlWUU589: 1)
}
func xG1qrXIMEJC1Eoma2Qbp_ZWJ5y2lrGYX(KuT5vOLIISvSJyju6bYxsHO_vlWUU589 vjCKgTT7Cf0ZlEi9giLZstzgdC9XLQcd: Int) {
a0vLRcFFAQ1Lvw2sf4ZIigWKjXjpJpug += vjCKgTT7Cf0ZlEi9giLZstzgdC9XLQcd
}
}
Статический анализ - это не единственный возможный вариант исследования приложений. Более продуктивный и быстрый метод анализа - динамический. При этом способе анализа приложения злоумышленник может использовать отладчики для операционной системы, приложения и наборы инструментов, которые будут исследовать каждую команду запущенного приложения. В прошлой статье было описано, как можно усложнить жизнь таким инструментам. Однако ранее мы говорили об инструментах, которые уже готовы для использования, а что, если будет использоваться что-то кастомное?
Вероятный проект, который может использовать злоумышленник для исследования - frida-gum. Это библиотека, которая может быть использована для создания новых инструментов анализа приложений. По сути, это те же наборы функций, которые были доступны из frida, только код для имплементации может меняться злоумышленником по его усмотрению. Пример кода, который использует frida-gum:
//адрес функции, которая отслеживает наличие заижекченого кода
const uintptr_t functionAddress = 0x....
// Установка перехвата функции
GumAttachReturn attach_ret = gum_interceptor_attach(
listener_->interceptor,
/* target */ reinterpret_cast<void*>(functionAddress),
reinterpret_cast<GumInvocationListener*>(listener_),
/* ID */ reinterpret_cast<void*>(functionAddress)
);
....
// OnEnter обычной Frida
void native_listener_on_enter(GumInvocationListener* listener, GumInvocationContext* ic) {
const uintptr_t ctor_function_addr = ic->cpu_context->x[1];
}
Если подобный код будет добавлен в зависимости приложения через патч или при запуске приложения, то можно будет собирать вызовы функций, которые отработали в приложении. Единственная возможность детектировать такое вмешательство - проверка контрольных точек алгоритма на наличие секретного значения. Например:
static constexpr uintptr_t OOD = 0x000dbeef;
static uintptr_t MAGIC_CFI = 0xdeadc0de;
__attribute__((constructor))
void frida_detect() {
if (is_frida_running()) {
crash();
}
MAGIC_CFI = OOD;
}
__attribute__((constructor))
void control_fault_check() {
if (MAGIC_CFI != OOD) {
crash();
}
}
Если добавить такие конструкции на функции проверки наличия, допустим, jailbreak, то перехват функции и создание обработчика, который не будет устанавливать секретные значения, не сможет отработать, потому что условие "contol_fault_check" будет постоянно крашить приложение.
Вывод
Методы защиты алгоритма приложения - это всегда компромисс между скоростью, функциональностью и безопасностью. Проблема iOS платформы в этой области заключается в том, что считается достаточным использование DRM защиты, которая предоставляется Apple. Но, до тех пор, пока существует jailbreak, эта защита будет недостаточной. Для защиты алгоритмов придется прибегать к определенным ухищрениям и "допиливать" opensouce проекты, чтобы они подходили под задачи защиты от обратной разработки.
Статья подготовлена в преддверии старта курса IOS Developer. Professional.
