Come funziona Bugbane
Questa pagina spiega cosa succede dietro le quinte, per i curiosi tecnici e per gli analisti che vogliono sapere esattamente da dove vengono i dati. Descrive Bugbane 0.2.3; il codice sorgente è il riferimento finale.
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 — una shell con 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 — ecco perché disattivarlo dopo ogni sessione è importante.
Cosa raccoglie l’acquisizione #
L’acquisizione esegue 16 moduli, ognuno dei quali produce un artefatto nell’archivio. Ogni modulo si riduce 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 che ha — 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 — 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 segnala 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. E poiché l’analisi è ripetibile, la stessa acquisizione può essere analizzata di nuovo quando gli indicatori migliorano.
Dove vivono le cose #
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.