Guida agli artefatti

Cosa contiene ogni file di un’acquisizione di Bugbane, e perché è importante dal punto di vista forense. Scritta per analisti che aprono un export decifrato; il layout è lo stesso di un’acquisizione AndroidQF. Valida per Bugbane 0.2.3.

Ogni voce risponde a due domande, nello spirito dei dizionari forensi di SocialTIC: cosa c’è in questo file? e a cosa serve? Tieni presente che la maggior parte di questi file contiene dati personali.

Metadati dell’acquisizione #

acquisition.json

Cosa: UUID, timestamp di inizio/fine, app e versione che l’hanno prodotta (androidqf_version: "Bugbane-<versione>"), informazioni sul dispositivo, stato e l’elenco dei moduli falliti o saltati. Perché: il primo file da leggere — dice se l’acquisizione è completa e quali artefatti non devi aspettarti. UUID e timestamp supportano la documentazione del caso.

hashes.csv

Cosa: lo SHA-256 di ogni artefatto dell’archivio, uno per riga. Perché: integrità e catena di custodia: verifica gli hash prima dell’analisi, citali nei report.

adb_host_key.pub

Cosa: la chiave ADB pubblica dell’installazione di Bugbane che ha fatto l’acquisizione. Perché: Bugbane acquisisce tramite il Debug Wireless del dispositivo stesso, quindi questa chiave compare legittimamente tra le chiavi ADB autorizzate. Qualsiasi altra chiave ADB sconosciuta merita attenzione.

Configurazione del dispositivo #

getprop.txt

Cosa: tutte le proprietà di sistema di Android: modello, build fingerprint, livello delle patch di sicurezza, radio, lingua, parametri di avvio. Perché: stabilisce esattamente quale dispositivo e versione del sistema stai guardando — e MVT legge da qui il fuso orario del dispositivo. Alcuni spyware alterano le proprietà o vi lasciano tracce.

settings_system.txt, settings_secure.txt, settings_global.txt

Cosa: i tre namespace delle impostazioni Android, come li stampa cmd settings list. Perché: mostra servizi di accessibilità, device admin, app predefinite, stato di ADB e altre impostazioni che gli stalkerware abusano di frequente.

selinux.txt

Cosa: lo stato di enforcement di SELinux (getenforce). Perché: un dispositivo non in modalità Enforcing è un campanello d’allarme: qualcosa potrebbe aver degradato la postura di sicurezza.

mounts.json

Cosa: i filesystem montati e le loro opzioni. Perché: mount insoliti (partizioni di sistema scrivibili, overlay) possono indicare rooting o manomissioni.

env.txt

Cosa: le variabili d’ambiente della shell ADB. Perché: contesto di base della shell da cui sono stati raccolti i dati; anomalie possono indicare un ambiente modificato.

Log ed eventi #

logcat.txt, logcat_old.txt

Cosa: i buffer di log completi di Android (logcat -d -b all), dell’avvio corrente e di quello precedente. Perché: una delle fonti più ricche: crash, concessioni di permessi, installazioni di pacchetti, eventi di rete — spesso è qui che compare la prima traccia di un’infezione. Pieni anche di dati personali.

logs/

Cosa: file di log copiati dal sistema: tracce ANR (/data/anr/), log del vendor, uiderrors.txt, log del kernel (kmsg, last_kmsg, console ramoops). Perché: i log del kernel e dei crash sopravvivono a eventi che logcat non registra, e possono rivelare tentativi di exploit o componenti che crashano sotto strumentazione.

bugreport.zip

Cosa: un bugreport Android completo (bugreportz), a sua volta uno ZIP con diagnostica estesa, inclusi dati storici. Perché: l’artefatto singolo più profondo — MVT ne estrae cronologia dei pacchetti, statistiche della batteria e altro. I bugreport hanno avuto un ruolo chiave nell’indagine NoviSpy di Amnesty.

bugreports/

Cosa: i bugreport generati sul dispositivo in passato, se ne sono stati conservati. Perché: istantanee dello stato del dispositivo in date precedenti — rare ma preziose per costruire una timeline.

Processi e app #

ps.txt

Cosa: tutti i processi in esecuzione (ps -A) con UID, PID e stato. Perché: uno spyware deve girare per funzionare. Nomi di processo e UID inattesi si confrontano direttamente con gli indicatori.

services.txt

Cosa: i servizi di sistema registrati (service list). Perché: il malware a volte registra o aggancia servizi; le voci inattese risaltano qui.

packages.json

Cosa: ogni pacchetto installato (compresi quelli disinstallati ma conservati, tramite pm list packages -U -u -i): nome del pacchetto, installer, date di installazione/aggiornamento, percorsi e hash SHA-256 degli APK, più flag euristici come sideloaded. Perché: l’artefatto centrale per rilevare stalkerware: nomi dei pacchetti e hash degli APK si confrontano direttamente con gli indicatori, e il campo installer mostra da dove è arrivata un’app.

apks/

Cosa: copie dei file APK delle app non di sistema. Perché: permette all’analista di esaminare i binari veri — calcolarne gli hash, decompilarli, sottoporli a scansione — a partire dalla sola acquisizione.

root_binaries.json

Cosa: i risultati di una ricerca di binari e app di rooting noti (come su) in $PATH e nelle posizioni comuni. Perché: la presenza di strumenti di root cambia l’intero quadro di rischio: con il root, uno spyware può nascondersi molto meglio.

Filesystem #

files.json

Cosa: un elenco ricorsivo delle directory accessibili: percorso, dimensione, timestamp, permessi, proprietario e contesto SELinux per file — nessun contenuto dei file. Perché: percorsi e nomi dei file si confrontano con gli indicatori, e i timestamp permettono di ricostruire cosa è comparso sul dispositivo e quando.

tmp/

Cosa: una copia di /data/local/tmp/. Perché: questa directory scrivibile da tutti è un classico punto di appoggio per payload consegnati via ADB; normalmente dovrebbe essere quasi vuota.