Come funziona Bugbane
Questa pagina descrive il funzionamento interno di Bugbane, per chi è interessato ai dettagli tecnici e per gli analisti che vogliono sapere esattamente da dove vengono i dati. Descrive Bugbane 0.2.3; il codice sorgente è il riferimento autorevole.
I componenti #
Bugbane è composto dall’applicazione principale e da un insieme di librerie, tutte open source:
- bugbane — l’app stessa: la UI, la procedura guidata, la cifratura (modulo
crypto) e la logica di acquisizione, una reimplementazione della raccolta di AndroidQF che produce lo stesso layout di artefatti. - libmvt — una libreria Kotlin/Java che implementa l’analisi in stile MVT, usata per la scansione sul dispositivo.
- libadb-android-bc — la libreria client ADB, un fork di libadb-android adattato per usare Bouncy Castle. Parla il protocollo ADB su TLS, come fa
adbsu un computer. - libohttp — un client Oblivious HTTP, usato per scaricare gli aggiornamenti degli indicatori, con i suoi backend libbhttp (codifica binary HTTP) e libohttp-hpke-bc (HPKE, basato su Bouncy Castle).
Tutti i componenti sono scritti in Kotlin/Java: al momento l’app non ha dipendenze native, e questo rende la build facile da riprodurre.
Tutto avviene su un solo dispositivo perché il Debug Wireless di Android accetta connessioni dalla rete, e il telefono sta sulla sua stessa rete. Bugbane si accoppia con l’interfaccia ADB del dispositivo stesso ed esegue gli stessi comandi che un analista digiterebbe. La shell ADB ha più privilegi di una normale app.
L’accoppiamento #
- Quando abiliti il Debug Wireless e premi “Accoppia dispositivo con codice di accoppiamento”, Android avvia un servizio di accoppiamento e lo annuncia sulla rete locale (mDNS).
- Bugbane scopre il servizio e mostra la notifica “Inserisci codice di accoppiamento”.
- Il codice di 6 cifre che digiti autentica un accoppiamento TLS, dopo il quale Android ricorda la chiave ADB di Bugbane (una chiave RSA-2048 generata dall’app, conservata avvolta dal keystore hardware).
Da quel momento, Bugbane può connettersi all’interfaccia ADB ogni volta che il Debug Wireless è attivo; per questo disattivarlo dopo ogni sessione è importante.
Cosa raccoglie l’acquisizione #
L’acquisizione esegue 16 moduli, ognuno dei quali produce un artefatto nell’archivio. Ogni modulo corrisponde a un comando standard o alla lettura di file, gli stessi che usa AndroidQF. I moduli che richiedono più spazio girano per ultimi, così un dispositivo quasi pieno li salta invece di far fallire tutto.
| Modulo | Artefatto | Cosa esegue / legge |
|---|---|---|
| Env | env.txt | env |
| Dumpsys | dumpsys.txt | dumpsys |
| Logs | logs/ | copia file di log: /data/anr/, /data/log/, /data/system/uiderrors.txt, log del kernel (/proc/kmsg → logs/kmsg.txt, /proc/last_kmsg, ramoops) |
| Logcat | logcat.txt, logcat_old.txt | logcat -d -b all (buffer correnti e dell’avvio precedente) |
| GetProp | getprop.txt | getprop |
| Mounts | mounts.json | mount |
| Processes | ps.txt | ps -A |
| RootBinaries | root_binaries.json | cerca in $PATH e nelle posizioni comuni (/system/bin, /system/xbin, /sbin, /su/bin, /vendor/bin) binari e app di rooting noti |
| Services | services.txt | service list |
| Settings | settings_<namespace>.txt | cmd settings list <namespace> per ogni namespace (system, secure, global) |
| SELinux | selinux.txt | getenforce |
| Temp | tmp/ | copia /data/local/tmp/ |
| Files | files.json | find <dir> -type f -printf … sulle directory accessibili: percorso, timestamp, dimensione, permessi, contesto SELinux per file |
| OldBugreports | bugreports/ | copia i bugreport generati in passato (/data/user_de/0/com.android.shell/files/bugreports/) |
| Bugreport | bugreport.zip | bugreportz -p |
| Packages | packages.json, apks/ | pm list packages -U -u -i più pm path; registra origine dell’installazione e hash SHA-256 degli APK, e copia gli APK non di sistema |
Accanto agli artefatti, l’archivio contiene acquisition.json (UUID, timestamp, versione dell’app, stato per modulo), hashes.csv (SHA-256 di ogni artefatto, per l’integrità) e adb_host_key.pub (la chiave ADB di Bugbane stesso, così l’analisi può distinguerla dalle chiavi sconosciute).
Ogni artefatto è cifrato mentre viene scritto: l’archivio su disco non è mai in chiaro.
Cosa fa l’analisi #
Quando premi “Esegui analisi”, Bugbane:
- Carica gli indicatori più recenti disponibili: il set incluso nell’app, più gli aggiornamenti scaricati in privato da mvt-indicators.
- Legge l’archivio cifrato in streaming, decifrando in memoria, e passa ogni artefatto a libmvt, che usa lo stesso approccio di parsing e matching di
mvt-android. - Confronta i record con gli indicatori (STIX2: domini, processi, nomi e percorsi di file, hash, id di app, URL…) e applica euristiche, per esempio segnalando i pacchetti installati manualmente senza un installer noto.
- Salva il risultato accanto all’acquisizione, con la data, la versione degli indicatori usata e ogni corrispondenza con la sua gravità: CRITICAL, HIGH, MEDIUM, LOW, INFO, LOG.
Un artefatto malformato non interrompe la scansione: ogni file è analizzato in modo indipendente. Poiché l’analisi è ripetibile, la stessa acquisizione può essere analizzata di nuovo quando sono disponibili indicatori aggiornati.
Dove sono salvati i dati #
Tutto resta nella memoria privata dell’app: gli archivi cifrati, i risultati delle analisi, le chiavi avvolte. Il quadro completo della protezione dei dati è nell’Architettura di sicurezza.