SeizeDROID: Guida Completa all'Acquisizione Forense Logica Android

SeizeDROID è uno strumento CLI per l'acquisizione forense logica di dispositivi Android via USB+ADB. Un singolo binario Go statico — zero dipendenze runtime — che estrae file utente, log di sistema, bugreport, identità hardware, APK firmati e backup WhatsApp criptati, producendo un pacchetto cifrato AES-256-GCM con marca temporale RFC 3161 e report HTML interattivo da 540+ pagine. Clicca su ogni immagine per ingrandirla.

Cos'è SeizeDROID e quando si usa

SeizeDROID copre il caso d'uso dominante dell'acquisizione mobile in ambito peritale: il dispositivo Android è disponibile, sbloccato, con Debug USB attivo. L'operatore deve documentare la superficie utente — foto, video, documenti, messaggi, log — con integrità dimostrabile e chain of custody completa, in modo ripetibile e riverificabile.

SeizeDROID non è un tool di imaging fisico. Non produce una copia bit-a-bit del flash storage. Produce un'acquisizione logica mirata ai dati accessibili via ADB — il perimetro è dichiarato esplicitamente nel report finale (sezione "Acquisition Scope") per trasparenza verso il giudice e la controparte. L'acquisizione logica e quella fisica sono complementari: SeizeDROID copre il primo livello, il laboratorio chip-off/JTAG il secondo.

Destinatari: consulenti tecnici d'ufficio (CTU), consulenti tecnici di parte (CTP), digital forensics examiner, periti informatici, forze dell'ordine con autorizzazione giudiziaria.

Architettura: binario Go statico via USB+ADB

SeizeDROID è un singolo eseguibile compilato con CGO_ENABLED=0: gira su Linux (primario) e macOS (secondario) senza installazione. L'unico prerequisito è adb nel PATH.

sudo apt install android-tools-adb                        # una volta
./seizedroid-linux-amd64 backup --apikey CHIAVE_API       # acquisizione completa

Il binario contiene tutto via go:embed: Bootstrap CSS/JS/Icons (~750 KB), logo, template HTML, certificati CA per riverifica offline. Nessuna dipendenza esterna, nessun server da configurare, nessun framework da installare. Dimensione binario release (con garble): ~16 MB.

Flusso di esecuzione: 13 step

Ogni acquisizione segue un flusso deterministico di 13 step, ciascuno loggato in operations-log.txt con timestamp UTC al millisecondo e offset NTP:

1. DETECT — adb devices -l + adb shell getprop. Verifica del device nella matrice validata.
2. CONNECT — Verifica stato "device" authorized. Samsung Auto Blocker detection.
3. SCAN — DetectStoragePaths() + adb shell find -exec stat single-pass.
4. TRANSFER — Worker pool (default 4). adb pull -a + os.Chtimes + SHA-256/SHA-1/MD5 inline.
5. SYSLOG — 22 comandi adb shell su pool 4 goroutine, timeout 30s per comando.
6. FORENSIC — Root detection, device identity, screenshot, bugreport, APK, GPS, WhatsApp backup, file cancellati. Con root: database privati.
7. WHATSAPP — Acquisizione backup criptati .crypt14/.crypt15.
8. MANIFEST — WriteManifest con MD5+SHA-1+SHA-256 + 3 timestamp + identity.
9. REPORT HTML — Thumbnail, waveform, video meta su pool 8 worker. 8 pagine + 12 analisi bugreport.
10. REPORT TXT + TSR — Ledger autoritativo + 2 marche RFC 3161 in parallelo.
11. PDF + VERIFY — Report PDF, landing page, verify.sh, bundle CA.
12. ESCROW + CIPHER — ZIP Store-mode, ReserveEscrow, EncryptFileStreamingGCM, pending record.
13. UNLOCK — (comando separato) Verifica fingerprint, decrypt, INSERT backend, scala slot.

Device Detection e Validated Matrix

All'avvio, SeizeDROID legge manufacturer, model e SDK level dal device e li confronta con una matrice di dispositivi validati (validated_devices.json, embedded nel binario). Se il device non è in matrice, il tool si ferma con un messaggio esplicito e richiede il flag --force-untested-device per proseguire — con log nel report chain-of-custody.

Samsung Auto Blocker detection: sui device Samsung, SeizeDROID rileva la feature che blocca i comandi ADB in ingresso e guida l'operatore a disabilitarla nelle impostazioni.

Scansione single-pass con find -exec stat

La scansione usa un singolo comando ADB:

adb shell find /storage/emulated/0 -exec stat -c '%X|%Y|%Z|%s|%n' {} +

Raccoglie path, 3 timestamp (access/modify/change) e size in un unico passaggio. Nessun batch separato, nessuna rilettura. Il find parte da /storage/emulated/0 (percorso reale, non il symlink /sdcard) ed include automaticamente eventuali SD card esterne rilevate sotto /storage/. Il risultato è streamato via StdoutPipe — il find restituisce exit code 1 per "Permission denied" su alcune directory protette, ma il parsing gestisce il caso senza interrompere la scansione.

Transfer con SHA-256 inline e timestamp preservation

Il trasferimento usa un worker pool producer-consumer (default 4, configurabile con --workers). Ogni worker:

1. Esegue adb pull -a (il flag -a preserva i timestamp)
2. Calcola MD5 + SHA-1 + SHA-256 inline via io.MultiWriter — nessuna rilettura del file
3. Applica os.Chtimes con access e modify time originali dal device
4. Registra il file nel manifest con i 3 hash e i 3 timestamp

Collision dedup: se due file su path diversi del device hanno lo stesso basename, il manager aggiunge un suffisso (N) prima dell'estensione. Retry opzionale con --retries N e backoff quadratico (0s, 1s, 4s, 9s) per cavi USB instabili.

22 log di sistema e bugreport completo

22 comandi adb shell eseguiti su pool 4 goroutine parallele (timeout 30s per comando):

• getprop — proprietà di sistema complete
• logcat -d — 4 buffer (main, events, radio, crash)
• dumpsys — 8 servizi (battery, wifi, connectivity, telephony, package, meminfo, diskstats, usagestats)
• settings list — 3 namespace (global, secure, system)
• pm list packages -3 -f, df -h, mount, uptime, uname -a

Ogni log hashato con SHA-256 e incluso nell'inventario report.txt (sezione 8.5).

Analisi forense: identità, APK, GPS, file cancellati

La fase FORENSIC raccoglie:

• Device Identity — IMEI per ogni SIM slot (dual-SIM), IMSI, ICCID, MAC Wi-Fi/Bluetooth, Android ID, piattaforma hardware. Estratti via service call iphonesubinfo + getprop.
• Screenshot — adb exec-out screencap al momento dell'estrazione
• Bugreport — adb bugreport completo (80+ MB)
• APK terze parti — pool 4 worker per dumpsys + pull + hash + signature parse (v1 interno + avast/apkverifier v2/v3/v4)
• GPS da MediaStore — query content://media/external/images/media per coordinate EXIF
• File cancellati — scan .trashed-*, .Trash/, .Recycle/, thumbnails
• Backup WhatsApp — .crypt14/.crypt15 da /Android/media/com.whatsapp/
• Con root — database privati da /data/data/: WhatsApp, Telegram, SMS, contatti, Chrome, Wi-Fi, calendario, Signal, Instagram, Messenger, Viber

Bugreport Parser: 244 sezioni, 292 servizi, 12 analisi curate

Il parser streaming processa bugreport da 80+ MB e produce 12 analisi curate:

1. Battery — estimated power use, capacity, drain, top UIDs. Badge zero-drain per device USB-bound.
2. Wi-Fi — reti salvate, SSID/BSSID/RSSI correnti
3. Network — interfacce, DNS, traffico per UID (Android 10-15)
4. Processes — snapshot top/cpuinfo
5. Crashes — ANR, Java crash, native crash, tombstones, WTF da dropbox + DUMP TRACES
6. Packages — app con permessi pericolosi, dedupe, device admin, accessibility flag
7. Usage Stats — uso app per pacchetto con foreground time
8. AppOps — permessi per operazione con timing (camera, microphone, location)
9. Location — provider attivi + richieste per app
10. Accessibility — servizi a11y registrati (red flag spyware)
11. Notifications — active + historical, preview messaggi
12. Jobs & Alarms — persistenza background, job schedulati

Parser tolleranti: formato non riconosciuto → pagina "not available" invece di crash. Sezioni >16 MiB spillano su disco temporaneo dopo il parse.

Le 244 sezioni top-level e i 292 servizi dumpsys sono navigabili individualmente con filtro live e link diretto. Ogni sezione mostra nome, comando, numero di righe e dimensione. Le sezioni grandi (>4 MiB) mostrano un estratto con link all'archivio bugreport originale.

manifest.json: inventario multi-hash con 3 timestamp

Il manifest è il file macchina dell'acquisizione. Per ogni file estratto contiene:

• 3 hash: MD5, SHA-1, SHA-256
• 3 timestamp originali del device: access_time, modify_time, change_time
• extracted_at: timestamp UTC dell'estrazione sull'host
• integrity_ok: risultato verifica post-pull (se --verify-remote-hash)
• category: Photos, Video, Audio, Documents, Archives, Deleted, SystemLogs, Forensic
• source_app: app di provenienza (WhatsApp, Telegram, Camera, Downloads, ...)

Il manifest include anche la sezione Identity (IMEI, IMSI, ICCID, MAC) e i metadati dispositivo (modello, seriale, Android version, API level). Versione formato "1.0" con forward-compat guard (SupportedManifestMajor=1). Marcato con TSR RFC 3161 (manifest.json.tsr).

report.txt: ledger autoritativo con sezioni 8.1-8.6

Il report.txt è il documento autoritativo dell'acquisizione: leggibile senza software, verificabile con sha256sum. 8 sezioni numerate + disclaimer "Acquisition scope" (sezione 0):

0. Acquisition Scope — cosa l'acquisizione logica cattura e cosa non cattura
1. Acquisition Info — UUID, operatore, supervisore, caso, data
2. Device Info — modello, seriale, Android, API level, identity
3. Collection Summary — conteggi per categoria, dimensioni, durata
4. NTP Synchronization — offset prima/dopo, server usato
5. Chain of Custody — tool version, binary MD5/SHA-1/SHA-256, device matrix status
6. Timestamps — TSA provider, manifest.json.tsr, report.txt.tsr
7. Encryption — algoritmo, ZIP SHA-256, .enc SHA-256
8. File Inventory — 6 sotto-tabelle multi-hash

L'inventario (sezione 8) è suddiviso in:

• 8.1 MEDIA FILES (Photos + Video + Audio)
• 8.2 DOCUMENTS & ARCHIVES
• 8.3 DELETED / TRASHED FILES RECOVERED
• 8.4 THIRD-PARTY APKs (con subject certificato firma + SHA-1 fingerprint + flag self-signed)
• 8.5 SYSTEM LOGS
• 8.6 REPORT-SIDE ARTIFACTS (manifest.json, operations-log.txt, report.pdf, .tsr, ...)

Ogni file con MD5 + SHA-1 + SHA-256 su tre righe separate (nessuna riga supera 80 caratteri). Marcato con TSR RFC 3161 (report.txt.tsr).

Report HTML: 540+ pagine self-contained

Il report HTML è generato automaticamente durante l'acquisizione. Bootstrap CSS/JS/Icons embeddati nel binario via go:embed, scritti una volta in report/assets/. Nessuna richiesta di rete — funziona completamente offline.

8 pagine principali: Overview, Images (tabella+griglia+lightbox), Images Map (GPS Leaflet), Video (player+metadati codec), Audio (player+waveform), Documents (preview inline), Forensic (identity+APK+WhatsApp+GPS+deleted), System Logs (22 log espandibili).

12 pagine analisi bugreport: Battery, Wi-Fi, Network, Processes, Crashes, Packages, Usage Stats, AppOps, Location, Accessibility, Notifications, Jobs & Alarms.

Centinaia di pagine raw: ogni sezione e ogni servizio dumpsys su pagina dedicata.

Generazione parallelizzata su pool 8 worker (auto-detect runtime.NumCPU(), cap 8): EnsureVideoMeta (ffprobe), EnsureWaveforms (ffmpeg), EnsureThumbnails (heif-convert/ffmpeg). Fase HTML gen misurata: da 3:00 a 1:06 su acquisizione reale (760 audio + 119 video + 1599 foto).

Cifratura AES-256-GCM chunked e escrow

Il pacchetto è cifrato con AES-256-GCM chunked: chunk da 1 MiB, nonce = baseNonce XOR counter, tag GCM per chunk, trailer uint64 con plaintext size (anti-troncamento). Formato .zip.enc con magic SDROIDx01.

La chiave AES è generata dal server (crypto-work.php) e rilasciata solo allo sblocco esplicito (seizedroid unlock). L'acquisizione e lo sblocco sono disaccoppiati: l'operatore esegue il backup sul campo e può decidere di sbloccare in un secondo momento — giorni, settimane o mesi dopo, quando il caso lo richiede. Fino allo sblocco il pacchetto resta cifrato, la chiave sul server, e gli slot non vengono scalati. Il pending record in ~/.pending/<UUID>.json contiene un APIKeyFingerprint (sha256(apikey + ":" + acquisition_id)), non la chiave in chiaro — mitigazione contro infostealer.

Handler globale SIGINT/SIGTERM: in caso di interruzione, la directory output, lo ZIP, il file cifrato e i TSR vengono rimossi con ForceRemoveAll (chmod + fallback rm -rf). Nessun artefatto in chiaro sopravvive a un Ctrl+C.

verify.sh e VERIFICATION.md: riverifica indipendente

Ogni acquisizione include verify.sh — script bash eseguibile che usa solo strumenti standard (openssl, jq, sha256sum). 4 step automatici:

1. Verifica integrità manifest.json (SHA-256 vs TSR)
2. Validazione timestamp RFC 3161 (manifest.json.tsr + report.txt.tsr)
3. Ri-calcolo hash SHA-256 per ogni file nel manifest
4. Verifica SHA-256 dello ZIP

Output: PASS/FAIL con counter ok/mismatch/missing. VERIFICATION.md guida l'auditor esterno passo per passo con soli strumenti standard, senza bisogno di possedere SeizeDROID. Il bundle tsa-ca/ (FreeTSA CA + signing cert) permette la riverifica offline senza dipendere dal server TSA.

Tariffazione flat e marca temporale qualificata

20 slot fissi per ogni device (costante, indipendente dalla dimensione dello storage). +2 slot per marca temporale qualificata InfoCert (--tsa infocert). Gli slot vengono scalati al momento dello sblocco, non dell'acquisizione. In caso di fallimento, vengono riaccreditati.

Il backend memorizza solo metadati e report.txt (pochi KB per acquisizione) — il pacchetto cifrato resta sulla macchina dell'operatore. I campi billable_size/media_bytes nel manifest restano per analytics ma non guidano il calcolo slot.

Catena di custody e tool attestation

Il pending record e il report.txt includono:

• tool_version + binary_md5/sha1/sha256 (self-attestation del binario)
• operator_name/id + supervisor_name/id (principio quattro-occhi)
• case_number (numero pratica)
• device_matrix_status (VALIDATED o NOT IN MATRIX)
• adb_commands.log — trascrizione di ogni comando ADB con timestamp UTC ms, exit code, durata, stderr
• operations-log.txt — JSONL con timestamp ms e offset NTP per ogni step

La firma di deposito in cancelleria resta responsabilità del tecnico (CNS/smartcard CAdES/PAdES) — SeizeDROID copre integrità e "quando", il "chi" è out-of-band.

Requisiti e piattaforme supportate

Target binario: linux/amd64, linux/arm64, darwin/arm64, darwin/amd64.