
Pentru a putea analiza comportamentul unei aplicații mobile dincolo de interfață și a identifica posibile vulnerabilități, este necesar să folosești un set de unelte specializate. Acestea îți permit să extragi, decompilezi și interpretezi fișierele aplicației, în special în cazul aplicațiilor Android, unde structura este mai accesibilă decât pe alte platforme mobile. În această lecție vom trece în revistă cele mai importante unelte folosite în reverse engineering-ul aplicațiilor și cum se combină ele într-un flux logic de analiză.
Ce înseamnă decompilarea unei aplicații?
O aplicație Android vine sub forma unui fișier .apk (Android Package). Acesta este, în esență, o arhivă care conține cod compilat, fișiere de resurse (imagini, texte, layout-uri), manifestul aplicației și alte fișiere binare. Decompilarea înseamnă desfășurarea acestui pachet și traducerea codului compilat (format Dalvik/DEX) în cod lizibil pentru oameni – fie în format Java, fie în format smali (un tip de limbaj intermediar, similar assembler-ului pentru Android).
Procesul de analiză presupune mai multe etape:
1. Extracția fișierului APK – dintr-un telefon, din Google Play sau dintr-o sursă alternativă.
2. Decompilarea codului – transformarea codului DEX în cod Java (sau smali).
3. Analiza resurselor și a manifestului – fișierul AndroidManifest.xml și directoarele /res sau /assets pot conține informații critice.
4. Maparea permisiunilor și identificarea API-urilor suspecte – pentru a înțelege ce face aplicația în fundal.
Unelte esențiale pentru analiza statică
Cele mai frecvente unelte pentru analiză statică sunt:
🔹 JADX – Decompilează codul DEX într-o formă de Java ușor de citit. Are interfață grafică și permite căutare rapidă în clase, metode, string-uri.
🔹 APKTool – Extrage structura aplicației și o recompilează la nevoie. Este excelent pentru vizualizarea fișierului AndroidManifest și a resurselor.
🔹 MobSF (Mobile Security Framework) – O suită completă de analiză statică și dinamică. Poate încărca automat un APK, analiza permisiunile, trackerele, codul sursă și poate face scanări cu reguli prestabilite.
🔹 Bytecode Viewer – Alternativă pentru vizualizarea codului și structurii interne a aplicațiilor, cu suport pentru diferite moduri de decompilare.
🔹 dex2jar + JD-GUI – O combinație clasică în care codul DEX este convertit într-un fișier .jar, apoi vizualizat în Java cu JD-GUI.
Fiecare dintre aceste unelte oferă o altă perspectivă: APKTool pentru structură și manifest, JADX pentru cod clar, MobSF pentru o imagine de ansamblu automatizată.
Pași practici într-o analiză
Să presupunem că vrei să analizezi o aplicație pe care nu o cunoști. Procesul poate arăta așa:
1. Descarci fișierul APK – fie de pe APKPure, APKMirror sau chiar extrăgându-l dintr-un telefon.
2. Rulezi APKTool pentru a decomprima fișierul și a obține resursele și manifestul.
3. Deschizi APK-ul cu JADX pentru a explora clasele, metodele și string-urile.
4. Notezi comportamente suspecte: clase cu nume ofuscate, metode care conțin „sendSMS”, „getLocation” sau „uploadToServer”.
5. Verifici AndroidManifest.xml: permisiunile cerute, activitățile, serviciile și receptorii declarați.
6. Identifici domenii externe sau URL-uri hardcodate care pot indica canale de comunicare cu servere de comandă și control.
7. Folosești MobSF pentru a verifica automat ce rapoarte generează asupra aplicației: puncte slabe, API-uri riscante, nivelul SDK-ului și scorul de securitate.
Acest flux combină analiza manuală cu raportarea automată. Poate fi dus mai departe, în lecția următoare, către analiza comportamentului dinamic prin rulare într-un sandbox.
Ce trebuie să urmărești în cod?
Deși este tentant să cauți imediat lucruri precum parole sau chei API hardcodate, analiza statică are o valoare mai mare când urmărești:
🔹 cum sunt manipulate datele utilizatorului (colectate, criptate, trimise)
🔹 dacă se folosește ofuscare și în ce măsură
🔹 ce biblioteci terțe sunt incluse și ce rol au
🔹 cum sunt tratate permisiunile (verificate înainte sau ignorate)
🔹 ce metode sunt apelate în mod automat (de ex., în servicii care rulează în fundal)
De asemenea, este important să notezi dacă aplicația folosește metode anti-debugging sau anti-tampering, deoarece acestea pot indica o încercare conștientă de a ascunde comportamente riscante.
Limitări ale analizei statice
Analiza statică, deși foarte utilă, nu este completă. Nu îți arată ce face efectiv aplicația în timpul rulării. Nu poți vedea dacă există funcționalitate declanșată doar în anumite condiții sau dacă unele componente sunt încărcate dinamic (de exemplu, descărcate de pe server după instalare).
În plus, aplicațiile pot fi protejate prin metode precum:
🔹 obfuscare (prin ProGuard, R8 sau alte tooluri)
🔹 criptare parțială a codului
🔹 verificare de semnătură (pentru a detecta modificări ale APK-ului)
Pentru astfel de cazuri, analiza dinamică este complementară și devine esențială. Vom discuta despre ea în lecția următoare.
Reverse engineering-ul începe întotdeauna cu o analiză statică bine structurată. Fără ea, analiza comportamentală ulterioară este mai puțin informată. De aceea, stăpânirea uneltelor de decompilare, înțelegerea fișierelor interne și capacitatea de a „citi” o aplicație din interior reprezintă o etapă critică în orice proces de audit mobil. Lecția următoare te va duce în zona de analiză dinamică – acolo unde poți vedea în timp real ce face aplicația pe un sistem controlat.