Reverse Engineering în dezvoltarea mobilă: ce este, instrumente și metode de analiză

Ce este Reverse Engineering?

Reverse Engineering (reversing) — disciplina analizei software, orientată spre reconstituirea caracteristicilor, logicii și structurii aplicației din reprezentarea sa binară. Pentru aplicațiile mobile, obiectele de analiză sunt fișierele APK (Android) și IPA (iOS), care conțin cod compilat, resurse, manifeste și certificate. Rezultatul reversingu-lui — extragerea algoritmilor, protocoalelor, cheilor de criptare, schemelor API și logicii de business.

Scopurile ingineriei inverse se împart în legitime și ilegitime. Legitime: analiza malware-ului pentru crearea mijloacelor de protecție, auditul propriilor aplicații pentru vulnerabilități, asigurarea compatibilității cu protocoale închise, analiza de brevete și instruire. Ilegitime: furtul de proprietate intelectuală, ocolirea restricțiilor de licență, crearea de copii piratate și modificarea aplicației pentru furtul datelor utilizatorilor. Potrivit Google Play Protect (2025), 78% din modificările malițioase ale aplicațiilor bancare sunt create pe baza APK-ului original trecut prin reverse engineering.

Metodologia reversingu-lui include două direcții principale: analiza statică (fără lansarea aplicației) și analiza dinamică (în timpul executării). Fiecare abordare oferă un nivel diferit de informații. Statică — imaginea completă a codului, dar fără datele de execuție. Dinamică — comportamentul real, fluxul de date, apelurile de rețea, dar doar în cadrul scenariului specific de execuție. Reversingul profesional combină întotdeauna ambele abordări.

Instrumente de analiză statică

Analiza statică — prima etapă a ingineriei inverse. APK-ul sau IPA-ul original este despachetat, iar fiecare component este analizat separat. Obiective principale: bytecod DEX, resurse, manifest, biblioteci native (.so, .dylib) și metadate.

jadx — decompilator DEX în Java

jadx — instrumentul principal pentru analiza statică a aplicațiilor Android. Acesta transformă bytecodul DEX în cod Java lizibil cu pierderi minime. jadx suportă: decompilarea multidex, recunoașterea lambdalor și claselor încorporate Kotlin, exportul în proiect Gradle. Pentru cod ofuscat (ProGuard), jadx afișează codul cu nume a, b, c, dar structura claselor și ordinea apelurilor se păstrează. Conform testelor independente, jadx decompilează corect 85–92% din cod chiar și cu ofuscare.

apktool — despachetarea resurselor

apktool decodifică APK-ul în cod smali (asamblor DEX) și reconstituie resursele într-o formă lizibilă: AndroidManifest.xml este transformat din AXML în XML lizibil, layout-urile — în marcaj XML, strings.xml — în text simplu. apktool permite modificarea resurselor și reasamblarea APK-ului. După despachetarea prin apktool și înlocuirea resurselor, aplicația poate fi instalată cu conținut modificat.

Ghidra — analiza bibliotecilor native

Ghidra (NSA) — framework de reverse engineering, indispensabil pentru analiza bibliotecilor .so Android și .dylib iOS. Ghidra dezasamblează codul ARM64, reconstituie pseudocodul C și construiește graful de apeluri. Pentru reversing mobil, Ghidra este utilizată pentru analiza implementărilor native de criptografie și mecanismelor DRM. Ghidra suportă scriptare în Python și Java pentru automatizarea analizei.

# Despachetarea și decompilarea APK
$ jadx -d output_dir app.apk

# Despachetarea resurselor prin apktool
$ apktool d app.apk -o app_unpacked

# Analiza bibliotecii native prin Ghidra
$ ghidra app.apk/lib/arm64-v8a/libnative.so

# Căutarea constantelor string în DEX
$ strings classes.dex | grep -i api_key

Instrumente de analiză dinamică

Analiza dinamică se realizează pe aplicația în execuție. Analizatorul se conectează la proces și interceptează apelurile de funcții, argumentele și valorile returnate în timp real.

Frida — instrument universal de instrumentație

Frida — instrumentul lider de analiză dinamică a aplicațiilor mobile. Frida injectează un motor JavaScript în procesul aplicației (Android ART sau iOS app) și permite interceptarea apelurilor atât a funcțiilor Java/Objective-C, cât și C/C++. Cu ajutorul Fridei, inginerii reversivi pot: loga toate apelurile metodei AES.decrypt() cu parametri, înlocui valoarea returnată cu una arbitrară, dezactiva SSL-pinning prin Universal Android SSL Unpin, trasa apelurile native prin Stalker. Frida funcționează fără modificarea APK/IPA, ceea ce o face indispensabilă pentru testarea de penetrare.

Objection — strat peste Frida

Objection oferă comenzi gata făcute pentru sarcini tipice de reversing fără a scrie scripturi JavaScript: disable-pinning (dezactivare SSL pinning), dump-keychain (iOS), explore (parcurgerea ierarhiei claselor), memory search (căutarea stringurilor în memorie). Objection permite efectuarea unei analize dinamice complete fără o singură linie de cod. Pentru aplicațiile iOS, Objection găsește și loghează automat apelurile NSURLSession, CFNetwork și NSKeyedArchiver.

Xposed Framework

Xposed — framework pentru Android, care funcționează prin înlocuirea fișierului app_process în Zygote. Spre deosebire de Frida, Xposed nu necesită acces root după instalare. Modulele Xposed pot intercepta apelurile metodelor în orice aplicație. Pentru reversing, Xposed este convenabil pentru analiza pe termen lung: modulul se instalează și funcționează permanent, logând comportamentul aplicației în diferite scenarii. Xposed suportă Android până la versiunea 8.1; pentru Android 9+ se utilizează EdXposed bazat pe SandHook.

// Frida: interceptarea metodei decrypt() în aplicație
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);
};

Procesul de inginerie inversă a aplicației Android

Fluxul de lucru standard al reversingu-lui constă în pași consecutivi, fiecare oferind un anumit nivel de informații.

Pasul 1: Colectarea informațiilor

Analizatorul studiază APK-ul la nivel de metadate: targetSdk, uses-permission (ce permisiuni solicită), intent-filter și exported components. După permisiuni se poate determina ce API-uri sunt utilizate (android.permission.CAMERA → cameră, android.permission.RECORD_AUDIO → audio). După exported activity se determină punctele de intrare fără autorizare. Această etapă se realizează prin aapt sau ApkAnalyzer și durează 1–2 minute.

Pasul 2: Decompilarea DEX

APK-ul se despachetează, classes.dex (sau multidex) este transmis la intrarea jadx. La ieșire — cod Java/Kotlin în pachete. Analizatorul caută clase cheie: CryptoUtils, ApiClient, AuthManager, DatabaseHelper, și verifică ce algoritmi sunt utilizați. Dacă în cod apar stringuri AES/CBC/PKCS5Padding — aplicația utilizează criptare și trebuie găsită cheia. În această etapă se determină: chei hardcodate, URL-uri API, tokenuri OAuth și secrete. Fără ofuscare întregul cod al aplicației se citește ca un proiect Java obișnuit.

Pasul 3: Analiza traficului

Configurând Frida sau Objection pentru dezactivarea SSL-pinning, analizatorul lansează aplicația și interceptează traficul de rețea prin Burp Suite sau mitmproxy. Pe baza datelor de trafic se reconstituie schema API: ce endpointuri, ce parametri, în ce format. La posibilitate, analizatorul modifică cererile și verifică reacția serverului la date incorecte sau malițioase. Absența validării pe server — o vulnerabilitate directă descoperită la acest pas.

Pasul 4: Scrierea în data.json

Rezultatele analizei se fixează într-o formă structurată. Pentru fiecare loc vulnerabil găsit se indică: clasa și metoda, descrierea vulnerabilității, vectorul de exploatare și recomandarea de remediere. Acest set de date se transmite echipei de dezvoltare sau se utilizează pentru întocmirea raportului de pentest. În medii automatizate (MobSF), raportul se generează automat pe baza analizei statice și dinamice.

Particularități ale reverse engineering pentru aplicații iOS

Reverse engineering al aplicațiilor iOS este mai dificil decât Android din cauza arhitecturii de securitate mai riguroase a Apple și a lipsei accesului direct la sistemul de fișiere pe dispozitivele standard. Pentru analiza iOS este necesar jailbreak.

Analiza statică Mach-O

Arhiva IPA conține binarul Mach-O — formatul universal al fișierelor executabile Apple. Pentru decompilare se utilizează Hopper Disassembler sau IDA Pro. Spre deosebire de Android DEX, care se decompilează în Java cu pierderi minime, Mach-O conține cod ARM64 nativ, care se reconstituie în pseudocod C cu o precizie mai mică. Hopper face față la 60–70% reconstituire, restul trebuie analizat la nivel de asamblor.

Analiza dinamică cu Frida pentru iOS

Frida pe iOS necesită jailbreak și instalarea frida-server. După conectare, Frida interceptează metodele Objective-C prin API de rutare a mesajelor. Pentru aplicațiile iOS, scenariul tipic: interceptarea metodelor NSURLSession.dataTaskWithRequest pentru logarea cererilor HTTP, interceptarea NSKeyedUnarchiver pentru analiza datelor serializate și trasarea cererilor CoreData prin frida-trace. Frida a devenit disponibilă pentru iOS 15–17 odată cu lansarea jailbreak-ului Dopamine.

Modificarea IPA

Reversingul poate include modificarea IPA-ului cu reambalarea și instalarea ulterioară pe dispozitiv. Instrumente: ipatool pentru despachetare, MachOView pentru vizualizarea secțiunilor și optool pentru injectarea codului. După modificare, IPA se semnează prin ldid sau fastlane sigh pentru instalare pe dispozitiv jailbreakuit. Pentru iOS 16+, semnătura codului se verifică la nivelul Secure Enclave, iar IPA-ul modificat nu va rula pe un dispozitiv non-jailbreakuit.

// Frida: interceptarea cererilor HTTP în aplicația 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());
        }
    });
}

Metode de protecție împotriva reverse engineering

Protecția împotriva ingineriei inverse se bazează pe principiul layered security: nicio metodă nu oferă protecție 100%, dar combinația face reversingul nejustificat economic.

Ofuscarea codului

Nivelul de bază — ProGuard pentru Android, care înlocuiește numele claselor și metodelor cu caractere unice. Pentru consolidare se utilizează DexGuard, care adaugă overload induction (mai multe metode cu semnături diferite și același nume) și criptarea stringurilor AES-256. Ofuscarea mărește timpul de analiză a codului de la 5 minute la 5–20 ore în funcție de nivel. DexGuard suplimentar încurcă fluxul de control, făcând codul ilizibil pentru jadx.

Criptarea constantelor

Toate constantele string — URL-uri, chei, tokenuri, interogări SQL — se criptează la etapa de compilare și se decriptează în runtime. Aceasta protejează de analiza statică a stringurilor fișierului DEX. Atacatorul care rulează strings app.apk nu va vedea niciun endpoint API. Chiar și după decompilare, toate stringurile arată ca date binare. Pentru fiecare string se poate utiliza o cheie separată, ceea ce complică deofuscarea.

RASP și controlul integrității

Agentul RASP din interiorul aplicației detectează Frida și depanarea în runtime. Controlul integrității prin hash SHA-256 al APK-ului previne lansarea versiunii modificate a aplicației. Dacă hash-ul APK nu corespunde cu cel de referință (salvat în stratul nativ) — aplicația se închide. Aceasta blochează atacurile bazate pe modificarea APK-ului, inclusiv repackaging-ul.

Protecția pe server

Logica de business critică trebuie executată pe server, nu pe client. Chiar dacă atacatorul decompilează complet aplicația, codul serverului rămâne inaccesibil. Validarea pe server a tuturor cererilor și parametrilor previne exploatarea vulnerabilităților găsite în timpul reversingu-lui. Atestarea pe server prin Play Integrity API sau App Attest confirmă că cererea provine de la o aplicație autentică, nemodificată.