1. Introduzione
2. Fondamenti delle applicazioni Android
3. Come iniziare a invertire le applicazioni Android
   • Esercizio 1
4. Reverse Engineering Android Apps – Bytecode DEX
   • Esercizio 2
   • Esercizio 3
   • Esercizio 4
5. Reverse Engineering Android Apps – Librerie native
   • Esercizio 5
   • Esercizio 6
6. Reverse Engineering Android Apps – Obfuscation
   • Esercizio 7
7. Conclusione

Costruire un’App

Uno dei miei maggiori suggerimenti per chi cerca di fare reverse engineering, qualunque esse siano, è di provare a costruire ciò che si vuole invertire. Nel caso di Android, siete fortunati perché ci sono così tante risorse gratuite disponibili per costruire la vostra prima applicazione. Se non avete mai costruito un’applicazione Android prima, vi suggerisco di iniziare da lì. Scegliete uno qualsiasi dei tutorial e dei video disponibili che suscitano il vostro interesse e iniziate a costruire. Quando capisci come uno sviluppatore costruisce qualcosa, è molto più facile capire come fare il reverse engineering.

Rassegna dei fondamenti

Bene! Hai costruito un’applicazione o hai imparato i principi di base dello sviluppo di applicazioni Android. Ecco un ripasso di alcuni punti importanti. Questa pagina “Application Fundamentals” nei documenti degli sviluppatori Android è un ottimo ripasso.

• Le applicazioni Android sono nel formato file APK. APK è fondamentalmente un file ZIP. (Puoi rinominare l’estensione del file in .zip e usare unzip per aprire e vedere il suo contenuto.)
• Contenuto dell’APK (Non esaustivo)
  • AndroidManifest.xml
  • META-INF/
    • Il certificato vive qui!
  • classes.dex
    • Il bytecode Dalvik per l’applicazione nel formato file DEX. Questo è il codice Java (o Kotlin) che l’applicazione eseguirà per default.
  • lib/
    • Le librerie native per l’applicazione, per default, vivono qui! Sotto la directory lib/, ci sono le directory specifiche della cpu. Es: armeabi, mips,
  • assets/
    • Qualsiasi altro file che può essere necessario all’applicazione.
    • Librerie native aggiuntive o file DEX possono essere inclusi qui. Questo può accadere soprattutto quando gli autori di malware vogliono provare a “nascondere” il codice aggiuntivo, nativo o Dalvik, non includendolo nelle posizioni predefinite.

Dalvik & Smali

La maggior parte delle applicazioni Android sono scritte in Java. Kotlin è anche supportato e interoperabile con Java. Per facilità, per il resto di questo workshop, quando mi riferisco a “Java”, potete assumere che intendo “Java o Kotlin”. Invece di eseguire il codice Java nella Java Virtual Machine (JVM) come le applicazioni desktop, in Android, Java è compilato nel formato Dalvik Executable (DEX) bytecode. Per le versioni precedenti di Android, il bytecode veniva tradotto dalla macchina virtuale Dalvik. Per le versioni più recenti di Android, viene utilizzato l’Android Runtime (ART).
Se gli sviluppatori scrivono in Java e il codice viene compilato in bytecode DEX, per il reverse engineering, si lavora nella direzione opposta.

Smali è la versione umana leggibile del bytecode Dalvik. Tecnicamente, Smali e baksmali sono i nomi degli strumenti (assemblatore e disassemblatore, rispettivamente), ma in Android, usiamo spesso il termine “Smali” per riferirci alle istruzioni. Se avete fatto reverse engineering o architettura di computer su codice compilato C/C++. SMALI è come il linguaggio assembly: tra il codice sorgente di livello superiore e il bytecode.

Per il seguente codice Java Hello World:

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

Il codice Smali sarebbe:

.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

La serie di istruzioni Smali è disponibile qui.

La maggior parte delle volte quando si fa reverse engineering di applicazioni Android, non è necessario lavorare in Smali. La maggior parte delle applicazioni può essere portata ad un livello ancora più alto, decompilando Java. Come tutti gli strumenti, i decompilatori Java possono avere dei bug. Il mio suggerimento è che ogni volta che l’output Java decompilato sembra discutibile, guardate l’output Smali. Lavora linea per linea con il riferimento alle istruzioni per capire cosa sta facendo il codice.

Per ottenere lo Smali da DEX, puoi usare lo strumento baksmali (disassemblatore) disponibile a https://github.com/JesusFreke/smali/wiki. Lo strumento smali ti permetterà di riassemblare gli smali in DEX.

Punti di ingresso dell’applicazione

Uno dei punti più importanti del reverse engineering è sapere dove iniziare la tua analisi e i punti di ingresso per l’esecuzione del codice sono una parte importante di questo.

Attività di lancio

L’attività di lancio è ciò che la maggior parte delle persone pensa come punto di ingresso di un’applicazione Android. L’attività di lancio è l’attività che viene avviata quando un utente clicca sull’icona di un’applicazione. Puoi determinare l’attività di avvio guardando il manifesto dell’applicazione. L’attività di avvio avrà i seguenti intenti MAIN e LAUNCHER elencati.

Tieni presente che non tutte le applicazioni avranno un’attività di avvio, specialmente le applicazioni senza interfaccia utente. Esempi di applicazioni senza un’interfaccia utente (e quindi un’attività di avvio) sono applicazioni preinstallate che eseguono servizi in background, come la segreteria telefonica.

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

Servizi

I servizi vengono eseguiti in background senza un’interfaccia utente. Ci sono una miriade di modi in cui possono essere avviati e quindi sono un punto di ingresso per le applicazioni. Il modo predefinito in cui un servizio può essere avviato come punto di ingresso per un’applicazione è attraverso gli Intenti.

Quando l’API startService viene chiamata per avviare un servizio, viene eseguito il metodo onStart nel servizio.

Ricevitori broadcast

I broadcast possono essere pensati come un sistema di messaggistica e i ricevitori broadcast sono gli ascoltatori. Se un’applicazione ha registrato un ricevitore per una specifica trasmissione, il codice in quel ricevitore viene eseguito quando il sistema invia la trasmissione. Ci sono 2 modi in cui un’applicazione può registrare un ricevitore: nel Manifest dell’applicazione o registrato dinamicamente nel codice dell’applicazione usando la chiamata API registerReceiver().

In entrambi i casi, per registrare il ricevitore, vengono impostati i filtri di intento per il ricevitore. Questi filtri d’intento sono le trasmissioni che dovrebbero attivare il ricevitore.

Quando vengono inviate le trasmissioni specifiche per cui il ricevitore è registrato, viene eseguito onReceive nella classe BroadcastReceiver.

Componenti esportati (Servizi & Attività)

Servizi e attività possono anche essere “esportati”, il che permette ad altri processi sul dispositivo di avviare il servizio o lanciare l’attività. I componenti vengono esportati impostando un elemento nel manifesto come qui sotto. Per impostazione predefinita, android:exported="false"a meno che questo elemento non sia impostato a true nel manifesto o che non siano definiti dei filtri di intenti per l’attività o il servizio.

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

Application Subclass

Le applicazioni Android possono definire una sottoclasse di Application. Le applicazioni possono, ma non devono definire una sottoclasse personalizzata di Application. Se un’applicazione Android definisce una sottoclasse di Application, questa classe viene istanziata prima di qualsiasi altra classe nell’applicazione.

Se il metodo attachBaseContext è definito nella sottoclasse di Application, viene chiamato per primo, prima del metodo onCreate.

NEXT > 3. Come iniziare a invertire le applicazioni Android