Struttura delle app Android

Un'app Android viene distribuita come APK (Android Package). In realtà è un archivio ZIP contenente il codice compilato, le risorse e i metadati.

Essendo un file ZIP, può semplicemente decomprimerlo per esaminarne i contenuti: è il primo passo nel pentesting mobile.

Un APK estratto contiene:

• AndroidManifest.xml: configurazione dell'app.
• classes.dex: bytecode compilato.
• res/ e resources.arsc: risorse.
• lib/: librerie native.
• META-INF/: informazioni sulla firma.

AndroidManifest.xml dichiara i componenti, le autorizzazioni e la configurazione dell'app. Nell'APK si trova in formato XML binario, che gli strumenti possono decodificare.

È il file più importante in assoluto per comprendere la superficie di attacco di un'app.

Il codice sorgente Java/Kotlin viene compilato nel bytecode DEX (Dalvik Executable) contenuto in classes.dex. Le versioni moderne di Android lo eseguono tramite ART (Android Runtime).

Il DEX può essere convertito nuovamente in una forma vicina al codice leggibile: è ciò che sfrutta l'analisi statica degli APK.

Le app Android sono costituite da quattro tipi di componenti:

• Activities: schermate / interfaccia utente.
• Services: attività in background.
• Broadcast Receivers: rispondono agli eventi di sistema.
• Content Providers: condividono dati tra le app.

Un componente contrassegnato con android:exported="true" può essere invocato da altre app. Se un componente di questo tipo esegue azioni sensibili senza controlli, costituisce una superficie di attacco.

I pentester cercano activities, services e providers esportati che divulgano dati o eseguono azioni privilegiate.

Le app richiedono autorizzazioni nel manifest (ad esempio INTERNET, READ_SMS, ACCESS_FINE_LOCATION).

Autorizzazioni eccessivamente ampie possono indicare comportamenti rischiosi o un accesso ai dati superiore al necessario. Anche le autorizzazioni personalizzate possono essere configurate erroneamente e consentire accessi non autorizzati.

Android isola ogni app nella propria sandbox, associata a un UID Linux univoco. Per impostazione predefinita, le app non possono leggere i dati delle altre.

Le vulnerabilità emergono quando le app indeboliscono questo confine, ad esempio con file leggibili da chiunque o provider esposti.

Un'app installata memorizza i dati privati in /data/data/<package>/: database, preferenze condivise e file.

Su un dispositivo con root o tramite i backup, un pentester esamina questa directory alla ricerca di segreti memorizzati in modo non sicuro, argomento che verrà approfondito in una lezione successiva.

Ogni APK è firmato digitalmente; la firma si trova in META-INF/. Android la verifica durante l'installazione e negli aggiornamenti.

Se modifica e riconfeziona un'app, deve firmarla nuovamente: per questo gli sviluppatori si affidano alla firma per rilevare manomissioni.

La logica critica per le prestazioni o offuscata può trovarsi nelle librerie native (file .so) sotto lib/, compilate da C/C++.

Queste librerie non fanno parte del DEX, quindi richiedono un'analisi separata con disassembler nativi. A volte gli sviluppatori vi nascondono segreti, credendo erroneamente che il codice nativo sia più difficile da esaminare.

Ricordi quale attributo del manifest espone un componente alle altre app.

Ora conosce la struttura delle app Android:

• Un APK è un file ZIP che contiene AndroidManifest.xml, classes.dex, risorse e dati della firma.
• Le app usano quattro componenti; quelli esportati costituiscono una superficie di attacco.
• Le autorizzazioni e la sandbox specifica di ogni app regolano l'accesso; i dati privati si trovano in /data/data/.
• Gli APK sono firmati per rilevare le manomissioni.

Nella prossima lezione decompilerà un APK mediante l'analisi statica.