Torna al sito principale

4. Estremi rimedi

4.1. Struttura di un filesystem qualsiasi
4.2. Salviamo il salvabile

Non è ancora detta l'ultima parola

Disco completamente cancellato. Oppure contenente errori in quantità impensabile. I dati sono ancora là, da qualche parte, ma non possiamo raggiungerli, dato che l'intero filesystem è perso. Qualcosa si può ancora fare.

4.1. Struttura di un filesystem qualsiasi

Indipendentemente dal nome e dalle prestazioni assicurate, un filesystem altro non è che un modo per archiviare dati e ritrovarli in un mare immenso. Tutti hanno strutture di dati che permettono di localizzare un file, tutti hanno una o più strutture che tengono traccia dello spazio occupato e di quello libero.

Queste strutture sono molto critiche, tant'è che vengono spesso scritte in più punti del supporto, oppure esiste un meccanismo per verificarne l'integrità. Se per qualche motivo questa viene a mancare, il sistema operativo si trova nella situazione di non poter più considerare attendibili i dati in esse. Il risultato è che non ha più informazioni per recuperare i dati: non sa dove siano.

Questo è uno dei peggiori disastri che possano capitare, e con i moderni supporti da molti gigabyte diventa una catastrofe.

Molto più semplice è invece l'organizzazione dello spazio dove effettivamente vengono memorizzati i dati. Molto spesso sono scritti in sequenza a partire da un punto del disco e si sviluppano per tutta la lunghezza necessaria in blocchi consecutivi. Questo per garantire efficienza e prestazioni. Tanto è vero che alcuni filesystem per mantenere queste prestazioni richiedono una operazione detta deframmentazione, dove il risultato è appunto di ricondurre i dati memorizzati in sequenze di blocchi consecutivi, per renderne più efficiente la lettura.

Su questo presupposto si basa un software molto semplice chiamato foremost, usatissimo nel campo dell'Informatica Forense. Questo software legge in sequenza il contenuto di un supporto, ignorandone completamente la struttura del filesystem, e riesce a recuperare gran parte dei file in esso contenuti semplicemente esplorandone il contenuto.

Il modo in cui compie questo apparente miracolo è in realtà molto meno magico, una volta che se ne conoscono i dettagli. Ogni tipo di file, sia esso una immagine, un file AVI, un filmato o un documento in formato PDF, contiene al suo interno delle strutture dati che consentono di ottenere informazioni sul file stesso, fra cui ad esempio la lunghezza in byte. Inoltre hanno una parte iniziale che è univoca ed uguale per tutti i file dello stesso tipo. Per esempio tutti i file PDF iniziano con i caratteri %PDF-, seguiti dalla versione della codifica utilizzata. I file AVI hanno nei primi quattro byte i caratteri RIFF, e dal nono al dodicesimo AVI  (l'ultimo è uno spazio).

Partendo da queste considerazioni, chi ha scritto il programma foremost ha assunto che:

  • Ogni file di un determinato tipo ha una sequenza di byte riconoscibili all'inizio

  • Ogni file dotato di struttura logica ha al suo interno scritta da qualche parte la sua lunghezza originale, o questa si può ricavare dalla struttura del file stesso

  • I file sono memorizzati sul supporto in sequenze di blocchi consecutivi, a partire dal primo blocco, contenente i dati che lo rendono riconoscibile

Semplicemente considerando validi questi assunti, foremost può recuperare immagini (nei formati gif, jpg, png e bmp), filmati e brani musicali (nei formati avi, mpg, mov, wmv e wav), documenti di Microsoft Office, file PDF, archivi ZIP e RAR, file HTML e sorgenti in linguaggio C. Inoltre è possibile definire nuovi formati di file secondo un metodo spiegato nella documentazione che accompagna foremost.

Il limite è determinato dal fatto che in realtà non è detto che il file sia memorizzato in blocchi consecutivi, ma potrebbe essere frammentato, ossia diviso in più parti ognuna delle quali scritta in un punto differente del disco. In questo caso, ovviamente, il file recuperato sarà rovinato, parzialmente o totalmente. E' l'unico caso in cui la deframmentazione di un filesystem è realmente utile. Certo che fare la deframmentazione solo per renderne recuperabile il contenuto in caso di disastro è un ragionamento piuttosto singolare. E' decisamente più astuto fare un regolare backup su un differente supporto.

4.2. Salviamo il salvabile

Siamo nel caso B o nel caso C. Il supporto non è accessibile o presenta errori nel filesystem, tanti e tali che directory intere sono sparite nel nulla.

Dopo aver acquisito l'immagine come spiegato prima (Sezione 3.2, «Acquisire l'immagine del disco»), possiamo operare direttamente su di essa, foremost non la modifica in alcun modo. Dobbiamo soltanto essere certi di avere spazio a sufficienza per salvare i file prodotti durante l'elaborazione.

Supponendo che l'immagine sia nel solito file pendrive.img, il comando da impartire è:

# foremost -i pendrive.img -v -t jpg,png
Foremost version 1.5.2 by Jesse Kornblum, Kris Kendall, and Nick Mikus
Audit File

Foremost started at Mon Jan 21 16:25:20 2008
Invocation: foremost -i pendrive.img -v -t jpg,png 
Output directory: /home/mario/output
Configuration file: /etc/foremost.conf
Processing: pendrive.img
|------------------------------------------------------------------
File: pendrive.img
Start: Mon Jan 21 16:25:20 2008
Length: 1003 MB (1052706816 bytes)
 
Num      Name (bs=512)         Size      File Offset     Comment 

0:      00091808.jpg           1 MB        47005696      
1:      00095008.jpg           1 MB        48644096      
2:      00098368.jpg           1 MB        50364416      
3:      00101568.jpg           1 MB        52002816      
...
...  molte altre linee
...
411:    01983840.jpg           2 MB      1015726080      
412:    01989152.jpg           2 MB      1018445824      
413:    01994272.jpg           3 MB      1021067264      
414:    02000640.jpg           2 MB      1024327680      
415:    02006272.jpg           3 MB      1027211264      
**|
Finish: Mon Jan 21 16:26:15 2008

416 FILES EXTRACTED

jpg:= 416
------------------------------------------------------------------

Foremost finished at Mon Jan 21 16:26:15 2008

Vediamo nel dettaglio cosa è successo. Abbiamo lanciato foremost con le opzioni:

  • -i pendrive.img: è il file contenente l'immagine del pen drive così come acquisita.

  • -v: sta per verbose, fornisce molti dettagli durante il processo di recupero.

  • -t jpg,png: specifica che tipo di file vogliamo recuperare. Se mettiamo -t all recupera tutti i tipi che conosce.

Al termine dell'esecuzione ci troveremo una directory dal nome output al cui interno esisterà un file dal nome audit.txt contenente un rapporto sul lavoro svolto, e tante directory quanti sono i tipi di file che è riuscito a recuperare. Nel caso mostrato si ha una sola directory, jpg, dato che ha trovato solo immagini di tipo JPG. I nomi dei file sono persi, come pure la loro organizzazione in directory: i file hanno come nome il numero del blocco in cui iniziano.

Se vogliamo ridurre il numero di file trovati ed aumentare un po' la velocità, possiamo specificare la dimensione del settore fisico del supporto originale, e imporre a foremost di cercare solo a partire dall'inizio del blocco e non tutto il blocco. Il comando diventa:

# foremost -i pendrive.img -q -b 2048 -v -t jpg,png

I parametri aggiunti sono:

  • -q: per quick, rapido, serve appunto per controllare solo l'inizio di ogni blocco fisico, e non l'intero blocco.

  • -b 2048: la lunghezza fisica del blocco, come riportato da fdisk (Sezione 3.2, «Acquisire l'immagine del disco»). Serve solo se si usa in congiunzione con l'opzione precedente.

Eseguendo due volte foremost sulla stessa immagine di pen drive, una volta in modo standard ed una volta in modo rapido, le differenze sono:

  • Modo standard - file trovati 418 - tempo impiegato: 59 secondi

  • Modo rapido - file trovati: 326 - tempo impiegato: 45 secondi

Nel primo caso tra i file trovati vi sono anche le miniature estratte dai dati Exif normalmente inclusi nei file JPG generati dalle fotocamere di ultima generazione, del tutto inutili o quasi.

Per aumentare ancora di più la rapidità in entrambi i modi, se abbiamo disponibile sufficiente memoria RAM, possiamo includere il parametro -k seguito dal numero di megabyte di memoria che foremost può impiegare per il suo lavoro.

Al termine avremo un numero di file da esaminare e identificare proporzionale alla dimensione del supporto che abbiamo esaminato. Basti pensare ad un pen drive da 16 gigabyte per rendersi conto che il numero di foto che può contenere è immenso, potrebbe superare le 10.000. Provate ad immaginare il tempo che occorre per aprirle, identificarle e catalogarle. Settimane?

Torna al sito principale