Reverse Engineering a mobilfejlesztésben: mi ez, eszközök és elemzési módszerek

Mi az a Reverse Engineering?

Reverse Engineering (reversing) — a szoftverelemzés tudományága, amely az alkalmazás jellemzőinek, logikájának és szerkezetének helyreállítására irányul a bináris megjelenítésből. Mobilalkalmazások esetén az elemzés tárgyai APK-fájlok (Android) és IPA-fájlok (iOS), amelyek fordított kódot, erőforrásokat, manifesteket és tanúsítványokat tartalmaznak. A reversing eredménye — algoritmusok, protokollok, titkosítási kulcsok, API-sémák és üzleti logika kinyerése.

A visszafejtés céljai legitim és illegitim csoportokra oszlanak. Legitim: kártevők elemzése védelmi eszközök létrehozásához, saját alkalmazások auditálása sérülékenységekre, kompatibilitás biztosítása zárt protokollokkal, szabadalmi elemzés és oktatás. Illegitim: szellemi tulajdon ellopása, licenckorlátozások megkerülése, kalózmásolatok készítése és az alkalmazás módosítása a felhasználói adatok ellopására. A Google Play Protect (2025) szerint a banki alkalmazások káros módosításainak 78%-a az eredeti, reverse engineeringen átesett APK alapján készül.

A reversing módszertana két fő irányt foglal magában: statikus elemzés (az alkalmazás elindítása nélkül) és dinamikus elemzés (végrehajtás közben). Minden megközelítés más információszintet ad. Statikus — teljes képet a kódról, de a végrehajtási adatok nélkül. Dinamikus — valós viselkedést, adatáramlást, hálózati hívásokat, de csak egy adott végrehajtási forgatókönyv keretein belül. A professzionális reversing mindig mindkét megközelítést kombinálja.

Statikus elemzési eszközök

A statikus elemzés a visszafejtés első szakasza. Az eredeti APK-t vagy IPA-t kicsomagolják, és minden komponenst külön elemeznek. Fő célok: DEX bájtkód, erőforrások, manifest, natív könyvtárak (.so, .dylib) és metaadatok.

jadx — DEX-dekompilátor Java-ba

jadx — a fő eszköz Android-alkalmazások statikus elemzéséhez. A DEX bájtkódot minimális veszteséggel olvasható Java kóddá alakítja. A jadx támogatja: a multidex dekompilálását, a lambdák és a beépített Kotlin-osztályok felismerését, exportálást Gradle-projektbe. Obfuszkált kód (ProGuard) esetén a jadx a, b, c nevekkel mutatja a kódot, de az osztályszerkezet és a hívások sorrendje megmarad. Független tesztek szerint a jadx a kód 85–92%-át helyesen dekompilálja még obfuszkációval is.

apktool — erőforrások kicsomagolása

Az apktool APK-t smali kódba (DEX assembler) dekódolja, és az erőforrásokat olvasható formában állítja helyre: az AndroidManifest.xml AXML-ből olvasható XML-be, a layoutok — XML-jelölésbe, a strings.xml — egyszerű szöveggé alakul. Az apktool lehetővé teszi az erőforrások módosítását és az APK újrafordítását. Az apktool-lal történő kicsomagolás és az erőforrások cseréje után az alkalmazás módosított tartalommal telepíthető.

Ghidra — natív könyvtárak elemzése

Ghidra (NSA) — reverse engineering keretrendszer, nélkülözhetetlen az Android .so és iOS .dylib könyvtárainak elemzéséhez. A Ghidra ARM64 kódot dezassemblál, C pszeudokódot állít helyre, és hívási gráfot épít. Mobil reversinghez a Ghidrát a kriptográfia és DRM-mechanizmusok natív implementációinak elemzésére használják. Ghidra támogatja a Python és Java szkriptírást az elemzés automatizálásához.

# APK kicsomagolása és dekompilálása
$ jadx -d output_dir app.apk

# Erőforrások kicsomagolása apktool-lal
$ apktool d app.apk -o app_unpacked

# Natív könyvtár elemzése Ghidrával
$ ghidra app.apk/lib/arm64-v8a/libnative.so

# String konstansok keresése DEX-ben
$ strings classes.dex | grep -i api_key

Dinamikus elemzési eszközök

A dinamikus elemzés futó alkalmazáson történik. Az elemző csatlakozik a folyamathoz, és valós időben elfogja a függvényhívásokat, argumentumokat és visszatérési értékeket.

Frida — univerzális instrumentációs eszköz

Frida — a vezető eszköz mobilalkalmazások dinamikus elemzéséhez. A Frida JavaScript-motort injektál az alkalmazás folyamatába (Android ART vagy iOS app), és lehetővé teszi mind a Java/Objective-C, mind a C/C++ függvények hívásainak elfogását. A Frida segítségével a visszafejtő mérnökök: naplózhatják az AES.decrypt() metódus összes hívását paramétereivel együtt, tetszőleges visszatérési értékre cserélhetik, eltávolíthatják az SSL-pinninget az Universal Android SSL Unpin segítségével, nyomon követhetik a natív hívásokat a Stalker-en keresztül. A Frida az APK/IPA módosítása nélkül működik, ami nélkülözhetetlenné teszi a penetrációs tesztelésben.

Objection — réteg a Frida felett

Az Objection kész parancsokat biztosít tipikus reversing feladatokhoz JavaScript-szkriptek írása nélkül: disable-pinning (SSL pinning kikapcsolása), dump-keychain (iOS), explore (osztályhierarchia bejárása), memory search (stringek keresése a memóriában). Az Objection lehetővé teszi a teljes dinamikus elemzés elvégzését egyetlen kódsor nélkül. iOS-alkalmazások esetén az Objection automatikusan megtalálja és naplózza a NSURLSession, CFNetwork és NSKeyedArchiver hívásait.

Xposed Framework

Xposed — Android keretrendszer, amely az app_process fájl lecserélésével működik a Zygote-ban. A Frida-val ellentétben az Xposed telepítés után nem igényel root hozzáférést. Az Xposed modulok bármely alkalmazásban képesek elfogni metódushívásokat. Reversinghez az Xposed hosszú távú elemzésre alkalmas: a modul telepítésre kerül és folyamatosan működik, naplózva az alkalmazás viselkedését különböző forgatókönyvekben. Az Xposed az Android 8.1-ig támogatott; Android 9+ esetén a SandHook-on alapuló EdXposed használatos.

// Frida: a decrypt() metódus elfogása az alkalmazásban
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);
};

Az Android-alkalmazás visszafejtési folyamata

A reversing szabványos munkafolyamata egymást követő lépésekből áll, amelyek mindegyike meghatározott információszintet biztosít.

1. lépés: Hírszerzési adatok gyűjtése

Az elemző az APK-t metaadat szinten vizsgálja: targetSdk, uses-permission (milyen engedélyeket kér), intent-filter és exported components. Az engedélyek alapján meghatározható, hogy mely API-kat használják (android.permission.CAMERA → kamera, android.permission.RECORD_AUDIO → audio). Az exported activity alapján meghatározhatók a belépési pontok engedélyezés nélkül. Ez a szakasz aapt vagy ApkAnalyzer segítségével történik, és 1–2 percig tart.

2. lépés: DEX dekompilálása

Az APK kicsomagolásra kerül, a classes.dex (vagy multidex) a jadx bemenetére kerül. Kimenet — Java/Kotlin kód csomagokban. Az elemző kulcsfontosságú osztályokat keres: CryptoUtils, ApiClient, AuthManager, DatabaseHelper, és ellenőrzi, hogy milyen algoritmusokat használnak. Ha a kódban AES/CBC/PKCS5Padding stringek találhatók — az alkalmazás titkosítást használ, és meg kell találni a kulcsot. Ebben a szakaszban meghatározásra kerülnek: keményre kódolt kulcsok, API-URL-ek, OAuth-tokenek és titkok. Obfuszkáció nélkül az alkalmazás teljes kódja úgy olvasható, mint egy szokásos Java projekt.

3. lépés: Forgalom elemzése

Az SSL-pinning kikapcsolásához a Frida vagy Objection beállításával az elemző elindítja az alkalmazást, és elfogja a hálózati forgalmat a Burp Suite vagy mitmproxy segítségével. A forgalmi adatok alapján helyreáll az API-séma: milyen végpontok, milyen paraméterek, milyen formátumban. Lehetőség szerint az elemző módosítja a kéréseket, és ellenőrzi a szerver reakcióját helytelen vagy káros adatokra. A szerveroldali validáció hiánya — közvetlen sérülékenység, amely ebben a lépésben derül ki.

4. lépés: Írás a data.json-ba

Az elemzés eredményei strukturált formában rögzítésre kerülnek. Minden talált sérülékeny helyhez megadásra kerül: osztály és metódus, a sérülékenység leírása, kihasználási vektor és javítási javaslat. Ez az adatkészlet továbbításra kerül a fejlesztőcsapatnak, vagy pentest-jelentés összeállításához használják. Automatizált környezetekben (MobSF) a jelentés automatikusan generálódik a statikus és dinamikus elemzés eredményei alapján.

Az iOS-alkalmazások reverse engineeringének jellemzői

Az iOS-alkalmazások reverse engineeringe nehezebb, mint az Androidé, az Apple szigorúbb biztonsági architektúrája és a fájlrendszerhez való közvetlen hozzáférés hiánya miatt a stock eszközökön. Az iOS elemzéséhez jailbreak szükséges.

Mach-O statikus elemzés

Az IPA-archívum Mach-O binárist tartalmaz — az Apple univerzális végrehajtható fájlformátumát. A dekompiláláshoz Hopper Disassembler vagy IDA Pro használatos. Az Android DEX-szel ellentétben, amely minimális veszteséggel Java-ba dekompilálódik, a Mach-O natív ARM64 kódot tartalmaz, amely kisebb pontossággal állítható helyre C pszeudokódban. Hopper 60–70%-os helyreállítással birkózik meg, a többit assembly szinten kell elemezni.

Dinamikus elemzés Frida-val iOS-hez

A Frida iOS-en jailbreak-et és a frida-server telepítését igényli. Csatlakozás után a Frida Objective-C metódusokat fog el az üzenetirányítási API-n keresztül. iOS-alkalmazások esetén tipikus forgatókönyv: a NSURLSession.dataTaskWithRequest metódusok elfogása a HTTP-kérések naplózásához, a NSKeyedUnarchiver elfogása a szerializált adatok elemzéséhez, és a CoreData lekérdezések nyomon követése a frida-trace-en keresztül. A Frida a Dopamine jailbreak megjelenésével vált elérhetővé iOS 15–17-re.

IPA-módosítás

A reversing magában foglalhatja az IPA módosítását, majd az újracsomagolást és telepítést az eszközre. Eszközök: ipatool a kicsomagoláshoz, MachOView a szakaszok megtekintéséhez és optool a kód injektálásához. Módosítás után az IPA-t ldid vagy fastlane sigh segítségével írják alá a jailbreakelt eszközre történő telepítéshez. iOS 16+ esetén a kódaláírás a Secure Enclave szintjén ellenőrzésre kerül, és a módosított IPA nem fog futni nem jailbreakelt eszközön.

// Frida: HTTP-kérések elfogása iOS-alkalmazásban
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());
        }
    });
}

Védelmi módszerek a reverse engineering ellen

A visszafejtés elleni védelem a réteges biztonság elvén alapul: egyetlen módszer sem nyújt 100%-os védelmet, de a kombináció gazdaságilag nem kifizetődővé teszi a reversinget.

Kód obfuszkáció

Alapszint — ProGuard Androidhoz, amely az osztály- és metódusneveket egykarakteresre cseréli. Erősítéshez DexGuard használatos, amely overload induction-t (több metódus eltérő aláírással és azonos névvel) és AES-256 string titkosítást ad hozzá. Az obfuszkáció a kódelemzés idejét 5 percről 5–20 órára növeli a szinttől függően. DexGuard továbbá összekuszálja a vezérlési folyamatot, olvashatatlanná téve a kódot a jadx számára.

Konstansok titkosítása

Minden string konstans — URL-ek, kulcsok, tokenek, SQL-lekérdezések — a build fázisban titkosításra kerül, és futásidőben visszafejtődik. Ez véd a DEX-fájl stringjeinek statikus elemzése ellen. Az a támadó, aki futtatja a strings app.apk-t, nem lát egyetlen API-végpontot sem. Még dekompilálás után is az összes string bináris adatnak tűnik. Minden stringhez külön kulcs használható, ami megnehezíti a deobfuszkációt.

RASP és integritás-ellenőrzés

Az alkalmazáson belüli RASP-ügynök érzékeli a Frida-t és a hibakeresést futásidőben. Az APK SHA-256 hash-én keresztüli integritás-ellenőrzés megakadályozza az alkalmazás módosított verziójának elindítását. Ha az APK hash nem egyezik a referenciával (a natív rétegben tárolva) — az alkalmazás leáll. Ez blokkolja az APK módosításán alapuló támadásokat, beleértve a repackaginget.

Szerveroldali védelem

A kritikus üzleti logikát a szerveren kell végrehajtani, nem a kliensen. Még ha a támadó teljesen dekompilálja is az alkalmazást, a szerverkód elérhetetlen marad. Az összes kérés és paraméter szerveroldali validálása megakadályozza a reversing során talált sérülékenységek kihasználását. Szerveroldali tanúsítás Play Integrity API-n vagy App Attesten keresztül igazolja, hogy a kérés hiteles, nem módosított alkalmazástól származik.