Acquisizione e analisi di Android

Per estrarre efficacemente i dati Android, è necessario sapere dove si trovano.

• /data/data/<package>/ — sandbox di ciascuna app: database, shared_prefs, file e cache.
• /data/media/0/ — memoria dell'utente (foto, download).
• /data/system/ — account, impostazioni di blocco e statistiche di utilizzo.

La maggior parte delle evidenze delle app si trova nei database SQLite e nei file XML delle preferenze all'interno del sandbox di ogni app, che non è leggibile senza root o un meccanismo di backup.

Android Debug Bridge (ADB) è il principale canale per l'acquisizione logica. Richiede che il debug USB sia abilitato e che la chiave dell'host sia autorizzata.

• Senza il debugging abilitato e lo schermo sbloccato, l'accesso ADB è bloccato.
• La richiesta di autorizzazione modifica già lo stato del dispositivo: la documenti.

Verifichi prima la connettività e acquisisca le proprietà del dispositivo:

adb backup produce un archivio .ab dei dati delle app che supportano il backup. Non richiede root ed è ampiamente disponibile, ma presenta dei limiti: molte app impostano allowBackup=false.

• Acquisisce i dati delle app, gli APK (con -apk) e la memoria condivisa.
• Non include le app che rinunciano al backup né i record eliminati.

Crei e converta un backup per l'analisi:

Un'estrazione del file system copia l'albero delle directory, inclusi i sandbox delle app e i file journal SQLite WAL/SHM che contengono i record non sincronizzati.

• Richiede root, un agente forense o un metodo basato su exploit/bootloader.
• Conserva i file -wal e -shm: sono fondamentali, perché le righe più recenti potrebbero trovarsi solo al loro interno.

Quando estrae database SQLite, recuperi sempre anche i file journal associati:

Un'immagine fisica è una copia bit per bit della NAND, incluso lo spazio non allocato in cui potrebbero persistere dati eliminati. Sui moderni dispositivi Android è il metodo più difficile da ottenere.

• La crittografia FBE fa sì che un dump grezzo della NAND sia testo cifrato senza la chiave dell'utente.
• I metodi includono exploit del produttore, modalità EDL/bootloader o chip-off (ultima risorsa, distruttivo).
• In pratica, un'estrazione del file system nello stato AFU fornisce spesso più dati utilizzabili di un dump fisico crittografato.

Scelga l'acquisizione fisica solo quando è giustificata e la decrittografia è possibile.

La maggior parte degli artefatti Android è costituita da database SQLite. Gli analisti li interrogano direttamente per recuperare messaggi, registri delle chiamate e timestamp.

• Li apra in sola lettura per evitare di modificare il file delle evidenze.
• I timestamp sono spesso espressi in millisecondi dall'epoca Unix.

Ispezioni il database dei contatti da un'estrazione:

L'eliminazione di una riga in SQLite spesso si limita a contrassegnare come libero lo spazio della relativa pagina. I residui recuperabili si trovano in:

• Pagine della freelist e aree non allocate del file .db.
• Il write-ahead log -wal, che conserva versioni delle righe precedenti al checkpoint.

Gli strumenti di carving ricostruiscono questi record. Esegua un passaggio di recupero su un database:

La creazione di una timeline mette in relazione gli eventi tra le app. La difficoltà sta nei numerosi formati di timestamp utilizzati da Android.

• Unix epoch (ms) — la maggior parte dei database dei messaggi.
• Unix epoch (s) — molti log di sistema.
• WebKit/Chrome time — microsecondi dal 1601 (cronologia del browser).

Normalizzi sempre in UTC e annoti il fuso orario del dispositivo. Esempio di conversione in SQLite:

Oltre ai dati delle app, gli artefatti del sistema Android rivelano il comportamento dell'utente e l'utilizzo del dispositivo.

• usagestats — quali app sono state eseguite e quando.
• accounts.db / accounts_ce.db — account Google e account delle app collegati.
• net stats / netpolicy — utilizzo dei dati per app.
• Wi-Fi config (WifiConfigStore.xml) — reti note, utili per il contesto della geolocalizzazione.

Questi dati confermano o contraddicono le dichiarazioni su chi ha utilizzato il dispositivo e quando.

L'analisi manuale non è scalabile. ALEAPP (Android Logs Events And Protobuf Parser) acquisisce un'estrazione del file system e produce un report strutturato in formato HTML/CSV.

• Analizza usagestats, attività recenti, notifiche, autorizzazioni delle app e altro.
• Lo utilizzi per una prima selezione, quindi verifichi manualmente i risultati principali nei database originali.

Esegua ALEAPP su una directory di estrazione:

Non si fidi mai di un singolo strumento. Convalidi i risultati automatizzati rispetto ai dati sorgente e tra strumenti diversi.

• Esegua nuovamente manualmente le query principali in sqlite3 per confermare i risultati dell'analizzatore.
• Presti attenzione ai segnali anti-forensi: log cancellati, timestamp modificati, app per la cancellazione sicura o app di chat con impostazioni per i messaggi a scomparsa.
• Verifichi che l'hash dell'immagine corrisponda ancora prima e dopo l'analisi.

La riproducibilità e la convalida incrociata rendono le conclusioni difendibili.

Sta estraendo il database SQLite di un'app di chat. Quali file associati deve raccogliere per evitare di perdere i messaggi inviati di recente?

Ora è in grado di acquisire e analizzare le prove Android dall'inizio alla fine.

• I dati delle app risiedono in sandbox separate per ogni app, sotto forma di database SQLite e preferenze XML.
• ADB backup = semplice acquisizione logica; l'estrazione del file system (root) conserva il WAL; l'acquisizione fisica è la più difficile con FBE.
• Recuperi i record eliminati dalle pagine freelist e dal WAL.
• Normalizzi i timestamp in UTC; decodifichi i formati epoch e WebKit.
• Utilizzi ALEAPP per la prima selezione, quindi convalidi manualmente con sqlite3.
• Presti attenzione alle manomissioni anti-forensi e verifichi nuovamente l'hash dell'immagine.

Prossimo argomento: iOS.