Reverse Engineering v mobilním vývoji: co to je, nástroje a metody analýzy

Co je Reverse Engineering?

Reverse Engineering (reversing) — disciplína analýzy softwaru zaměřená na obnovení charakteristik, logiky a struktury aplikace z jejího binárního zobrazení. Pro mobilní aplikace jsou objekty analýzy soubory APK (Android) a IPA (iOS) obsahující zkompilovaný kód, zdroje, manifesty a certifikáty. Výsledek reversingu — extrakce algoritmů, protokolů, šifrovacích klíčů, API schémat a obchodní logiky.

Cíle zpětného inženýrství se dělí na legitimní a nelegitimní. Legitimní: analýza malwaru pro vytvoření ochranných prostředků, audit vlastních aplikací na zranitelnosti, zajištění kompatibility s uzavřenými protokoly, patentová analýza a školení. Nelegitimní: krádež duševního vlastnictví, obcházení licenčních omezení, vytváření pirátských kopií a modifikace aplikace pro krádež uživatelských dat. Podle Google Play Protect (2025) vzniká 78% škodlivých modifikací bankovních aplikací na základě původního APK, které prošlo reverse engineeringem.

Metodologie reversingu zahrnuje dva hlavní směry: statickou analýzu (bez spuštění aplikace) a dynamickou analýzu (během provádění). Každý přístup poskytuje jinou úroveň informací. Statická — úplný obraz kódu, ale bez dat o běhu. Dynamická — skutečné chování, tok dat, síťová volání, ale pouze v rámci konkrétního scénáře provádění. Profesionální reversing vždy kombinuje oba přístupy.

Nástroje statické analýzy

Statická analýza — první fáze zpětného inženýrství. Původní APK nebo IPA se rozbalí a každá komponenta se analyzuje samostatně. Hlavní cíle: DEX bytekód, zdroje, manifest, nativní knihovny (.so, .dylib) a metadata.

jadx — dekompilátor DEX do Java

jadx — hlavní nástroj pro statickou analýzu Android aplikací. Převádí DEX bytekód do čitelného Java kódu s minimálními ztrátami. jadx podporuje: dekompilaci multidex, rozpoznávání lambd a vestavěných tříd Kotlin, export do Gradle projektu. Pro obfuskovaný kód (ProGuard) zobrazuje jadx kód se jmény a, b, c, ale struktura tříd a pořadí volání jsou zachovány. Podle nezávislých testů jadx správně dekompiluje 85–92% kódu i s obfuskací.

apktool — rozbalení zdrojů

apktool dekóduje APK do smali kódu (DEX assembler) a obnovuje zdroje v čitelné podobě: AndroidManifest.xml se převádí z AXML do čitelného XML, rozvržení do XML značek, strings.xml do prostého textu. apktool umožňuje upravovat zdroje a znovu sestavit APK. Po rozbalení pomocí apktool a výměně zdrojů lze aplikaci nainstalovat s upraveným obsahem.

Ghidra — analýza nativních knihoven

Ghidra (NSA) — framework reverse engineering, nepostradatelný pro analýzu .so knihoven Android a .dylib iOS. Ghidra disassembluje ARM64 kód, obnovuje pseudokód C a vytváří graf volání. Pro mobilní reversing se Ghidra používá k analýze nativních implementací kryptografie a DRM mechanismů. Ghidra podporuje skriptování v Pythonu a Javě pro automatizaci analýzy.

# Rozbalení a dekompilace APK
$ jadx -d output_dir app.apk

# Rozbalení zdrojů pomocí apktool
$ apktool d app.apk -o app_unpacked

# Analýza nativní knihovny pomocí Ghidra
$ ghidra app.apk/lib/arm64-v8a/libnative.so

# Hledání řetězcových konstant v DEX
$ strings classes.dex | grep -i api_key

Nástroje dynamické analýzy

Dynamická analýza se provádí na běžící aplikaci. Analytik se připojí k procesu a zachycuje volání funkcí, argumenty a návratové hodnoty v reálném čase.

Frida — univerzální nástroj pro instrumentaci

Frida — přední nástroj pro dynamickou analýzu mobilních aplikací. Frida vkládá JavaScriptový engine do procesu aplikace (Android ART nebo iOS app) a umožňuje zachycovat volání jak Java/Objective-C, tak C/C++ funkcí. Pomocí Fridy mohou reverzní inženýři: logovat všechna volání metody AES.decrypt() s parametry, nahradit návratovou hodnotu libovolnou, odstranit SSL-pinning pomocí Universal Android SSL Unpin, trasovat nativní volání pomocí Stalker. Frida pracuje bez úpravy APK/IPA, což ji činí nepostradatelnou pro penetrační testování.

Objection — vrstva nad Fridou

Objection poskytuje hotové příkazy pro typické úkoly reversingu bez psaní JavaScript skriptů: disable-pinning (vypnutí SSL pinning), dump-keychain (iOS), explore (procházení hierarchie tříd), memory search (hledání řetězců v paměti). Objection umožňuje provést úplnou dynamickou analýzu bez jediného řádku kódu. Pro iOS aplikace Objection automaticky nachází a loguje volání NSURLSession, CFNetwork a NSKeyedArchiver.

Xposed Framework

Xposed — framework pro Android, který funguje nahrazením souboru app_process v Zygote. Na rozdíl od Fridy, Xposed po instalaci nevyžaduje root přístup. Xposed moduly mohou zachycovat volání metod v jakékoli aplikaci. Pro reversing je Xposed vhodný pro dlouhodobou analýzu: modul se nainstaluje a pracuje nepřetržitě, loguje chování aplikace v různých scénářích. Xposed podporuje Android až do verze 8.1; pro Android 9+ se používá EdXposed založený na SandHook.

// Frida: zachycení metody decrypt() v aplikaci
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);
};

Proces zpětného inženýrství aplikace Android

Standardní workflow reversingu se skládá z po sobě jdoucích kroků, z nichž každý poskytuje určitou úroveň informací.

Krok 1: Sběr zpravodajských dat

Analytik zkoumá APK na úrovni metadat: targetSdk, uses-permission (jaká oprávnění požaduje), intent-filter a exported components. Podle oprávnění lze určit, která API se používají (android.permission.CAMERA → kamera, android.permission.RECORD_AUDIO → audio). Podle exported activity se určují vstupní body bez autorizace. Tato fáze se provádí pomocí aapt nebo ApkAnalyzer a trvá 1–2 minuty.

Krok 2: Dekompilace DEX

APK se rozbalí, classes.dex (nebo multidex) se předá na vstup jadx. Na výstupu — Java/Kotlin kód v balíčcích. Analytik hledá klíčové třídy: CryptoUtils, ApiClient, AuthManager, DatabaseHelper, a kontroluje, které algoritmy se používají. Pokud se v kódu vyskytují řetězce AES/CBC/PKCS5Padding — aplikace používá šifrování a je třeba najít klíč. V této fázi se určují: hardcodované klíče, API URL, OAuth tokeny a tajemství. Bez obfuskace se celý kód aplikace čte jako běžný Java projekt.

Krok 3: Analýza provozu

Nastavením Fridy nebo Objection pro vypnutí SSL-pinning, analytik spustí aplikaci a zachycuje síťový provoz pomocí Burp Suite nebo mitmproxy. Na základě dat provozu se obnovuje API schéma: jaké endpointy, jaké parametry, v jakém formátu. Pokud je to možné, analytik modifikuje požadavky a kontroluje reakci serveru na nesprávná nebo škodlivá data. Absence serverové validace — přímá zranitelnost objevená v tomto kroku.

Krok 4: Zápis do data.json

Výsledky analýzy se zaznamenávají ve strukturované podobě. Pro každé nalezené zranitelné místo se uvádí: třída a metoda, popis zranitelnosti, vektor zneužití a doporučení pro opravu. Tato datová sada se předává vývojovému týmu nebo se používá pro sestavení pentest zprávy. V automatizovaných prostředích (MobSF) se zpráva generuje automaticky na základě statické a dynamické analýzy.

Zvláštnosti reverse engineering iOS aplikací

Reverse engineering iOS aplikací je obtížnější než Android kvůli přísnější bezpečnostní architektuře Apple a chybějícímu přímému přístupu k souborovému systému na standardních zařízeních. Pro analýzu iOS je potřeba jailbreak.

Statická analýza Mach-O

IPA archiv obsahuje Mach-O binárku — univerzální formát spustitelných souborů Apple. Pro dekompilaci se používá Hopper Disassembler nebo IDA Pro. Na rozdíl od Android DEX, který se dekompiluje do Java s minimálními ztrátami, Mach-O obsahuje nativní ARM64 kód, který se obnovuje do pseudokódu C s menší přesností. Hopper zvládá 60–70% obnovení, zbytek je třeba analyzovat na úrovni assembleru.

Dynamická analýza s Fridou pro iOS

Frida na iOS vyžaduje jailbreak a instalaci frida-server. Po připojení Frida zachycuje Objective-C metody přes API směrování zpráv. Pro iOS aplikace typický scénář: zachycení metod NSURLSession.dataTaskWithRequest pro logování HTTP požadavků, zachycení NSKeyedUnarchiver pro analýzu serializovaných dat a trasování CoreData dotazů přes frida-trace. Frida se stala dostupnou pro iOS 15–17 s vydáním jailbreaku Dopamine.

IPA modifikace

Reversing může zahrnovat modifikaci IPA s následným přebalením a instalací na zařízení. Nástroje: ipatool pro rozbalení, MachOView pro prohlížení sekcí a optool pro vkládání kódu. Po modifikaci se IPA podepisuje pomocí ldid nebo fastlane sigh pro instalaci na jailbreaknuté zařízení. Pro iOS 16+ se podpis kódu kontroluje na úrovni Secure Enclave a modifikovaná IPA se nespustí na non-jailbreaknutém zařízení.

// Frida: zachycení HTTP požadavků v iOS aplikaci
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());
        }
    });
}

Metody ochrany proti reverse engineering

Ochrana proti zpětnému inženýrství je postavena na principu layered security: žádná metoda neposkytuje 100% ochranu, ale kombinace činí reversing ekonomicky nevýhodným.

Obfuskace kódu

Základní úroveň — ProGuard pro Android, který nahrazuje názvy tříd a metod jednoznakovými. Pro posílení se používá DexGuard, přidávající overload induction (několik metod s různými signaturami a stejným názvem) a šifrování řetězců AES-256. Obfuskace zvyšuje dobu analýzy kódu z 5 minut na 5–20 hodin v závislosti na úrovni. DexGuard navíc zamotává tok řízení, činí kód nečitelným pro jadx.

Šifrování konstant

Všechny řetězcové konstanty — URL, klíče, tokeny, SQL dotazy — se šifrují ve fázi sestavení a dešifrují za běhu. To chrání před statickou analýzou řetězců DEX souboru. Útočník, který spustí strings app.apk, neuvidí žádný API endpoint. I po dekompilaci všechny řetězce vypadají jako binární data. Pro každý řetězec lze použít samostatný klíč, což ztěžuje deobfuskaci.

RASP a kontrola integrity

RASP agent uvnitř aplikace detekuje Fridu a ladění za běhu. Kontrola integrity pomocí SHA-256 hash APK zabraňuje spuštění modifikované verze aplikace. Pokud hash APK nesouhlasí s referenčním (uloženým v nativní vrstvě) — aplikace se ukončí. To blokuje útoky založené na modifikaci APK, včetně repackagingu.

Serverová ochrana

Kritická obchodní logika by měla být prováděna na serveru, ne na klientovi. I když útočník plně dekompiluje aplikaci, serverový kód zůstává nepřístupný. Serverová validace všech požadavků a parametrů zabraňuje zneužití zranitelností nalezených během reversingu. Serverová atestace prostřednictvím Play Integrity API nebo App Attest potvrzuje, že požadavek pochází z autentické, nemodifikované aplikace.