[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [home] [volume] [parte]


Capitolo 197.   Recupero dei dati cancellati

Ogni file system utilizza una propria procedura per amministrare i file all'interno dell'unità di memorizzazione. In generale vale il principio che la cancellazione di un file implichi semplicemente la rimozione dei riferimenti ai dati relativi, mentre la cancellazione effettiva dei contenuti avviene soltanto quando dei dati nuovi vanno a occupare la stessa area.

Dalle caratteristiche del file system deriva la semplicità o complessità del recupero di un file cancellato. In generale, un file system utilizzato in un sistema operativo destinato alla massa, viene progettato per facilitare il recupero dei dati cancellati, mentre un file system per ambienti specializzati tende a privilegiare altri aspetti, lasciando inesplorato il problema di tale recupero.

Gli esempi di questo capitolo possono solo dimostrare quanto sia complesso il procedimento di recupero di un file cancellato e dovrebbero scoraggiare questa pratica, privilegiando piuttosto una buona politica di copie di sicurezza.

197.1   Indicazioni di massima

In generale non si può fare affidamento sulla possibilità di recupero dei file cancellati, anche quando si tratta di file system più disponibili nei confronti di questo problema. Pertanto, in generale è necessaria un'organizzazione di copie di sicurezza.

Quando dovesse verificarsi un incidente, a seguito del quale si vuole tentare assolutamente il recupero di un file cancellato, è indispensabile impedire le operazioni di scrittura nel file system considerato; pertanto, il minimo che si possa fare è reinnestare il file system in sola lettura. Tuttavia, di norma si riavvia il sistema con l'ausilio di CD/DVD di emergenza, o dischi esterni, ma in ogni caso occorre disporre di un'unità di memorizzazione ulteriore in cui depositare i file che emergono dal recupero.

197.2   Utilizzo generale di «debugfs»

Il programma debugfs(1) è utile per analizzare ed eventualmente modificare il contenuto di un file system di tipo Ext2 o Ext3:

debugfs [opzioni] [immagine]

Il programma debugfs può essere usato in modo interattivo e in tal caso, di norma, nella riga di comando viene specificato solo il nome del file-immagine o del file di dispositivo contenente il file system da analizzare, come nell'esempio seguente:

debugfs /dev/fd0[Invio]

Richiedendo un funzionamento interattivo, si ottiene un invito, dal quale vanno impartiti i comandi di debugfs. Il comando da ricordare è help, con il quale si ottiene un elenco sintetico delle funzioni disponibili:

debugfs: help[Invio]

Available debugfs requests:

show_debugfs_params, params
Show debugfs parameters
open_filesys, open       Open a filesystem
close_filesys, close     Close the filesystem
feature, features        Set/print superblock features
...

Quando un comando di debugfs produce un listato più lungo dello spazio a disposizione sullo schermo, viene utilizzato automaticamente un programma per il controllo dello scorrimento del testo, come more o less, in base alla configurazione del proprio sistema (precisamente dipende dalla variabile di ambiente PAGER). Ciò significa che in tal caso l'invito cambia e si passa a una fase in cui i comandi vengono interpretati dal tale programma usato per la lettura del risultato. Di norma, è sufficiente il comando q per abbandonare la funzione di scorrimento.

Quando l'invito è quello di debugfs, per concludere il funzionamento interattivo si utilizza il comando quit:

debugfs: quit[Invio]

In generale, durante il funzionamento interattivo di debugfs è possibile indagare sul contenuto del file system, utilizzando comandi simili a quelli di un sistema Unix comune per attraversare la gerarchia di directory. In questa fase conviene prendere appunti sui numeri inode a cui si può essere interessati. Successivamente, per estrapolare dei dati, conviene utilizzare debugfs in modo non interattivo, impartendo i comandi attraverso l'argomento dell'opzione -R:

debugfs [opzioni] -R comando [immagine]

Quando i comandi di debugfs richiedono l'indicazione di un file, si può specificare il nome di questo file, attraverso un percorso che parte dalla radice di quel file system (oppure dalla directory corrente se si sta usando il programma in modo interattivo); diversamente si può indicare il numero inode, ma in tal caso questo va racchiuso tra parentesi angolari: <n>. A titolo di esempio, il comando seguente copia il contenuto del numero inode 123 456, dal file system del file di dispositivo /dev/hda7, nel file /tmp/mio:

debugfs -R "cat <123456>" /dev/fd0 > /tmp/mio[Invio]

197.3   Recupero da un file system Ext2 con «debugfs»

La cancellazione di un file all'interno di un file system Ext2 implica la perdita dell'informazione del nome che questo aveva, mentre il «nodo indice», ovvero l'inode, continua a mantenere il riferimento ai dati originali. In questo modo è possibile risalire alla presenza di un contenuto, cancellato in un certo momento. Per fare una ricerca di questo tipo si utilizza normalmente il programma debugfs. A titolo di esempio viene mostrata un'indagine all'interno di un dischetto:

debugfs /dev/fd0[Invio]

debugfs: ls -l[Invio]

      2   40755 (2)      0      0    1024 17-Jul-2007 12:43 .
      2   40755 (2)      0      0    1024 17-Jul-2007 12:43 ..
     11   40700 (2)      0      0   12288 17-Jul-2007 12:39 lost+found
     12   40755 (2)      0      0    1024 17-Jul-2007 12:44 bin
     13   40755 (2)      0      0    1024 17-Jul-2007 12:40 sbin
     14   40755 (2)      0      0    1024 17-Jul-2007 12:42 usr
     31   40755 (2)      0      0    1024 17-Jul-2007 12:41 lib
     56   41777 (2)      0      0    1024 17-Jul-2007 12:43 tmp

Si vogliono recuperare dei file cancellati nella directory /bin/:

debugfs: cd /bin[Invio]

debugfs: ls -l[Invio]

     12   40755 (2)      0      0    1024 17-Jul-2007 12:44 .
      2   40755 (2)      0      0    1024 17-Jul-2007 12:43 ..
<     0>      0 (1)      0      0       0                   arch
<     0>      0 (1)      0      0       0                   bash
<     0>      0 (1)      0      0       0                   bunzip2
     18  100755 (1)      0      0    2105 21-May-2007 07:43 bzcmp
     18  100755 (1)      0      0    2105 21-May-2007 07:43 bzdiff
     19  100755 (1)      0      0    3642 21-May-2007 07:43 bzegrep
     20  100755 (1)      0      0    4878 21-May-2007 07:43 bzexe

La directory riporta tre file cancellati (arch, bash e bunzip2), pertanto si verifica la presenza di inode riferiti a file cancellati nella directory corrente:

debugfs: lsdel[Invio]

 Inode  Owner  Mode    Size    Blocks   Time deleted
    15      0 100755   3248    4/   4 Tue Jul 17 12:44:29 2007
    16      0 100755 677184  666/ 666 Tue Jul 17 12:44:29 2007
    17      0 100755  25140   26/  26 Tue Jul 17 12:44:29 2007
3 deleted inodes found.

Vengono segnalati tre file cancellati, corrispondenti agli inode 15, 16 e 17. Si prende nota e si chiude il funzionamento interattivo del programma:

debugfs: quit[Invio]

Attraverso comandi non interattivi è possibile copiare il contenuto a cui fanno ancora riferimento gli inode annotati dal file system in cui è stata svolta l'indagine:

debugfs -R "cat <15>" /dev/fd0 > /tmp/inode15[Invio]

debugfs -R "cat <16>" /dev/fd0 > /tmp/inode16[Invio]

debugfs -R "cat <17>" /dev/fd0 > /tmp/inode17[Invio]

Si ottiene così la copia dei dati a cui fanno riferimento gli inode annotati in precedenza, nei file /tmp/inode15, /tmp/inode16 e /tmp/inode17.

197.4   Recupero da un file system Ext2 con i programmi di The Sleuth Kit

Il pacchetto noto come The Sleuth Kit,(2) ovvero TSK, può essere usato per individuare la presenza di file cancellati e per recuperarli, da un file system Ext2, ma attraverso un procedimento meno agevole rispetto a debugfs. Viene mostrato un esempio analogo a quello già apparso nella sezione precedente, con l'uso di programmi del pacchetto The Sleuth Kit, senza entrare nel dettaglio del funzionamento degli stessi.

Per prima cosa viene osservata la struttura di file e directory, dalla quale è possibile individuare la presenza di file cancellati, benché non si possa sapere se i contenuti relativi siano ancora accessibili:

fls -rp /dev/fd0[Invio]

d/d 11: lost+found
d/d 12: bin
r/- * 0:        bin/arch
r/- * 0:        bin/bash
r/- * 0:        bin/bunzip2
r/r 18: bin/bzcmp
r/r 18: bin/bzdiff
...
l/l 48: lib/libbz2.so.1.0
r/r 49: lib/libbz2.so.1.0.3
d/d 56: tmp

L'incolonnamento dei dati che appaiono nel listato non è perfetto, perché le colonne sono separate semplicemente da un carattere di tabulazione orizzontale. A ogni modo si individua la presenza di tre file che sono stati cancellati nella directory /bin/, di cui però non si conosce il numero inode originale. Con il programma ils si cercano tutti gli inode liberi che risultano essere stati usati in precedenza:

ils -Z /dev/fd0[Invio]

class|host|device|start_time
ils|nanohost||1184686862
st_ino|st_alloc|st_uid|st_gid|st_mtime|st_atime|st_ctime|\
  \st_mode|st_nlink|st_size|st_block0|st_block1 15|f|0|0|1172080124|1184661548|1184669069|100755|0|3248|49|50 16|f|0|0|1165872010|1184668800|1184669069|100755|0|677184|53|54 17|f|0|0|1179726247|1184661548|1184669069|100755|0|25140|719|720

Il listato è difficile da interpretare e sarebbe fatto per l'utilizzo attraverso altri programmi. In questo caso sono riportati solo tre inode: 15, 16 e 17. Non riuscendo a fare altre congetture, si estrapola il contenuto di questi tre inode copiandoli in altrettanti file:

icat /dev/fd0 15 > /tmp/inode15[Invio]

icat /dev/fd0 16 > /tmp/inode16[Invio]

icat /dev/fd0 17 > /tmp/inode17[Invio]

197.5   Recupero da un file system Ext2 con «recover»

Il programma Recover(3), il quale a sua volta si avvale di debugfs, viene usato in modo interattivo per tentare di recuperare file cancellati in un file system Ext2:

recover [-a] file_di_dispositivo

Nella riga di comando va indicato espressamente un file di dispositivo, mentre non è possibile indicare semplicemente un file-immagine contenente la copia del file system da elaborare.

L'opzione -a consente di eseguire una scansione automatica per recuperare tutti gli inode recuperabili. Viene mostrato solo un esempio con l'uso di tale opzione. Senza l'opzione -a il programma fa una serie di domande che consentono di circoscrivere la ricerca dei file da recuperare a un insieme ristretto:

recover /dev/fd0[Invio]

Getting inodes (this can take some time)...
debugfs 1.40 (29-Jun-2007)
=> 15 3248 JUL TUE 17 12:44:29 2007
=> 16 677184 JUL TUE 17 12:44:29 2007
=> 17 25140 JUL TUE 17 12:44:29 2007

3 inodes found. Where shall i dump them? (directory):

/tmp/recuperati[Invio]

Please type some text the deleted file should have included \
  \(type: * if you don't know it):

*[Invio]

Please wait...
Dumping inode 15 to /tmp/recuperati
Dumping inode 16 to /tmp/recuperati
Dumping inode 17 to /tmp/recuperati

Do you want to refilter the inodes? [yn]

n[Invio]

Alla fine, in base all'esempio, si trovano dei file nella directory /tmp/recuperati/, con nomi che ricordano semplicemente il numero inode da cui hanno origine.

197.6   Recupero da un file system generico con Foremost

Partendo dal presupposto che, nella maggior parte dei casi, i dati memorizzati in un file system utilizzano blocchi adiacenti, è possibile usare strumenti che scandiscono l'unità di memorizzazione alla ricerca di impronte di riconoscimento nei file. In generale, il programma più citato per questo tipo di scansione è Foremost.(4)

foremost [opzioni]

L'utilizzo più semplice che se ne può fare consiste nell'indicare un file-immagine da scandire e una directory vuota in cui vanno depositate le copie dei file rinvenuti:

foremost -i immagine -o /tmp/recupero[Invio]

In questo esempio, il file-immagine è precisamente immagine e la directory in cui il programma deve copiare i file è /tmp/recupero/.

Nella directory usata per copiare i file rinvenuti, vengono create delle sottodirectory per tipologia di file individuato e un file con il riassunto delle operazioni svolte: audit.txt. La lettura di questo file consente di sapere da quale posizione del file-immagine sono stati estrapolati i file recuperati.

Come accennato, il riconoscimento dei file avviene attraverso delle impronte e il programma dispone già di un discreto numero di impronte incorporate nel codice, mentre è possibile aggiungerne altre nel file di configurazione: /etc/foremost.conf o quanto indicato con l'opzione -c file. Il file di configurazione predefinito, normalmente è vuoto, oppure contiene la spiegazione di come va compilato, attraverso una serie di commenti. A titolo di esempio si può vedere come potrebbe essere definito un tipo di file contenente codice HTML:

...
    htm         n       50000   <html   </html>
...

Il primo campo che appare in queste direttive indica il tipo di file che può essere usato nell'opzione -t tipo e serve per attribuire un'estensione ai file individuati. In pratica, in questo caso, nella directory usata per depositare i file rinvenuti, questi file hanno una propria sottodirectory htm/ e i nomi dei file terminano per .htm. Inoltre, volendo limitare la ricerca ai soli file di questo tipo, andrebbe usata l'opzione -t htm.

Il secondo campo indica se l'impronta debba essere considerata letteralmente o se sia indifferente l'uso di maiuscole e minuscole. In questo caso, la lettera n indica che non fa differenza se l'impronta appare con lettere maiuscole o minuscole; diversamente si userebbe la lettera y.

Il terzo campo indica la dimensione massima in byte del file da estrapolare. In questo caso si tratta di file che al massimo occupano 50 000 byte.

Il quarto campo indica l'impronta iniziale: da quel punto inizia il file. Il quinto campo, facoltativo, indica l'impronta che indica la fine del file.

L'esempio successivo mostra una direttiva del file di configurazione per individuare i file eseguibili in formato ELF. Purtroppo, in questo caso non è possibile indicare un'impronta che permetta di individuare correttamente la fine di tali file. Si osservi che l'impronta è scritta in forma esadecimale:

...
    elf         y       1000000     \x7F\x45\x4C\x46
...

Quando viene riconosciuto un file per il quale è prevista solo l'impronta iniziale di riconoscimento, diventa cruciale la dimensione massima (predefinita o fissata nel file di configurazione). Infatti, il file che viene individuato viene copiato fino alla dimensione massima, non essendoci altro modo di capire dove può terminare, salvo quando ci si trova alla fine dell'unità di memorizzazione. Ma anche se un file ottenuto dalla scansione ne contiene altri, se questi altri file sono individuabili, il loro contenuto viene comunque copiato in altrettanti file separati. In pratica, la somma delle dimensioni dei file copiati può superare di gran lunga la dimensione complessiva dell'unità di memorizzazione originale.

Tabella 197.12. Alcune opzioni per l'uso di Foremost.

Opzione Descrizione
-d
Attiva il riconoscimento dei blocchi indiretti, utile quando si scandisce un file system Unix (tra quelli conosciuti da Foremost).
-w
Si limita a scrivere il file audit.txt nella directory di destinazione, senza copiare effettivamente i file individuati.
-i immagine
Specifica il nome del file-immagine (o del file di dispositivo) da scandire alla ricerca dei file.
-o directory
Specifica la directory di destinazione dei file da estrapolare e del file audit.txt. Se non viene specificata, si intende la directory output/.
-c configurazione
Specifica il file di configurazione da usare. Generalmente, se non viene specificata questa opzione, dovrebbe trattarsi di /etc/foremost.conf.
-t tipo
Se viene usata, questa opzione serve a limitare la ricerca a un certo tipo di file. Il nome che individua il tipo di file può essere trovato nella pagina di manuale foremost(1) e nel file di configurazione.

In generale, per una scansione all'interno di un file system Ext2 o Ext3, è conveniente l'uso dell'opzione -d; pertanto il comando tipo dovrebbe essere:

foremost [-t tipo] [-w] -d -i immagine -o directory[Invio]

È evidente che la scansione di Foremost non tiene conto delle informazioni contenute nel file system, a parte il caso dell'opzione -d, pertanto i file che si ottengono possono essere indifferentemente dati cancellati o dati che hanno una propria identificazione ancora valida.

197.7   Combinare Foremost e The Sleuth Kit

Attraverso il programma dls del pacchetto The Sleuth Kit è possibile estrapolare facilmente, da un file-immagine, l'insieme dei blocchi che risultano essere liberi (non allocati). Il risultato di questa estrazione può essere dato in pasto a Foremost, in modo da cercare qualcosa solo tra i file cancellati:

dls immagine > immagine2[Invio]

foremost -i immagine2 -o /tmp/recupero[Invio]

197.8   Altri programmi affini

197.9   Riferimenti


1) Ext2 filesystem utilities   GNU GPL

2) The Sleuth Kit   IBM Public License <http://www.opensource.org/licenses/ibmpl.php>

3) Recover   GNU GPL

4) Foremost   In parte di dominio pubblico e in parte GNU GPL

5) Autopsy   GNU GPL


Appunti di informatica libera 2008 --- Copyright © 2000-2008 Daniele Giacomini -- <appunti2 (ad) gmail·com>


Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome recupero_dei_dati_cancellati.htm

[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [home]

Valid ISO-HTML!

CSS validator!

Gjlg Metamotore e Web Directory