Che cosa contiene davvero un’estrazione completa del file system, e perché la maggior parte non viene mai esaminata

Chieda a qualcuno fuori dal campo che cosa c’è su un telefono sequestrato e dirà messaggi, foto e contatti. Lo chieda a un analista e farà una pausa, perché la risposta onesta è che nessuno lo sa del tutto, e scoprirlo è il lavoro.

Un’estrazione completa del file system è una copia del file system del dispositivo come lo vede il sistema operativo. Non un’esportazione curata, non il sottoinsieme che un’applicazione accetta di consegnare attraverso un’interfaccia di backup. L’intero albero.

Vale la pena percorrere che cosa c’è davvero lì dentro, perché la forma dei dati spiega quasi tutto su dove va il tempo di esame.

Quattro strati, in ordine decrescente di attenzione

Lo strato a cui tutti pensano. Messaggi, registri delle chiamate, contatti, il rullino. È davvero importante, è ciò su cui di solito si regge il caso, ed è una piccola frazione dell’estrazione, in volume. È anche la parte che ogni strumento decodifica bene, perché è la parte per cui ogni strumento è stato costruito per prima.

Memorizzazione delle applicazioni. Ogni applicazione installata tiene il proprio stato: database di messaggi e dei loro metadati, cache di foto del profilo, bozze, cronologia delle notifiche, cronologia di ricerca, tracce di posizione, stato di sincronizzazione. Un telefono con sessanta applicazioni ne ha sessanta, in sessanta disposizioni, in diversi formati, alcuni con versione e altri no.

Questo strato è dove le prove interessanti stanno sempre di più, ed è dove la copertura è più diseguale. Lo strumento di un analista decodificherà la memorizzazione delle applicazioni che il fornitore ha implementato, e il resto è un elenco di directory.

Tracce di sistema. Il sistema operativo registra una quantità notevole su se stesso nel corso ordinario del lavoro: quali applicazioni sono state eseguite e quando, a quali reti il dispositivo si è unito, quando è stato acceso, quali account sono configurati, che cosa è stato aperto di recente. Nulla di tutto questo è stato progettato come prova. Molto è una prova molto buona, perché è difficile da curare e corrobora o contraddice il racconto della persona.

Sedimento. Cache delle miniature, file temporanei, write-ahead log che contengono ancora righe cancellate dal database principale, spazio non allocato con i resti di record che sono stati rimossi. È lo strato in cui si recupera il contenuto cancellato, ed è anche quello in cui l’analista deve essere più attento, perché una riga recuperata e una riga viva hanno un peso probatorio diverso e non devono mai essere presentate come se fossero la stessa cosa.

Il problema del volume non è davvero un problema di volume

Un telefono di punta moderno produrrà un’estrazione nelle decine o nelle basse centinaia di gigabyte. Ma la memorizzazione costa poco e la lettura è rapida, quindi la dimensione grezza non è il vincolo.

Il vincolo è che il contenuto utile è sparso su un gran numero di formati, la maggior parte dei quali non è documentata, diversi dei quali cambiano tra le versioni dell’applicazione che li ha scritti, e nessuno dei quali è stato progettato perché lo leggesse qualcuno che non sia l’applicazione stessa.

È per questo che la domanda che conta non è quanto è grande un’estrazione. È su quale quota di essa uno strumento qualsiasi abbia un’opinione. Tutto il resto è presente, leggibile in linea di principio e inutilizzabile in pratica.

Dove vanno le ore

Si osservi un analista esperto mentre percorre un’estrazione: la distribuzione del tempo non è quella che si aspetta chi è fuori dal campo.

Pochissimo è leggere messaggi. Moltissimo è capire quali parti dell’estrazione valga la pena leggere, e poi portare quelle parti in uno stato in cui leggerle sia possibile. Aprire un database sconosciuto, capire che cosa significano le sue tabelle, scoprire che le date e ore sono memorizzate in un’epoca insolita, rendersi conto che il corpo del messaggio è in una tabella e il partecipante in un’altra, senza un join evidente. È questo il lavoro.

È anche lavoro qualificato che non produce nulla di durevole. La comprensione che un analista costruisce, un martedì, sulla disposizione di memorizzazione di un’applicazione vive nella sua testa o, nel migliore dei casi, in un file di note personali, e deve essere ricostruita dalla persona successiva che incontra la stessa applicazione in un altro servizio, sei mesi dopo.

La parte che non viene mai esaminata

Ogni laboratorio ha una regola informale su fino a dove arrivare. Di rado è scritta, e di solito è sensata: si esamina ciò che lo strumento ha decodificato, si esamina tutto ciò che l’investigatore ha chiesto in modo specifico e si annota il resto come non analizzato.

Il risultato è una riduzione del perimetro coerente e invisibile. Non è un difetto di diligenza, e non è qualcosa che una revisione del caso segnalerebbe, perché il rapporto descrive con accuratezza ciò che è stato esaminato. Ma l’effetto, su un carico di casi, è che una grande frazione dei dati sequestrati non viene guardata da nessuno, e la frazione è più grande proprio nelle applicazioni che un fornitore ha trovato commercialmente poco interessanti.

Che cosa cambierebbe il quadro

Tre cose lo sposterebbero, in ordine di quanta differenza fanno.

La prima è una copertura che non dipende dal calendario di versioni di qualcun altro. Se un’applicazione sconosciuta si può strutturare il giorno in cui il caso ne ha bisogno, la regola informale di perimetro smette di togliere ogni volta le stesse categorie di prove.

La seconda è una ricerca che funziona sul significato e non solo sulle stringhe. La maggior parte di un’estrazione è illeggibile perché nessuno ha un motivo per aprirla. Una domanda posta sull’intero sigillo in una volta trova il motivo.

La terza è una verifica abbastanza economica da essere davvero eseguita. Un analista che deve passare un pomeriggio a confermare da dove viene un accertamento ne confermerà di meno. Uno che può farlo in un clic li confermerà tutti, che è ciò che un’aula ha titolo di aspettarsi.

Quest’ultima conta più di quanto sembri. Rendere più rapida la revisione delle prove è utile solo se non la rende anche più superficiale, e la sola difesa contro questo è rendere il controllo così economico che saltarlo non fa risparmiare nulla.