1. Introducere
2. Fundamentele aplicațiilor Android
3. Noțiuni de bază privind inversarea aplicațiilor Android
   • Exercițiu 1
4. Reverse Engineering Aplicații Android – DEX Bytecode
   • Exercițiu 2
   • Exercițiu 3
   • Exercițiu 4
5. Reverse Engineering Android Apps – Biblioteci native
   • Exercițiu 5
   • Exercițiu 6
7. Reverse Engineering Android Apps – Obfuscation
   • Exercițiu 7
8. Concluzie

Construiți o aplicație

Una dintre cele mai mari sugestii ale mele pentru cei care doresc să facă inginerie inversă, oricare ar fi acestea, este să încerce să construiască ceea ce doriți să inversați. În cazul Android, sunteți norocoși pentru că există atât de multe resurse gratuite disponibile pentru a vă construi prima aplicație. Dacă nu ați construit niciodată o aplicație Android, vă sugerez să începeți de acolo. Alegeți oricare dintre tutorialele și videoclipurile disponibile care vă trezesc interesul și apucați-vă de construit. Atunci când înțelegeți cum construiește un dezvoltator ceva, este mult mai ușor să înțelegeți cum să faceți inginerie inversă.

Revizuirea fundamentelor

Greav! Ați construit o aplicație sau ați învățat principiile de bază ale dezvoltării aplicațiilor Android. Iată o trecere în revistă a câtorva dintre punctele importante. Această pagină „Application Fundamentals” din documentația dezvoltatorilor Android este o trecere în revistă excelentă.

• Aplicațiile Android sunt în formatul de fișier APK. APK este practic un fișier ZIP. (Puteți redenumi extensia fișierului în .zip și să folosiți unzip pentru a-l deschide și a-i vedea conținutul.)
• Conținut APK (Nu este exhaustiv)
  • AndroidManifest.xml
  • META-INF/
    • Certificatul locuiește aici!
  • classes.dex
    • Dalvik bytecode pentru aplicația în format de fișier DEX. Acesta este codul Java (sau Kotlin) pe care aplicația îl va rula în mod implicit.
  • lib/
    • Bibliotecile native pentru aplicație, în mod implicit, locuiesc aici! Sub directorul lib/, se află directoarele specifice cpu-urilor. Ex: armeabi, mips,
• assets/
  • Toate celelalte fișiere care pot fi necesare aplicației.
  • Biblioteci native suplimentare sau fișiere DEX pot fi incluse aici. Acest lucru se poate întâmpla în special atunci când autorii de malware doresc să încerce să „ascundă” codul suplimentar, nativ sau Dalvik, prin neincluderea acestuia în locațiile implicite.

Dalvik & Smali

Majoritatea aplicațiilor Android sunt scrise în Java. Kotlin este, de asemenea, suportat și interoperabil cu Java. Pentru ușurință, în restul acestui atelier, când mă refer la „Java”, puteți presupune că mă refer la „Java sau Kotlin”. În loc ca codul Java să fie rulat în Java Virtual Machine (JVM), ca în cazul aplicațiilor desktop, în Android, Java este compilat în formatul bytecode Dalvik Executable (DEX). În cazul versiunilor anterioare de Android, bytecode-ul era tradus de mașina virtuală Dalvik. Pentru versiunile mai recente ale Android, se utilizează Android Runtime (ART).
Dacă dezvoltatorii, scriu în Java și codul este compilat în DEX bytecode, pentru a face inginerie inversă, lucrăm în sens invers.

Smali este versiunea lizibilă pentru oameni a bytecode-ului Dalvik. Din punct de vedere tehnic, Smali și baksmali sunt numele instrumentelor (asamblor și, respectiv, dezasamblorator), dar în Android, folosim adesea termenul „Smali” pentru a ne referi la instrucțiuni. Dacă ați făcut inginerie inversă sau arhitectură de calculator pe cod C/C++ compilat. SMALI este ca limbajul de asamblare: între codul sursă de nivel superior și bytecode.

Pentru următorul cod Java Hello World:

public static void printHelloWorld() {System.out.println("Hello World")}

Codul Smali ar fi:

.method public static printHelloWorld()V.registers 2sget-object v0, Ljava/lang/System;->out:Ljava/io/PrintStream;const-string v1, "Hello World"invoke-virtual {v0,v1}, Ljava/io/PrintStream;->println(Ljava/lang/String;)Vreturn-void.end method

Setul de instrucțiuni Smali este disponibil aici.

De cele mai multe ori, atunci când faceți inginerie inversă pentru aplicații Android, nu va fi nevoie să lucrați în Smali. Majoritatea aplicațiilor pot fi ridicate la un nivel și mai înalt, Java decompilat. Ca toate instrumentele, decompilatoarele Java pot avea erori. Sugestia mea este ca ori de câte ori rezultatul Java descompilat pare îndoielnic, să vă uitați la rezultatul Smali. Lucrați linie cu linie cu referința instrucțiunilor pentru a vă da seama ce face codul.

Pentru a obține Smali din DEX, puteți utiliza instrumentul baksmali (dezasamblator) disponibil la https://github.com/JesusFreke/smali/wiki. Instrumentul smali vă va permite să asamblați smali înapoi în DEX.

Puncte de intrare în aplicație

Unul dintre cele mai importante puncte ale ingineriei inverse este să știți de unde să începeți analiza, iar punctele de intrare pentru execuția codului reprezintă o parte importantă a acesteia.

Activitatea de lansare

Activitatea de lansare este ceea ce majoritatea oamenilor consideră a fi punctul de intrare într-o aplicație Android. Activitatea de lansare este activitatea care este pornită atunci când un utilizator face clic pe pictograma unei aplicații. Puteți determina activitatea de lansare uitându-vă la manifestul aplicației. Activitatea de lansare va avea listate următoarele intenții MAIN și LAUNCHER.

Rețineți că nu toate aplicațiile vor avea o activitate de lansare, în special aplicațiile fără interfață de utilizator. Exemple de aplicații fără o interfață de utilizator (și, prin urmare, o activitate de lansare) sunt aplicațiile preinstalate care execută servicii în fundal, cum ar fi mesageria vocală.

<activity android:name=".LauncherActivity"><intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter></activity>

Servicii

Serviciile rulează în fundal fără o interfață de utilizator. Există o multitudine de moduri în care acestea pot fi pornite și, prin urmare, reprezintă un punct de intrare pentru aplicații. Modul implicit în care un serviciu poate fi pornit ca punct de intrare pentru o aplicație este prin intermediul Intents.

Când API-ul startService este apelat pentru a porni un serviciu, metoda onStart din serviciu este executată.

Broadcast Receivers

Broadcast-urile pot fi considerate ca un sistem de mesagerie, iar receptorii de broadcast sunt ascultătorii. În cazul în care o aplicație a înregistrat un receptor pentru o anumită difuzare, codul din acel receptor este executat atunci când sistemul trimite difuzarea. Există 2 moduri în care o aplicație poate înregistra un receptor: în Manifestul aplicației sau înregistrat dinamic în codul aplicației folosind apelul API registerReceiver().

În ambele cazuri, pentru a înregistra receptorul, se setează filtrele de intenție pentru receptor. Aceste filtre de intenție sunt emisiunile care ar trebui să declanșeze receptorul.

Când sunt trimise emisiunile specifice pentru care este înregistrat receptorul, se execută onReceive din clasa BroadcastReceiver.

Componente exportate (Servicii & Activități)

Serviciile și activitățile pot fi, de asemenea, „exportate”, ceea ce permite altor procese de pe dispozitiv să pornească serviciul sau să lanseze activitatea. Componentele sunt exportate prin setarea unui element în manifest ca mai jos. În mod implicit, android:exported="false", cu excepția cazului în care acest element este setat la true în manifest sau sunt definite filtre de intenție pentru activitate sau serviciu.

<service android:name=".ExampleExportedService" android:exported="true"/><activity android:name=".ExampleExportedActivity" android:exported="true"/>

Subclasa aplicației

Aplicațiile Android pot defini o subclasă a aplicației. Aplicațiile pot, dar nu sunt obligate să definească o subclasă personalizată de Application. Dacă o aplicație Android definește o subclasă Application, această clasă este instanțiată înaintea oricărei alte clase din aplicație.

Dacă metoda attachBaseContext este definită în subclasa Application, aceasta este apelată prima, înaintea metodei onCreate.

NEXT > 3. Noțiuni introductive privind inversarea aplicațiilor Android

.