Acquisizione e analisi dei dispositivi

Quando i dispositivi arrivano in laboratorio, le domande passano da «che cosa potrebbe esserci qui?» a «che cosa c’è qui e possiamo dimostrarlo?». Un indirizzo di wallet trovato su un laptop è utile in tribunale solo se l’esaminatore può dimostrare che l’immagine era una copia fedele, che lo strumento ha trovato l’artefatto nel percorso indicato e che l’indirizzo è stato verificato sulla blockchain anziché dato per scontato. Questa lezione tratta l’acquisizione e l’integrità, le fonti mobili e cloud, le prove nei browser, il funzionamento degli strumenti forensi quando estraggono chiavi e indirizzi e la documentazione dei risultati.

Immagini forensi e integrità

Il fondamento dell’esame dei dispositivi è l’immagine forense: una copia bit per bit di un supporto di archiviazione, realizzata in modo da non modificare l’originale e verificata così da poter dimostrare che la copia corrisponde all’originale.

• Blocco della scrittura. I supporti di archiviazione vengono collegati tramite un write blocker hardware o software, affinché il computer di analisi non possa modificarli. Il blocker stesso dovrebbe essere testato e il suo modello e firmware registrati.
• Hashing. Durante l’acquisizione, l’esaminatore calcola un hash crittografico della sorgente e un hash dell’immagine risultante, quindi verifica che corrispondano. Oggi la scelta abituale è SHA-256; MD5 e SHA-1 sono ancora presenti negli strumenti meno recenti e possono essere registrati insieme agli altri, ma non dovrebbero essere gli unici hash.
• Formati. Le immagini possono essere raw (un semplice file byte per byte) oppure contenute in formati contenitore forensi come EWF (E01) o il formato aperto AFF4, che memorizzano metadati e checksum interni insieme ai dati.
• Copie di lavoro. L’analisi viene eseguita su copie verificate; l’immagine originale viene archiviata e ne viene ricalcolato l’hash al momento del controllo.

Gli strumenti vengono convalidati prima dell’uso. Il programma NIST Computer Forensics Tool Testing (CFTT) pubblica metodi di test e risultati per gli strumenti di imaging e i write blocker; i registri di convalida del laboratorio dimostrano che la configurazione in uso si comporta come previsto (vedi la lezione Gestione della qualità nell’unità forense).

Un registro di acquisizione riporta gli elementi essenziali:

Elemento:        CASE-0417-I-003 (SSD interno del laptop, 1 TB)
Write blocker:   hardware, modello e firmware registrati nel registro del kit
Formato immagine: E01, dimensione segmento 4 GB
SHA-256 sorgente: e41b…07af
SHA-256 immagine: e41b…07af   (corrispondono)
Inizio / fine:   2026-03-15 09:02Z / 2026-03-15 11:47Z
Esaminatore:     Esaminatore 2
Note:            rilevata crittografia dell’intero volume; un’immagine logica
                 del volume sbloccato è stata acquisita in tempo reale
                 sul luogo (vedi registro delle attività in tempo reale)

Il registro identifica l’elemento e il supporto, la protezione utilizzata, il formato, gli hash corrispondenti, gli orari e l’esaminatore. La nota spiega che il volume era crittografato e collega questa immagine all’acquisizione in tempo reale registrata sul luogo, motivo per cui è importante il registro delle attività in tempo reale descritto nella lezione Perquisizione e sequestro di criptovalute sul luogo. Gli SSD aggiungono una riserva: la loro manutenzione interna può cancellare autonomamente i dati eliminati, quindi i file di wallet cancellati potrebbero essere irrecuperabili indipendentemente dal metodo.

Acquisizione dei dispositivi mobili in generale

I telefoni contengono molti wallet e sono i dispositivi più difficili da acquisire come immagini. La pubblicazione NIST SP 800-101 Revision 1, Guidelines on Mobile Device Forensics (2014), classifica gli strumenti in cinque livelli: estrazione manuale (fotografare lo schermo), estrazione logica, dump esadecimale o JTAG, chip-off e microlettura, ciascuno più invasivo e tecnicamente complesso del precedente. Il documento sulle migliori pratiche SWGDE del 2025 raggruppa le acquisizioni in logiche (dati richiesti tramite il sistema operativo), del file system (complete o parziali, nello stato AFU o BFU) e fisiche (accesso diretto alla memoria).

I telefoni moderni crittografano i dati dell’utente, perciò ciò che è possibile acquisire dipende dal dispositivo, dal suo stato di blocco e dallo strumento; un’estrazione completa del file system da un dispositivo sbloccato o nello stato AFU raggiunge solitamente dati delle app che un backup logico non acquisisce. Gli strumenti per dispositivi mobili estraggono in genere i dati e poi li analizzano con decodificatori specifici per le app. Il supporto delle app di wallet varia ed è spesso in ritardo rispetto agli aggiornamenti delle app; gli esaminatori analizzano quindi spesso direttamente i database e i file delle preferenze di un’app di wallet, e devono dichiararlo nel rapporto. Il fatto che un parser «non abbia trovato nulla» non dimostra che l’app non contenesse nulla.

Dati cloud e sincronizzati

Un dispositivo sequestrato è spesso una porta d’accesso a dati conservati altrove: librerie fotografiche cloud con immagini di frasi seed, note sincronizzate, archivi di password con vault, backup mobili che includono dati delle app di wallet e account email pieni di notifiche di exchange. Accedere ai dati remoti tramite un dispositivo sequestrato solleva questioni di autorizzazione specifiche. L’articolo 19(2) della Convenzione di Budapest contempla l’estensione di una perquisizione a un altro sistema informatico situato nello stesso territorio; i dati conservati all’estero richiedono normalmente le procedure di cooperazione descritte nella lezione Autorizzazione legale e cooperazione internazionale. Quando possibile, si conserva l’account presso il provider e si ottengono i dati tramite richiesta di produzione, che offre una provenienza migliore rispetto a un accesso in tempo reale (vedi la lezione Account di exchange e cloud come prove).

Cronologia del browser e sessioni di exchange

Nei casi legati alle criptovalute, i browser sono fonti ricche di informazioni. I database della cronologia mostrano visite a exchange, pagine di download di wallet e block explorer; gli URL degli explorer contengono spesso l’indirizzo o il txid cercato dall’utente, collegando il dispositivo a specifici oggetti on-chain in un momento preciso. I download mostrano i programmi di installazione dei wallet; i cookie e le sessioni salvate indicano a quali account di exchange si era effettuato l’accesso; il riempimento automatico e le credenziali salvate possono rivelare gli indirizzi email degli account.

I browser basati su Chromium conservano la cronologia in un database SQLite chiamato History. Una breve query su una copia esportata elenca le visite agli explorer:

-- Database History di Chromium (SQLite); eseguire su una copia di lavoro verificata
SELECT u.url,
       u.title,
       datetime(v.visit_time / 1000000 - 11644473600, 'unixepoch') AS visit_utc
FROM visits v
JOIN urls u ON u.id = v.url
WHERE u.url LIKE '%/address/%'
   OR u.url LIKE '%/tx/%'
ORDER BY v.visit_time;

Chromium memorizza gli orari delle visite in microsecondi dal 1º gennaio 1601 UTC. La query divide per un milione per ottenere i secondi e sottrae 11.644.473.600 secondi, la differenza tra il 1601 e l’epoca Unix del 1970, poi converte il valore con la funzione datetime di SQLite; altri motori utilizzano funzioni di data diverse. I join associano ogni visita al relativo URL e i filtri mantengono le pagine degli explorer relative agli indirizzi e alle transazioni. Firefox memorizza dati comparabili in places.sqlite, con uno schema diverso e microsecondi dal 1970.

Estrazione di chiavi e indirizzi con strumenti forensi

Le suite forensi e gli strumenti open source cercano artefatti legati alle criptovalute nelle immagini e nelle acquisizioni della memoria seguendo modalità sostanzialmente simili:

I checksum eliminano la maggior parte dei falsi positivi casuali, ma non tutti: una stringa esadecimale di 40 caratteri composta solo da lettere minuscole potrebbe essere un hash e non un indirizzo. Il passo successivo è sempre una verifica on-chain, preferibilmente sul nodo dell’unità stessa, registrando l’altezza del blocco e la fonte: l’indirizzo esiste? Quando è stato attivo per la prima e l’ultima volta? È collegato agli indirizzi del caso? I dati pubblici possono essere controllati liberamente; qualsiasi risultato relativo a materiale di chiavi viene isolato immediatamente e gestito come descritto nella lezione Recupero dei wallet in virtù di un’autorizzazione legale. Le informazioni di base sui formati degli indirizzi sono disponibili nella lezione IDFE-BA Tipi di script e formati degli indirizzi.

Due fonti meritano un’analisi separata. Un’acquisizione della memoria eseguita sul luogo può contenere materiale di chiavi o una seed conservata da un wallet in esecuzione, indirizzi presenti negli appunti e frammenti di pagine di exchange; gli strumenti la cercano usando gli stessi schemi, ma i risultati non hanno un percorso di file né un timestamp, quindi il rapporto deve specificare che provengono dalla memoria acquisita a un’ora indicata. L’app complementare di un hardware wallet su un computer o un telefono conserva spesso le chiavi pubbliche estese del dispositivo, i nomi degli account e una cronologia memorizzata nella cache, che possono ricostruire l’attività on-chain del dispositivo senza toccarlo.

Documentazione dei risultati

Ogni risultato dovrebbe poter essere ritrovato da un altro esaminatore basandosi solo sul registro: hash dell’elemento e dell’immagine, percorso del file, hash del file stesso, tipo di artefatto, strumento e versione, valore estratto (troncato nei rapporti quando si tratta di materiale di chiavi), convalida eseguita e verifica on-chain con relativa fonte e altezza del blocco. Mantenere distinti i diversi livelli delle affermazioni. «Il file wallets/default_wallet è presente nell’immagine I-003 e contiene l’indirizzo bc1q…7k3f» è un fatto. «L’utente del laptop controllava bc1q…7k3f» è un’inferenza che richiede ulteriori elementi: materiale di chiavi, tracce d’uso, tempistiche e informazioni su chi ha utilizzato il dispositivo. La lezione Redazione del rapporto forense tratta il modo di esprimere questa distinzione.

Focus sull’esame: blocco della scrittura, corrispondenza degli hash della sorgente e dell’immagine, formati delle immagini e copie di lavoro; convalida degli strumenti (NIST CFTT e registri di laboratorio); livelli di estrazione della pubblicazione NIST SP 800-101 Rev. 1 e gruppi logico, del file system e fisico di SWGDE; perché è necessario verificare la copertura dei parser per le app di wallet; autorizzazioni per i dati cloud e sincronizzati raggiunti tramite un dispositivo; cronologia del browser come prova che collega un dispositivo a indirizzi e txid, inclusa la conversione degli orari di Chromium; convalida dei checksum e verifiche on-chain degli indirizzi e delle chiavi estratti; distinzione tra fatti e inferenze nei risultati.