Reverse Engineering в мобилното разработване: какво е, инструменти и методи за анализ

Какво е Reverse Engineering?

Reverse Engineering (reversing) — дисциплина за анализ на софтуер, насочена към възстановяване на характеристиките, логиката и структурата на приложението от неговото двоично представяне. За мобилни приложения обектите на анализ са APK файлове (Android) и IPA файлове (iOS), съдържащи компилиран код, ресурси, манифести и сертификати. Резултатът от reversing — извличане на алгоритми, протоколи, ключове за криптиране, API схеми и бизнес логика.

Целите на обратното инженерство се делят на легитимни и нелегитимни. Легитимни: анализ на зловреден софтуер за създаване на защитни средства, одит на собствени приложения за уязвимости, осигуряване на съвместимост със затворени протоколи, патентен анализ и обучение. Нелегитимни: кражба на интелектуална собственост, заобикаляне на лицензионни ограничения, създаване на пиратски копия и модифициране на приложението за кражба на потребителски данни. Според Google Play Protect (2025), 78% от зловредните модификации на банкови приложения се създават на базата на оригиналния APK, преминал през reverse engineering.

Методологията на reversing включва две основни направления: статичен анализ (без стартиране на приложението) и динамичен анализ (по време на изпълнение). Всеки подход дава различно ниво на информация. Статичен — пълна картина на кода, но без данни за времето на изпълнение. Динамичен — реално поведение, поток от данни, мрежови извиквания, но само в рамките на конкретен сценарий на изпълнение. Професионалният reversing винаги комбинира и двата подхода.

Инструменти за статичен анализ

Статичният анализ е първият етап на обратното инженерство. Оригиналният APK или IPA се разопакова и всеки компонент се анализира отделно. Основни цели: DEX байткод, ресурси, манифест, естествени библиотеки (.so, .dylib) и метаданни.

jadx — декомпилатор от DEX в Java

jadx — основният инструмент за статичен анализ на Android приложения. Той преобразува DEX байткод в четим Java код с минимални загуби. jadx поддържа: декомпилиране на multidex, разпознаване на ламбда и вградени Kotlin класове, експорт в Gradle проект. За объркан код (ProGuard) jadx показва код с имена a, b, c, но структурата на класовете и последователността на извикванията се запазват. Според независими тестове, jadx правилно декомпилира 85–92% от кода дори с объркване.

apktool — разопаковане на ресурси

apktool декодира APK в smali код (DEX асемблер) и възстановява ресурсите в четим вид: AndroidManifest.xml се превръща от AXML в четим XML, layout-ове — в XML маркировка, strings.xml — в обикновен текст. apktool позволява модифициране на ресурси и повторно сглобяване на APK. След разопаковане чрез apktool и замяна на ресурси, приложението може да се инсталира с модифицирано съдържание.

Ghidra — анализ на естествени библиотеки

Ghidra (NSA) — рамка за reverse engineering, незаменима за анализ на .so библиотеки на Android и .dylib на iOS. Ghidra дизасемблира ARM64 код, възстановява псевдокод C и изгражда граф на извикванията. За мобилен reversing, Ghidra се използва за анализ на естествени реализации на криптография и DRM механизми. Ghidra поддържа скриптове на Python и Java за автоматизиране на анализа.

# Разопаковане и декомпилиране на APK
$ jadx -d output_dir app.apk

# Разопаковане на ресурси чрез apktool
$ apktool d app.apk -o app_unpacked

# Анализ на естествена библиотека чрез Ghidra
$ ghidra app.apk/lib/arm64-v8a/libnative.so

# Търсене на низови константи в DEX
$ strings classes.dex | grep -i api_key

Инструменти за динамичен анализ

Динамичният анализ се извършва на работещо приложение. Анализаторът се свързва с процеса и прихваща извиквания на функции, аргументи и върнати стойности в реално време.

Frida — универсален инструмент за инструментация

Frida — водещ инструмент за динамичен анализ на мобилни приложения. Frida инжектира JavaScript двигател в процеса на приложението (Android ART или iOS app) и позволява прихващане на извиквания както на Java/Objective-C, така и на C/C++ функции. С помощта на Frida, реверс инженерите могат: да логват всички извиквания на метода AES.decrypt() с параметри, да заменят върнатата стойност с произволна, да премахват SSL-pinning чрез Universal Android SSL Unpin, да проследяват естествени извиквания чрез Stalker. Frida работи без модифициране на APK/IPA, което я прави незаменима за тестване за проникване.

Objection — слой над Frida

Objection предоставя готови команди за типични задачи за reversing без писане на JavaScript скриптове: disable-pinning (изключване на SSL pinning), dump-keychain (iOS), explore (обхождане на йерархията от класове), memory search (търсене на низове в паметта). Objection позволява извършване на пълен динамичен анализ без нито един ред код. За iOS приложения, Objection автоматично намира и логва извикванията на NSURLSession, CFNetwork и NSKeyedArchiver.

Xposed Framework

Xposed — рамка за Android, която работи чрез замяна на файла app_process в Zygote. За разлика от Frida, Xposed не изисква root достъп след инсталиране. Xposed модулите могат да прихващат извиквания на методи във всяко приложение. За reversing, Xposed е удобен за дългосрочен анализ: модулът се инсталира и работи непрекъснато, логвайки поведението на приложението в различни сценарии. Xposed поддържа Android до версия 8.1; за Android 9+ се използва EdXposed, базиран на SandHook.

// Frida: прихващане на метода decrypt() в приложението
let aesClass = Java.use("javax.crypto.Cipher");

aesClass.doFinal.overload(
    "[B", "int", "int"
).implementation = function(
    input, offset, len
) {
    console("[AES] decrypt called, len=" + len);
    return this.doFinal(input, offset, len);
};

Процес на обратно инженерство на Android приложение

Стандартният работен процес на reversing се състои от последователни стъпки, всяка от които предоставя определено ниво на информация.

Стъпка 1: Събиране на разузнавателни данни

Анализаторът изучава APK на ниво метаданни: targetSdk, uses-permission (какви разрешения изисква), intent-filter и exported components. По разрешенията може да се определи кои API се използват (android.permission.CAMERA → камера, android.permission.RECORD_AUDIO → аудио). По exported activity се определят входни точки без оторизация. Този етап се извършва чрез aapt или ApkAnalyzer и отнема 1–2 минути.

Стъпка 2: Декомпилиране на DEX

APK се разопакова, classes.dex (или multidex) се подава на входа на jadx. На изхода — Java/Kotlin код в пакети. Анализаторът търси ключови класове: CryptoUtils, ApiClient, AuthManager, DatabaseHelper, и проверява кои алгоритми се използват. Ако в кода се появяват низове AES/CBC/PKCS5Padding — приложението използва криптиране и трябва да се намери ключът. На този етап се определят: твърдо кодирани ключове, API URL, OAuth токени и тайни. Без объркване целият код на приложението се чете като обикновен Java проект.

Стъпка 3: Анализ на трафика

Чрез настройване на Frida или Objection за изключване на SSL-pinning, анализаторът стартира приложението и прихваща мрежовия трафик чрез Burp Suite или mitmproxy. По данните от трафика се възстановява API схемата: какви крайни точки, какви параметри, в какъв формат. При възможност анализаторът модифицира заявките и проверява реакцията на сървъра към некоректни или зловредни данни. Липсата на сървърна валидация — пряка уязвимост, открита на тази стъпка.

Стъпка 4: Запис в data.json

Резултатите от анализа се записват в структуриран вид. За всяко намерено уязвимо място се посочват: клас и метод, описание на уязвимостта, вектор на експлоатация и препоръка за коригиране. Този набор от данни се предава на екипа за разработка или се използва за съставяне на pentest отчет. В автоматизирани среди (MobSF) отчетът се генерира автоматично въз основа на статичен и динамичен анализ.

Особености на reverse engineering на iOS приложения

Reverse engineering на iOS приложения е по-труден от Android поради по-строгата архитектура на сигурност на Apple и липсата на пряк достъп до файловата система на стандартни устройства. За анализ на iOS е необходим jailbreak.

Статичен анализ на Mach-O

IPA архивът съдържа Mach-O двоичен файл — универсален формат за изпълними файлове на Apple. За декомпилиране се използва Hopper Disassembler или IDA Pro. За разлика от Android DEX, който се декомпилира в Java с минимални загуби, Mach-O съдържа естествен ARM64 код, който се възстановява в псевдокод C с по-малка точност. Hopper се справя с 60–70% възстановяване, останалото трябва да се анализира на ниво асемблер.

Динамичен анализ с Frida за iOS

Frida на iOS изисква jailbreak и инсталиране на frida-server. След свързване, Frida прихваща Objective-C методи чрез API за маршрутизиране на съобщения. За iOS приложения типичен сценарий: прихващане на методи NSURLSession.dataTaskWithRequest за логване на HTTP заявки, прихващане на NSKeyedUnarchiver за анализ на сериализирани данни и проследяване на CoreData заявки чрез frida-trace. Frida стана достъпна за iOS 15–17 с пускането на Dopamine jailbreak.

IPA модификация

Reversing може да включва модифициране на IPA с последващо преопаковане и инсталиране на устройството. Инструменти: ipatool за разопаковане, MachOView за преглед на секции и optool за инжектиране на код. След модификация IPA се подписва чрез ldid или fastlane sigh за инсталиране на jailbreak-нато устройство. За iOS 16+ подписът на кода се проверява на ниво Secure Enclave и модифицираният IPA няма да работи на non-jailbreak-нато устройство.

// Frida: прихващане на HTTP заявки в iOS приложение
if (ObjC.available) {
    let NSURLSession = ObjC.classes.NSURLSession;
    let dataTaskWithRequest = ObjC.protocol("NSURLSessionDelegate")
        .method("- URLSession:dataTask:didReceiveData:");
    Interceptor.attach(dataTaskWithRequest.implementation, {
        onEnter(args) {
            let data = ObjC.Object(args[3]);
            console("[HTTP Response]", data.toString());
        }
    });
}

Методи за защита от reverse engineering

Защитата от обратно инженерство се основава на принципа на слоеста сигурност: нито един метод не осигурява 100% защита, но комбинацията прави reversing икономически неизгоден.

Объркване на кода

Основно ниво — ProGuard за Android, който заменя имената на класове и методи с едносимволни. За укрепване се използва DexGuard, добавящ overload induction (няколко метода с различни подписи и едно име) и криптиране на низове AES-256. Объркването увеличава времето за анализ на кода от 5 минути на 5–20 часа в зависимост от нивото. DexGuard допълнително обърква потока на управление, правейки кода нечетим за jadx.

Криптиране на константи

Всички низови константи — URL, ключове, токени, SQL заявки — се криптират на етапа на изграждане и се декриптират в runtime. Това защитава от статичен анализ на низовете на DEX файла. Нападател, който пусне strings app.apk, няма да види нито една API крайна точка. Дори след декомпилиране всички низове изглеждат като двоични данни. За всеки низ може да се използва отделен ключ, което усложнява деобъркването.

RASP и контрол на целостта

RASP агентът вътре в приложението открива Frida и отстраняване на грешки в runtime. Контролът на целостта чрез SHA-256 хеш на APK предотвратява стартирането на модифицирана версия на приложението. Ако хешът на APK не съвпада с еталонния (запазен в естествения слой) — приложението се прекратява. Това блокира атаки, базирани на модификация на APK, включително repackaging.

Сървърна защита

Критичната бизнес логика трябва да се изпълнява на сървъра, а не на клиента. Дори ако нападателят напълно декомпилира приложението, сървърният код остава недостъпен. Сървърната валидация на всички заявки и параметри предотвратява експлоатацията на уязвимости, открити по време на reversing. Сървърната атестация чрез Play Integrity API или App Attest потвърждава, че заявката идва от автентично, немодифицирано приложение.