La crescente popolarità di Android, negli ultimi anni, ha contribuito ad aumentare il numero di sviluppatori mobile e delle app da essi prodotte. Tuttavia molte di queste, pur utilizzando dati sensibili, non sempre tengono conto della sicurezza. Senza grandi difficoltà, infatti, è possibile entrare in possesso del codice sorgente di un’app e di altri dati sensibili, tramite un processo di reverse engineering del pacchetto APK (contenente tutti i file binari da eseguire su Android).
In questo articolo, focalizzeremo l’attenzione sui contenuti di un generico pacchetto APK ed illustreremo il processo di decompilazione e di offuscamento del codice in esso contenuto. Per farlo, lavoreremo su Windows, sebbene questo processo può essere opportunamente adattato su altri sistemi operativi.
Anatomia di un APK
Terminato il processo di compilazione di un progetto Android, l’output generato dal nostro IDE sarà un file con estensione .apk composto da quattro elementi:
| Nome | Descrizione |
|---|---|
| classes.dex | Contiene tutti i file .class Dalvik Virtual Machine Java Virtual Machine |
| resources.arsc | Contiene le risorse compilate della nostra applicazione |
| Uncompiled resources | Rappresenta tutte le risorse non compilate dell’applicazione (ad esempio i contenuti della cartella assets |
| AndroidManifest.xml | Contiene molte informazioni fondamentali per l'utilizzo dell'app. Di questo file si è approfonditamente discusso nella Guida Android |
Di seguito è rappresentato il processo di creazione di un .apk ed il relativo contenuto.
Un file .apk .zip
Pur potendo esplorare il contenuto di un APK, non è sempre possibile leggerne i contenuti, in quanto i file .xml .dex .arsc decompilare l’APK
Prima di proseguite è bene sottolineare che, di per sé, tale procedura non è un operazione illegale, purché essa non sia usata per scopi di pirateria o analoghi.
Decompilazione di un APK
La decompilazione di un APK può essere effettuata impiegando tool come Android APK Decompiler e ApkAnalyser. Tali strumenti condividono lo stesso nucleo software di base, che si compone di tre elementi fondamentali:
- Dex2jar, .dex .class .jar
- Apktool
- Java Decompiler (JD) .jar
L’opportuna combinazione di questi elementi rende il processo di decompilazione replicabile senza l’ausilio di software di terze parti. Vediamo come.
Creiamo una nuova cartella nel nostro ambiente di lavoro che conterrà:
- i tre tool scaricati per il nostro sistema operativo;
- l’APK che vogliamo analizzare;
- l’archivio decompresso del suddetto APK, contenuto nell’omonima cartella.
Il primo passo da compiere è la decompilazione del file classes.dex
Spostiamoci all’interno della cartella dex2jar-2.0 SHIFT + tasto_destro -> Apri finestra di comando qui
d2j-dex2jar.bat "[PERCORSO_FILE]classes.dex"ottenendo come risposta:
dex2jar [PERCORSO_FILE]classes.dex -> .classes-dex2jar.jarQuesto ci informa che la decompilazione del file classes.dex
compilazione è il file classes-dex2jar.jar
A questo punto per poter leggere il codice sorgente della nostra applicazione basta eseguire JD con doppio click sull’icona, e caricare il file classes-dex2jar.jar
Come mostrato in figura 5, è possibile esplorare il sorgente dell’APK decompilato
Dex2jar permette solo di decompilare il codice sorgente ma non il file resources.arsc
- apktool.bat
- apktool_2.0.3.jar
- l’APK da decompilare.
I file apktool.bat
apktool_2.0.3.jar
apktool_2.0.3.jar
rinominato in apktool.jar
.bat
apktool d "[PERCORSO_FILE]NOME.apk"Di seguito è mostrato il risultato del prompt dei comandi che conferma la avvenuta decompilazione con successo e mostra i passi compiuti per effettuarla.
Il risultato di questa operazione è una cartella con il nome dell’APK, che conterrà il codice smali res AndroidManifest.xml smali .dex Jasmin Dedexer
Grazie all’utilizzo di questi strumenti è dunque possibile effettuare il reverse engineering dell’APK senza l’utilizzo di tool di terze parti e riuscendo
ottenendo tutte le informazioni di interesse.
Offuscamento del codice
Avendo capito quanto è semplice analizzare il contenuto di un APK, è bene capire in che modo possiamo proteggere il codice sorgente per
impedire a utenti malintenzionati di entrare in possesso del cuore della nostra app.
Una delle soluzioni più diffuse è ProGuard, un software che permette di:
- ridurre il codice eliminando le classi e le variabili non utilizzate nell’applicazione;
- ottimizzare il codice e le risorse, permettendo una riduzione del peso dell’APK;
- offuscare il codice tramite la rinominazione di classi, attributi e metodi con nomi semanticamente non significativi.
Tale soluzione consente di avere un APK ottimizzato in termini di codice e dimensioni, ma soprattutto rende più complicato il processo di decompilazione e reverse engineering dell’APK. Inoltre, ProGuard può essere integrato nel sistema di build di Android, automatizzandone quindi gli effetti tutte le volte che viene generato un nuovo APK. Non è quindi obbligatorio abilitare ProGuard, ma è fortemente consigliato farlo nel caso in cui l’applicazione dispone di funzioni sensibili per la sicurezza.
Se abilitato, ProGuard verrà eseguito dal sistema di build solo in release mode
permettendo allo sviluppatore di lavorare in debug mode
abilitarlo nel proprio progetto, basta modificare la proprietà minifyEnabled nel file build.gradle
Creato l’APK in release mode mapping outputs build
| File | Descrizione |
|---|---|
| dump.txt | Descrive la struttura interna dell’APK |
| mapping.txt | Contiene la lista delle corrispondenze tra classi, metodi, attributi originali e offuscati, ed è fondamentale per interpretare i bug report provenienti dal Play Store |
| seeds.txt | È la lista delle classi che non sono state offuscate |
| usage.txt | Specifica le porzioni di codice che sono state eliminate |
Per ulteriori dettagli su ProGuard si rimanda all’apposita pagina sulla documentazione ufficiale di Android
