Acquisire uno smartphone non significa leggerlo tutto: come funzionano davvero i software di mobile forensics

Dott. Domenico Moretta
Criminalista forense – Digital & Audio Forensics Expert
Studioso di diritto delle nuove tecnologie e prova digitale

Tra acquisizione logica, Full File System, cifratura e interpretazione degli artefatti digitali

«Riuscite a recuperare le conversazioni WhatsApp?»

«È possibile vedere che cosa è stato cancellato?»

«Se il telefono è sbloccato, perché non si riesce a estrarre tutto?»

Sono domande assolutamente comprensibili. Nascono, tuttavia, da una rappresentazione semplificata della mobile forensics: l’idea che il consulente colleghi lo smartphone a un software, prema un pulsante e ottenga automaticamente una copia completa, leggibile e perfettamente organizzata di tutto ciò che il dispositivo contiene o ha contenuto in passato.

La realtà tecnica è molto diversa.

L’acquisizione forense di uno smartphone non è un’operazione unica e standardizzata, ma un processo condizionato da numerose variabili: modello del dispositivo, versione del sistema operativo, livello delle patch di sicurezza, stato di blocco, disponibilità del codice di accesso, tipo di cifratura, applicazioni installate, versione delle singole app e metodo di acquisizione concretamente supportato.

Per questa ragione, la domanda corretta non è semplicemente: «Il software supporta questo telefono?». Occorre chiedersi:

• quale metodo di acquisizione sia disponibile;
• quali aree del dispositivo siano effettivamente accessibili;
• quali dati vengano acquisiti;
• quali di questi dati possano essere decifrati;
• quali artefatti il software sia in grado di interpretare;
• quali informazioni richiedano, invece, un’analisi manuale.

Comprendere questa distinzione è fondamentale anche per valutare correttamente il lavoro del consulente e i limiti oggettivi dell’accertamento.

I software forensi non sono macchine della verità

Soluzioni come Cellebrite UFED e Inseyets, MSAB XRY, Magnet Verakey e AXIOM, Oxygen Forensic Detective, Belkasoft X o MOBILedit Forensic rappresentano alcuni dei principali strumenti impiegati nella mobile forensics.

Si tratta di piattaforme estremamente evolute, che combinano differenti tecniche di accesso, acquisizione, decodifica e analisi. Nessuna di esse, tuttavia, possiede una capacità universale e invariabile.

Ogni prodotto dispone di una propria matrice di compatibilità, di specifici metodi di accesso e di parser sviluppati per interpretare determinate strutture dati. Il risultato può quindi cambiare non soltanto tra due software diversi, ma anche tra due versioni dello stesso software o tra due dispositivi apparentemente identici che utilizzano versioni differenti del sistema operativo o delle applicazioni.

La stessa documentazione commerciale dei produttori distingue chiaramente tra acquisizioni logiche, acquisizioni del file system, Full File System e acquisizioni fisiche. Cellebrite, ad esempio, indica espressamente la disponibilità di molteplici metodi di raccolta, comprese acquisizioni FFS e fisiche; MSAB distingue a sua volta tra XRY Logical, che comunica con il sistema operativo, e XRY Physical, orientato a forme di accesso più profonde alla memoria del dispositivo. Cellebrite UFED, MSAB XRY Logical, MSAB XRY Physical.

Queste definizioni non descrivono semplicemente diverse “modalità dello stesso programma”. Identificano livelli di accesso differenti, dai quali dipende la quantità e la qualità dei dati disponibili.

Acquisizione e analisi sono due operazioni diverse

Uno degli aspetti meno compresi riguarda la distinzione tra acquisizione e analisi.

Durante l’acquisizione il software tenta di ottenere dati dal dispositivo mediante uno o più metodi tecnici. Successivamente, nella fase di elaborazione e analisi, quei dati vengono esaminati e trasformati in artefatti comprensibili: conversazioni, contatti, chiamate, posizioni, fotografie, cronologie web, eventi di sistema e così via.

Il fatto che un dato sia stato acquisito non significa necessariamente che sia stato anche correttamente interpretato.

Un database può essere presente nella copia forense, ma non comparire nel report perché:

• la relativa applicazione non è supportata;
• la versione dell’app è più recente rispetto al parser;
• la struttura del database è cambiata;
• il contenuto è ulteriormente cifrato;
• alcuni collegamenti tra database e file multimediali non sono stati ricostruiti;
• il software non riconosce la posizione nella quale l’app ha iniziato a memorizzare i dati.

Questo è uno dei punti centrali dell’articolo di Heather Barnhart dedicato alle applicazioni di terze parti: gli sviluppatori modificano continuamente app, database e formati di memorizzazione, mentre gli strumenti forensi devono inseguire tali cambiamenti. Una nuova tabella, una colonna aggiuntiva o lo spostamento dei dati in un diverso archivio possono essere sufficienti a rendere incompleta la decodifica automatica. Forensic Magazine, “Leveraging the Third-party App Evidence ‘Goldmine’”.

In altri termini, il report prodotto dal software non coincide necessariamente con l’intero contenuto dell’acquisizione.

Acquisizione logica: rapida, utile, ma selettiva

L’acquisizione logica ottiene i dati che il dispositivo e il sistema operativo rendono disponibili attraverso interfacce autorizzate, procedure di sincronizzazione, backup, agenti o altri canali applicativi.

Può consentire di acquisire, secondo il dispositivo e il metodo utilizzato:

• rubrica e registro chiamate;
• SMS e MMS;
• fotografie e video accessibili;
• informazioni sul dispositivo;
• dati ottenibili mediante backup;
• contenuti di alcune applicazioni;
• determinate categorie selezionate dall’operatore.

È normalmente meno invasiva e può essere più rapida, ma non permette necessariamente di accedere alle directory private di tutte le applicazioni, ai file di sistema, ai database protetti o ai residui di dati eliminati.

Dire che un telefono è stato “acquisito” logicamente, pertanto, non significa che ne sia stato riprodotto l’intero contenuto.

Anche la disponibilità di un backup non garantisce che ogni applicazione vi riversi integralmente i propri dati. Alcune informazioni possono essere escluse per scelta dello sviluppatore, protette separatamente o conservate soltanto sul dispositivo o nel cloud.

Full File System: un accesso più profondo, non una garanzia assoluta

La Full File System, comunemente indicata come FFS, consente di ottenere una rappresentazione molto più estesa del file system del dispositivo.

Rispetto a una comune acquisizione logica, può includere:

• directory private delle applicazioni;
• database SQLite;
• file di configurazione;
• registri di sistema;
• cache;
• dati sull’utilizzo delle app;
• file temporanei;
• metadati non visibili all’utente;
• residui presenti in tabelle, file accessori o archivi non più utilizzati.

Un confronto pubblicato da Magnet Forensics mostra, su uno specifico dispositivo di test, differenze molto rilevanti tra acquisizione logica e FFS per quantità di artefatti relativi a comunicazioni, posizioni, attività web e informazioni di sistema. Il dato non deve essere generalizzato come una percentuale valida per ogni telefono, ma dimostra quanto il metodo di acquisizione possa incidere sull’ampiezza del materiale disponibile. Magnet Forensics, “Full file system extractions uncovered”.

La FFS non deve tuttavia essere descritta come una copia infallibile di “tutto ciò che esiste nel telefono”.

Anche quando tecnicamente disponibile, il suo contenuto dipende dallo stato del dispositivo, dalle chiavi di cifratura accessibili, dal metodo utilizzato e dalle protezioni implementate dal sistema operativo o dalle singole applicazioni.

Inoltre, acquisire un file non significa automaticamente poterne comprendere il contenuto. Un database può essere presente ma cifrato; può essere leggibile ma non supportato dal parser; oppure può richiedere una ricostruzione manuale mediante interrogazioni SQL e confronto con altri archivi.

Acquisizione fisica: un concetto da contestualizzare

L’acquisizione fisica viene spesso rappresentata come il livello massimo e definitivo. In termini generali, mira a ottenere dati direttamente dalla memoria del dispositivo o una sua immagine a basso livello.

Sui dispositivi moderni, però, la disponibilità di una copia fisica non implica necessariamente la disponibilità di dati leggibili.

iOS e Android utilizzano sistemi di cifratura strettamente integrati con l’hardware, con il codice di sblocco e con lo stato operativo del dispositivo. Apple applica meccanismi di Data Protection basati su chiavi associate ai singoli file o alle loro porzioni; Android, a partire dalle versioni moderne, utilizza la file-based encryption, che può proteggere aree diverse mediante chiavi differenti. Apple Platform Security, Android Open Source Project.

Un’immagine della memoria composta prevalentemente da contenuti cifrati può quindi essere formalmente molto estesa ma investigativamente poco utile se non sono disponibili le chiavi necessarie alla decifrazione.

Per questo, nella mobile forensics contemporanea, una FFS correttamente decifrata può risultare più utile di una copia fisica grezza non interpretabile.

Il ruolo decisivo delle applicazioni di terze parti

Le applicazioni di messaggistica, i social network, i servizi di posta, le app di incontri, i sistemi di pagamento e le piattaforme di collaborazione costituiscono oggi una delle principali fonti di evidenza digitale.

WhatsApp, Telegram, Signal, Messenger, Instagram, Snapchat e applicazioni meno diffuse non memorizzano però i dati nello stesso modo. Ciascuna può utilizzare:

• database proprietari;
• differenti schemi SQLite;
• file multimediali separati;
• cache locali;
• token e chiavi conservati in archivi protetti;
• dati presenti soltanto nel cloud;
• cifratura applicativa aggiuntiva;
• meccanismi di sincronizzazione o eliminazione temporizzata.

Su Android, inoltre, i dati delle applicazioni sono normalmente conservati in directory specifiche e isolate. Le evoluzioni dello scoped storage hanno ulteriormente limitato l’accesso alle directory appartenenti ad altre app. Android Developers – Data and file storage, Android 11 storage updates.

Ne consegue che una comune acquisizione logica può recuperare fotografie e file presenti nelle aree condivise, ma non necessariamente il database privato necessario per ricostruire una conversazione.

Questo spiega perché, in alcuni casi, il software possa individuare la presenza di WhatsApp o dei relativi file multimediali senza riuscire a restituire le chat nel report.

Il parser non trova ciò che non è stato programmato per cercare

I software di analisi utilizzano parser: moduli che conoscono, o presumono di conoscere, il formato nel quale una determinata applicazione conserva le informazioni.

Il parser cerca specifici file, tabelle, colonne e relazioni. Se l’applicazione modifica il proprio schema, il software può continuare a cercare i dati nella posizione precedente.

È il fenomeno che Barnhart definisce, efficacemente, una forma di “visione a tunnel”: lo strumento riconosce ciò che è stato programmato per riconoscere, mentre il dato non supportato può rimanere presente ma non interpretato.

La conseguenza metodologica è rilevante:

l’assenza di un’informazione nel report automatico non dimostra necessariamente l’assenza della stessa informazione nell’acquisizione o, più in generale, nel dispositivo.

Prima di formulare una conclusione negativa occorre verificare:

• il tipo di acquisizione eseguita;
• i dati effettivamente acquisiti;
• la versione dell’applicazione;
• la presenza dei database originari;
• eventuali file WAL, journal, cache o archivi precedenti;
• la compatibilità del parser;
• l’esistenza di dati cifrati o non decodificati;
• la necessità di un’analisi manuale.

È qui che l’attività del consulente si distingue dalla semplice produzione di un report.

I dati cancellati non sono sempre recuperabili

Un’altra aspettativa frequente riguarda il recupero dei dati eliminati.

L’idea deriva in parte dalla digital forensics tradizionale applicata a supporti magnetici, nei quali un file cancellato poteva rimanere fisicamente presente fino alla sovrascrittura dei relativi settori.

Sugli smartphone moderni lo scenario è più complesso.

Cifratura, gestione della memoria flash, garbage collection, comandi TRIM, eliminazione delle chiavi e funzionamento interno dei database possono rendere il recupero del contenuto cancellato molto difficile o impossibile.

Ciò non significa che la cancellazione elimini sempre ogni traccia. Possono residuare:

• record non ancora rimossi;
• pagine libere di database;
• file WAL o journal;
• cache;
• miniature;
• allegati multimediali;
• notifiche;
• indici di sistema;
• informazioni quantitative;
• riferimenti presenti in database collegati;
• copie conservate nei backup o nel cloud.

In alcuni casi non viene recuperato il testo di una conversazione, ma rimangono elementi capaci di documentarne l’esistenza, la cronologia, i partecipanti o il volume delle interazioni.

Il professionista può quindi cercare evidenze residue, ma non dovrebbe promettere preventivamente il recupero di un contenuto cancellato.

Perché può essere necessario utilizzare più strumenti

Nella pratica professionale non è raro elaborare la stessa acquisizione con software diversi o utilizzare più metodi sul medesimo dispositivo.

Un prodotto può supportare meglio lo specifico modello; un altro può disporre di un parser più aggiornato per una determinata applicazione; un terzo può consentire una consultazione più efficace dei database o delle relazioni tra gli artefatti.

L’utilizzo di più strumenti non rappresenta necessariamente un’anomalia. Può costituire una forma di verifica incrociata.

Anche il NIST, nelle proprie linee guida sulla mobile device forensics, colloca l’uso degli strumenti all’interno di un processo più ampio di preservazione, acquisizione, esame, analisi, validazione e documentazione. NIST SP 800-101 Rev. 1.

Il software è quindi una componente essenziale del processo, ma non coincide con il processo stesso.

Che cosa dovrebbe attendersi il cliente

Un incarico correttamente impostato non dovrebbe contenere la promessa di “recuperare tutto”, ma l’indicazione delle attività tecniche che verranno eseguite.

Il consulente dovrebbe chiarire:

1. quale dispositivo deve essere esaminato e in quali condizioni si trova;
2. quale dato o periodo temporale sia realmente rilevante;
3. quali metodi di acquisizione risultino tecnicamente disponibili;
4. quali limiti siano prevedibili prima dell’esame;
5. quali verifiche verranno effettuate sui dati acquisiti;
6. come saranno documentate le operazioni;
7. quali risultati non possano essere garantiti anticipatamente.

Il risultato professionale non consiste necessariamente nel ritrovamento del dato sperato. Può consistere anche nell’accertamento documentato che una determinata tipologia di acquisizione non consentiva l’accesso a una specifica area, che il database non era disponibile, che il contenuto risultava cifrato o che il report automatico non era sufficiente per formulare una conclusione.

La differenza è sostanziale: una cosa è non trovare un’informazione; altra cosa è dimostrare, con metodo, dove sia stata cercata, con quali strumenti, attraverso quale acquisizione e con quali limiti.

Conclusioni

La mobile forensics non è una procedura automatica e il software forense non è una scatola magica capace di restituire ogni contenuto presente o cancellato da uno smartphone.

Il risultato dipende dall’interazione tra dispositivo, sistema operativo, patch di sicurezza, stato di blocco, cifratura, applicazioni, metodo di acquisizione, capacità di decodifica e competenze dell’esaminatore.

Le applicazioni di terze parti rappresentano una straordinaria fonte di evidenza, ma anche uno dei settori nei quali l’automazione mostra più chiaramente i propri limiti. I dati possono essere presenti e non acquisiti, acquisiti e non decifrati, decifrati e non interpretati, oppure interpretati in modo incompleto.

Per questo il valore dell’accertamento non risiede soltanto nella licenza utilizzata. Risiede nella capacità del professionista di scegliere il metodo appropriato, comprendere che cosa il software abbia realmente fatto, verificare i dati originari e formulare conclusioni proporzionate alle evidenze disponibili.

In definitiva, non è il software a trasformare un dato in prova. È il metodo con cui quel dato viene acquisito, verificato, interpretato e documentato.

Riferimenti

1. Heather Barnhart, “Leveraging the Third-party App Evidence ‘Goldmine’”, Forensic Magazine, 13 luglio 2026.
   Articolo originale
2. Rick Ayers, Sam Brothers, Wayne Jansen, Guidelines on Mobile Device Forensics, NIST Special Publication 800-101 Rev. 1, National Institute of Standards and Technology, maggio 2014, DOI: 10.6028/NIST.SP.800-101r1.
   Scheda ufficiale NIST
3. Cellebrite, “UFED – Mobile Forensic Data Extraction Tool”. La pagina descrive i differenti metodi di raccolta messi a disposizione dalla piattaforma, comprese le acquisizioni Full File System e fisiche.
   Documentazione Cellebrite UFED
4. MSAB, “XRY Logical – Quick Extractions from Digital Devices”. La documentazione descrive l’acquisizione logica come un processo basato sulla comunicazione con il sistema operativo del dispositivo.
   Documentazione XRY Logical
5. MSAB, “XRY Physical – Physical Extraction XRY Software”. La pagina illustra le funzionalità dichiarate di accesso a basso livello, acquisizione della memoria e trattamento dei dati eliminati sui dispositivi supportati.
   Documentazione XRY Physical
6. Magnet Forensics, “Revealing Hidden Data: Full File System Extractions Uncovered”, 6 giugno 2024. Il contributo propone un confronto sperimentale tra acquisizione logica e Full File System su uno specifico dispositivo di test.
   Approfondimento Magnet Forensics
7. Apple, Apple Platform Security – Data Protection Overview. La documentazione descrive la protezione dei dati mediante chiavi associate ai file e classi di accessibilità.
   Apple Platform Security
8. Android Open Source Project, “File-based Encryption”. La documentazione illustra il sistema di cifratura basato su file adottato dalle versioni moderne di Android.
   Android File-based Encryption
9. Android Developers, “Data and File Storage Overview”. La fonte descrive le aree di archiviazione specifiche delle applicazioni, quelle condivise e le relative limitazioni di accesso.
   Android Data and File Storage
10. Android Developers, “Storage Updates in Android 11”. La documentazione tratta le restrizioni introdotte dallo scoped storage nell’accesso alle directory e alle cache appartenenti ad altre applicazioni.
    Android 11 Storage Updates

✒️ Nota sull’autore

Domenico Moretta, laureato in Diritto della Società Digitale, è criminalista forense e consulente tecnico specializzato in digital forensics, audio forense e trascrizioni giuridiche. Autore di volumi divulgativi e professionali, affianca all’attività peritale un costante percorso di approfondimento nelle discipline giuridiche e nelle tecnologie applicate alla prova digitale.
Con il progetto www.acquisizioneprovedigitali.it promuove una cultura integrata tra scienze forensi, innovazione tecnologica e tutela dei diritti nell’ambiente digitale.

CLICCA QUI PER RICHIEDERE MAGGIORI INFORMAZIONI