Il recupero dati dai file system di Linux

Il recupero dati dai file
system di Linux
Bartosz Przybylski
Artykuł opublikowany w numerze 3/2005 magazynu hakin9. Zapraszamy do lektury całego magazynu.
Wszystkie prawa zastrzeżone. Bezpłatne kopiowanie i rozpowszechnianie artykułu dozwolone
pod warunkiem zachowania jego obecnej formy i treści.
Magazyn hakin9, Software-Wydawnictwo, ul. Piaskowa 3, 01-067 Warszawa, [email protected]
Il recupero dati dai file
system di Linux
Bartosz Przybylski
Quando, per esempio in seguito
ad un attacco al sistema, ci
capiterà di perdere in Linux
file importanti, non dovremo
disperare. Esistono molti metodi
per recuperare i dati. Anche se
spesso è un lavoro impegnativo,
un buon assortimento di
strumenti ci permetterà di
recuperare anche contenuto
completo di un file system
danneggiato.
I
l nostro server è stato vittima di pirata informatico. L'intruso è stato così malvagio
da cancellare dal nostro disco parecchi file
importanti, tra questi il programma sul quale
abbiamo lavorato un paio di mesi. Prima di fare
una reinstallazione del sistema (per assicurarci
che non rimanga in esso nessun codice maligno lasciato dall’intruso) bisogna cercare di
recuperare i dati. Per farlo, dobbiamo servirci di
alcuni strumenti che ogni distribuzione di Linux
contiene.
Difesa
Strumenti utili
60
Il primo elemento indispensabile è un insieme
di strumenti per poter operare sui file system
ext2 e ext3 – si tratta del pacchetto e2fsprogs.
Per noi il più importante sarà debugfs che,
come indica il nome, serve per fare il debug
dei file system. Di default (per la piattaforma
x86) tutto il pacchetto viene installato insieme
al sistema.
Il successivo strumento indispensabile
è reiserfsck che fa parte del pacchetto reiserfsprogs e che serve per editare il file system ReiserFS. Anche questo pacchetto dovrebbe essere allegato al sistema. Invece il programma
dd ci servirà per recuperare tutta la partizione
www.hakin9.org
con il file system ReiserFS e come alternativa
per recuperare dati dai vari tipi dei file system.
La preparazione di una
partizione per recuperare dati
Indipendentemente dal file system dal quale
recupereremo i dati, la prima operazione da
eseguire sarà quella di smontare la partizione
sulla quale lavoreremo. Per avere almeno una
parziale certezza che i nostri dati non sono stati
in alcun modo danneggiati, dovremo fare questo
passo al più presto dopo l'eliminazione dei file.
Dall'articolo imparerai...
•
•
come recuperare dati dai file system di tipo ext2
e ext3,
in che modo salvare file dalla partizione ReiserFS.
Cosa dovresti sapere...
•
•
dovresti saperti servire della linea di comando in
Linux,
dovresti conoscere le basi della struttura dei file
system.
hakin9 N o 3/2005
Il recupero dei dati
I termini legati alla gestione dello spazio su disco
Gli inode
L'inode è una struttura di dati utilizzata nei file system di Linux per descrivere un file.
Di essa fanno parte:
•
•
•
il tipo di file – file ordinario, directory o file di dispositivo,
l'identificativo UID di un proprietario,
la lista dei blocchi del disco e i loro frammenti che compongono un file.
Possiamo considerare l'inode come un particolare identificatore di un file su disco, di
cui il sistema si serve per trovare un file richiesto. Ogni file su una data partizione ha
un solo inode subordinato.
Il blocco del disco
Il blocco del disco è una parte di spazio su una partizione, che conserva informazioni.
La dimensione di un blocco è definita da un utente durante la divisione del disco in
partizioni. Può però essere cambiata usando i programmi per la modifica di un dato file
system. Contrariamente agli inode, molti blocchi possono appartenere ad un solo file.
Il journaling
Il journaling (ingl. journaling, registrazione dei cambiamenti) è uno dei metodi per conservare dati su disco. Il principio è semplice ma particolarmente efficace. Lo schema
di funzionamento, un po' semplificato, è visibile nella Fig. 1.
Come si vede, File1 dopo la modifica non cambierà i dati compresi nella sua vecchia posizione (contrariamente ai file system senza il journaling), ma i dati saranno
registrati in una nuova posizione. Questa è una grande cosa, infatti quando giungeremo alla conclusione che la versione precedente era migliore, anche dopo notevoli
modifiche, saremo in grado di recuperare la forma originale di un file.
Per smontare una partizione
basta umount /dev/hdaX (dove X
è il numero della partizione dalla
quale sono stati cancellati i dati, nel
nostro caso essa avrà il valore 10).
Se però durante quest'operazione
otterremo il messaggio:
di ottenere in output dati più dettagliati, con ciò, invece dei soli numeri
PID, vedremo anche gli argomenti
null dei programmi. Se constateremo
che i processi ci sono inutili, basterà
eliminarli con il comando:
# fuser -k -v -m /dev/hda10
# umount /dev/hda10
umount: /tmp: device is busy
questo significa che qualche processo utilizza questa partizione.
Ci sono due le vie d'uscita da
una tale situazione. Una di queste
è uccidere il processo che utilizza
una data partizione. Prima però
bisogna controllare quali processi
bloccano la partizione. Utilizzeremo
il programma fuser, che serve per
identificare utenti e processi che
adoperano determinati file o socket:
# fuser -v -m
Se invece preferiamo terminare
i processi normalmente, dovremo
eseguire:
# fuser -TERM -v -m /dev/hda10
Un modo alternativo per smontare
un file system è quello di metterlo
in modalità RO (read only). In questo modo i nostri file non potranno
essere sovrascritti. Per eseguire
quest'azione, dovremo impartire
il seguente comando:
# mount -o ro, remount /dev/hda10
Attenzione: il comando non funzionerà, se la partizione è la root directory,
ossia il file system principale. Se in
effetti è così, dovremo informare di
questo il programma mount, affinché
non registri i cambiamenti nel file
/etc/mtab. A questo scopo aggiungiamo il parametro -n.
Il recupero dati in
Ext2fs
Il primo tipo di file system del quale
ci occuperemo è ext2fs (per saperne
di più su questo e su altri file system,
conviene dare un'occhiata al Riquadro I file system di Linux). Cominciamo trovando gli inode cancellati.
La ricerca degli inode
cancellati
Per fare questo passo utilizzeremo
il programma debugfs dal pacchetto
e2fsprogs. Avviamo l'applicazione
aprendo la partizione richiesta:
# debugfs /dev/hda10
Quando apparirà un messaggio di
prompt, dovremo eseguire il comando lsdel, che ci farà vedere tutti
i file cancellati dal momento della
creazione di questa partizione (nel
caso di sistemi pubblici questa lista
può avere migliaia di righe e la sua
compilazione esige a volte un po' di
tempo). Adesso – esclusivamente in
base alla data della cancellazione,
/dev/hda10
L'opzione -m /dev/hda10 imporrà al
programma di verificare quali servizi
utilizzano la partizione hda10. Invece
l'opzione -v (verbose) ci permetterà
hakin9 N o 3/2005
Fig. 1: Lo schema di funzionamento del journaling
www.hakin9.org
61
Listing 1. L'effetto del comando lsdel del programma debugfs
debugfs: lsdel
Inode Owner Mode
Size
(...)
20 0
100644 41370
24 0
100644 17104
352 deleted inodes found.
debugfs:
Blocks
Time deleted
14/14
5/5
Tue Feb 15 19:13:25 2005
Tue Feb 15 19:13:26 2005
Listing 2. Il riversamento dei dati recuperati su di un file
debugfs: dump <24> /home/aqu3l/recovered.000
debugfs: quit
# cat /home/aqu3l/recovered.000
(...)
all'UID dell'utente e alla dimensione
– possiamo dedurre quali file appartenevano a noi e quali vogliamo recuperare. Una buona idea è scrivere
o stampare i numeri degli inode.
Guardiamo da vicino l'esito del
comando lsdel (vedere Listing 1).
Le colonne nei risultati del comando
lsdel si presentano in questo ordine:
•
•
•
•
•
•
il numero dell'inode (inode),
il proprietario (owner),
le opzioni d'accesso (mode),
la dimensione in byte (size),
il numero di blocchi occupati
(blocks),
il tempo di cancellazione (time
deleted).
Come si vede, i file cancellati hanno
i numeri degli inode pari a 20 e 24.
Cercheremo di recuperare proprio
questi dati.
Difesa
Il recupero dei dati
62
Adesso possiamo provare a recuperare l'inode 24 tramite il riversamento
(ingl. dump) dei dati su un altro file.
Come si vede nel Listing 1, occupa
5 blocchi. È un'informazione abbastanza importante – questo metodo
non sempre può essere efficace con
file che occupano più di 12 blocchi.
L'esempio di tale recupero si trova
nel Listing 2.
Tra le parentesi angolari indichiamo il nome del file o il numero
dell'inode. Il secondo parametro
è il nome del file di destinazione
– bisogna indicarlo con il percorso
d'accesso completo, quindi l'abbreviazione ~/ non avrà effetto.
Una volta eseguito il comando
digitiamo quit ed andiamo a leggere
il contenuto del file recuperato.
Spesso alla fine del file recuperato
possono apparire diversi caratteri-
spazzatura; sono i resti di altri file sovrascritti. Si possono eliminare con
l'uso di un qualsiasi editor di testo.
Questo metodo è ovviamente efficace soltanto nel caso di file di testo.
C'è rimasto da recuperare un
file dall'inode 20 (vedere Listing 1).
Occupa 14 blocchi e, come abbiamo
menzionato, il metodo del trasferimento dei dati da un inode che conta
più di 12 blocchi non termina con
successo (vedere Riquadro I blocchi
e la loro gerarchia in ext2fs). Perciò
per recuperare il 20º inode useremo
il programma dd.
Prima di recuperare il file verifichiamo i dati principali, cioè i numeri
dei blocchi e la dimensione del blocco sulla partizione. Per verificare
la dimensione del blocco utilizzeremo
il comando:
# dumpe2fs /dev/hda10 \
| grep "Block size"
I file system di Linux
Ext2fs
Il file system, il cui principale creatore è Theodore Ts'o. Non ha il journaling. È stato
progettato in modo tale che sia possibile recuperare dati da una partizione. È uno dei
più popolari (proprio a causa della facilità di recupero) file system di UNIX.
Ext3fs
In teoria è la versione successiva di ext2. Nonostante non sia stato progettato così
bene come il suo predecessore, offre la possibilità del journaling. Uno dei principali
difetti è che gli sviluppatori non vi hanno previsto in ext3 la possibilità di recuperare un
file cancellato. Questo succede perché il sistema dopo aver segnato il file come cancellato ne libera anche l'inode relativo, in questo modo rendendo impossibile leggere
gli inode eliminati.
ReiserFS
Il file system creato dalla NameSys, più precisamente da Hans Reiser (da qui il nome).
Fornisce anche il journaling; è stato sviluppato in base all'algoritmo dell'albero bilanciato (ingl. balanced tree). Maggiori informazioni sulla struttura specifica di reiserfs si
trovano sul sito Web degli sviluppatori (vedere Riquadro In Rete).
Jfs
Jfs (IBM's Journaled File System for Linux) è il file system scritto dalla IBM per la
piattaforma Linux. Ha lo scopo di rendere più efficiente la comunicazione con i prodotti
IBM. È basato su un principio del journaling, similmente al resto dei sistemi che lo adoperano. Questo significa che i nuovi dati memorizzati vengono posti all'inizio del disco,
invece le informazioni nel blocco principale, vengono aggiornate.
Xfs
Extended filesystem è stato progettato per i computer che hanno la necessità
di conservare un grande numero di file in una sola directory e che devono averne un accesso immediato. Progettato principalmente per Irix, ha trovato anche
impiego nei supercomputer funzionanti con il sistema GNU/Linux. Una curiosità
è il fatto che il sistema è capace di mantenere in una sola directory persino 32
milioni di file.
www.hakin9.org
hakin9 N o 3/2005
Il recupero dei dati
I blocchi e la loro gerarchia in ext2fs
I blocchi sul disco non sono una sola sequenza attribuita ad un file (inode). In certe
parti (dipendenti dal file system, non dall'utente) sono presenti i cosidetti blocchi indiretti, di tre tipi:
•
•
•
il blocco indiretto (ingl. indirect block) – IND,
il blocco doppiamente indiretto (ingl. double indirect block) – DIND,
il blocco triplamente indiretto (ingl. triple indirect block) – TIND.
Ogni blocco successivamente numerato dipende dal precedente, però anche ogni successivo può conservare un maggiore numero di blocchi:
•
•
•
•
i numeri dei primi 12 blocchi sono conservati direttamente in un inode (proprio essi
sono spesso chiamati blocchi indiretti),
un inode contiene il numero di un blocco indiretto; il blocco indiretto contiene i
numeri dei successivi 256 blocchi con dati,
un inode contiene il numero di un blocco doppiamente indiretto. Il blocco doppiamente indiretto contiene i numeri dei 256 blocchi indiretti supplementari,
un inode contiene il numero di un blocco triplamente indiretto; il blocco triplamente
indiretto contiene i numeri dei 256 blocchi doppiamente indiretti supplementari.
La struttura è presentata nella Fig. 2.
da recuperare. Quest'operazione,
la vediamo nel Listing 3 – prestiamo attenzione al fatto che il blocco
22027 è un blocco indiretto (IND).
Ci interessa la penultima riga,
proprio in essa sono indicati i blocchi che appartengono al dato inode.
Utilizziamo il programma dd per recuperare i blocchi da 0 (bisogna cominciare sempre da questo numero
a contare i blocchi) a 11:
# dd bs=4k if=/dev/hda10 \
skip=22015 count=12 \
> ~/recovered.001
# dd bs=4k if=/dev/hda10 \
skip=22028 count=1 \
>> ~/recovered.001
Alcune spiegazioni:
•
Listing 3. La verifica dei blocchi da recuperare
# debugfs /dev/hda10
debugfs: stat <20>
Inode: 20
Type: regular
Mode: 0644
Flags: 0x0
User: 0
Group: 0
Size: 41370
(...)
BLOCKS:
(0-11):22015-22026, (IND): 22027, (12):22028
TOTAL: 14
•
Generation: 14863
Listing 4. Il recupero dei file tramite la modifica diretta di un inode
# debugfs -w /dev/hda10
debugfs: mi <24>
Mode
[0100644]
User ID
[0]
Group ID
[0]
(...)
Deletion time [1108684119]
Link count
[0] 1
0
debugfs: quit
# e2fsck -f /dev/hda10
e2fsck 1.35 (28-Feb-2004)
(...)
Unattached inode 14
Connect to /lost+found<y>? yes
(...)
dumpe2fs 1.35 (28-Feb-2004)
Block size:
4096
hakin9 N o 3/2005
•
Il blocco 22027 è doppiamente indiretto, ecco perché l'abbiamo omesso
ed abbiamo subito aggregato il blocco 22028.
La modifica degli inode
(...)
In risposta dovremmo ottenere:
•
indica la dimensione del blocco (fornito in kilobyte), che avevamo prima,
if indica il file di input (ingl. input
file),
skip impone al programma di
saltare 22015 blocchi della dimensione bs data,
count indica il numero dei blocchi
da aggregare.
bs
Proprio quest'ultimo numero (4096)
è la dimensione del blocco. Adesso,
quando abbiamo già la dimensione
del blocco, verifichiamo i blocchi
www.hakin9.org
Adesso ci occuperemo di un altro modo per recuperare dati – della modifica
diretta degli inode. Essa consiste nel
cambiamento di un inode, in modo
tale che il file system tratti rispettivi
dati come mai cancellati, e in occasione della prossima verifica del disco
sposti il file cancellato nella cartella
lost+found su una data partizione.
Anche per la modifica utilizzeremo
il programma debugfs. L'intera procedura è riportata nel Listing 4.
Come si vede, sono state modificate soltanto due stringhe: il tempo
di cancellazione (deletion time – non
è però del tutto vero, perché il sistema non è in grado di determinare
la data di cancellazione di un file)
e il numero dei collegamenti al file
63
(link count). Adesso, dopo avere
terminato il lavoro da debugfs, basta
eseguire il comando:
# e2fsck -f /dev/hda10
Il programma, dopo aver incontrato
l'inode modificato, riconoscerà che
esso non ha nessun allegato (ingl.
unattached) e chiederà se i dati descritti in questo inode sono da allegare alla cartella lost+found. Se ci
teniamo al file ovviamente premiamo
il tasto y. Però non c'è rosa senza
spine – avendo dato un'occhiata nella
cartella non vedremo i nomi eleganti
dei file, ma esclusivamente i nomi degli inode ricostruiti (p.es. 24). Bisogna
allora esplorare il file e dal contenuto
riconoscere il suo nome originale.
Ext3fs
Il recupero dati in questo file system
è specifico, a volte persino molto
impegnativo (vedi anche Riquadro
I file system di Linux). In verità non
c'è nessun modo di recupero consolidato per questo tipo di partizione.
Esistono però metodi non ufficiali per
salvare dati.
È ext3 o ext2?
Figura 2. La struttura dei blocchi nel file system ext2
Listing 5. La ricerca degli inode cancellati in ext3fs
Difesa
# debugfs /dev/hda10
debugfs: lsdel
Inode
Owner
0 deleted inodes found.
debugfs: q
Mode
Size
Blocks
Time deleted
Listing 6. Il recupero dati dalla partizione ext3 montata come ext2
debugfs: lsdel
Inode Owner Mode
Size Blocks
(...)
20 0
100644 41370 14/14
(...)
24 0
100644 17104 5/5
352 deleted inodes found.
debugfs:
Ext3 e ext2 sono file system molto
simili (ad eccezione del journaling e del modo di cancellare file)
– utilizziamo allora questo fatto per
recuperare i nostri dati. Cercheremo
di usare debugfs; questo processo
è stato presentato nel Listing 5.
Guardiamo il Listing 5. I nostri
inode sono stati cancellati dal file
system. La via che abbiamo scelto
sembra non condurre in nessun
luogo.
Possiamo però provare un trucco
– fare in modo che il sistema tratti
il file system come ext2. Questa soluzione si suddivide in tre tappe:
Time deleted
•
•
Tue Feb 14 19:20:25 2005
•
Tue Feb 15 19:13:26 2005
smontare il file system,
montarlo nuovamente, però questa volta come ext2,
recuperare i file.
Smontiamo allora la partizione:
# umount /dev/hda10
64
www.hakin9.org
hakin9 N o 3/2005
Il recupero dei dati
In seguito dobbiamo montarla di nuovo come ext2, per maggior sicurezza
in modalità read only:
# mount -o ro -t ext2 \
/dev/hda10 /tmp
Adesso cerchiamo di lavorare con debugfs nel modo, che abbiamo presentato parlando del sistema ext2. Come
trovare gli inode cancellati dalla partizione ext3 è illustrato nel Listing 6.
L'inode 20 ha una falsa data di
cancellazione. Succede così perché
dopo la liberazione dell'inode da
ext3, il sistema ext2 può avere dei
problemi sulla lettura di dati corretti
sui file.
Dopo un'attenta analisi dell'intera lista dei file eliminati possiamo
iniziare ad occuparci del recupero
dei file di cui abbiamo bisogno.
Il metodo è lo stesso come nel caso
di ext2, però con ext3 si può incontrare qualche problema dopo la modifica diretta dell'inode. In alcuni casi
può persino causare l'illeggibilità dell'intera partizione per il sistema.
Il lavoro duro rende
Il secondo metodo per recuperare
dei file da ext2 è molto più difficile,
però rende possibile recuperare
un numero molto più grande di file
di testo cancellati. Anche questo
metodo, purtroppo, ha un serio
difetto – richiede l'esplorazione manuale del contenuto dei dischi, allora
il salvataggio dei file binari è molto
difficile.
Una buona idea è quella di fare
prima una copia di backup dell'intero
disco. Facciamolo con il comando:
$ dd if=/dev/hda10 \
>~/hda10.backup.img
Listing 7. dsksplitter.pl – un semplice script per dividere dischi
#!/usr/bin/perl
if ($ARGV[3] eq "") {
print "Usage:\ndsksplitter.pl <dsk_parts> <part_size in Kb>
<partition_to_split> <target_dir>";
}
else {
$parts = $ARGV[0];
$size = $ARGV[1];
$partition = $ARGV[2];
$tardir = $ARGV[3];
for ($i = 1; $i <= $parts; $i++) {
system "dd bs=1k if=$partition of=$tardir/dks.$i
count=$size skip=$ix$size";
}
}
Per facilitarci un po' il lavoro, possiamo suddividere la nostra partizione
in parti più piccole. Se la partizione
ha la capacità di 1 GB, sarà prudente dividerla in 10 parti da 100 MB.
Un semplice script destinato a questo scopo è stato presentato nel
Listing 7 – il disco lo possiamo suddividere con il comando:
biare la sequenza int main in una
qualsiasi. Ecco i risultati ottenuti:
$ dsksplitter.pl 10 1000000 \
Ext3 registra i nuovi file all'inizio del
disco, possiamo allora supporre che
la linea da noi trovata è proprio quella che cerchiamo. Proviamo, allora,
ancora una volta, a dividere il file
in parti più piccole e lì cercare i dati:
/dev/hda10 ~/dsk.split
Utilizziamo ora il comando di sistema
grep per trovare le sequenze di caratteri che ci interessano (per questa
attività possiamo ovviamente usare
il comando strings):
•
•
"int main" ~/dsk.split/*
Il parametro -n ci indicherà il numero
della linea del file in cui si trova la
sequenza. Il parametro -a impone di
trattare i file binari come i file di testo, invece -1 visualizzerà una linea
prima ed una linea dopo la sequenza
trovata. Ovviamente possiamo cam-
int main (int argc, char *argv[])
~/dsk.split/dsk.1:40212:§
{ (...)
$ mkdir ~/dsk1.split
~/dsk.split/dsk.1 ~/dsk1.split
Eseguiamo adesso il comando grep
sul file dsk.1 diviso:
$ grep -n -a -1 \
"int main" ~/dsk1.split/*
Otterremo:
~/dsk1.split/dsk.3:143:§
#include <sys/socket.h>
~/dsk1.split/dsk.3:144:§
http://e2fsprogs.sourceforge.net – la pagina del pacchetto e2fsprogs,
http://web.mit.edu/tytso/www/linux/ext2fs.html – la homepage di ext2fs,
http://www.namesys.com – la homepage degli sviluppatori di ReiserFS,
http://oss.software.ibm.com/developerworks/opensource/jfs – il sito del file system jfs,
http://oss.sgi.com/projects/xfs – la pagina del progetto xfs,
http://www.securiteam.com/tools/6R00T0K06S.html – il pacchetto unrm.
hakin9 N o 3/2005
#include <sys/socket.h>
~/dsk.split/dsk.1:40211:§
$ dsksplitter.pl 10 10000 \
$ grep -n -a -1 \
In Rete
•
•
•
•
~/dsk.split/dsk.1:40210:§
www.hakin9.org
int main (int argc, char *argv[])
~/dsk1.split/dsk.3:145:§
{ (...)
Adesso abbiamo il file con il programma cancellato dall'intruso.
In verità il file, in cui l'abbiamo trovato è di 10 MB, però, ad ogni modo,
65
è una prospettiva molto migliore
che dover esplorare 1 GB di dati.
Se però questa precisione non ci
soddisfa, possiamo tentare di dividere il file di frammento di disco
esaminato in parti ancora più piccole. Se la dimensione del file verrà
diminuita abbastanza, non ci rimane
che avviare un editor di testo ed occuparci della penosa eliminazione
delle righe superflue.
Questa tecnica è impegnativa,
però efficace. È stata sottoposta ad
un test con alcune distribuzioni di
Linux, però non possiamo garantire
che il metodo funzionerà su tutti
i sistemi Linux.
Il recupero in ReiserFS
Per recuperare i file ci serviremo
dei programmi standard di Linux.
Cominciamo da dd – lo useremo per
creare l'immagine della partizione.
È indispensabile, perché le azioni
che eseguiremo potrebbero causare
dei danni irreversibili. Eseguiamo
allora il comando:
$ dd bs=4k if=/dev/hda10 \
conv=noerror \
> ~/recovery/hda10.img
dove /dev/hda10 è la partizione da
recuperare, e bs (block size) lo abbiamo determinato con il comando:
$ echo "Yes" | reiserfstune \
Difesa
-f /dev/hda10 | grep "Blocksize"
Il parametro conv=noerror causerà
la conversione al file senza trasmettere errori, vuol dire che, anche se
il programma incontrerà errori sul
disco, continuerà a convertire dati al
file. Dopo aver immesso il comando
saremo costretti ad aspettare un determinato lasso di tempo, dipendente
dalla dimensione della partizione.
Adesso bisogna spostare il contenuto della nostra immagine della
partizione sul dispositivo di loopback
loop0, assicurandoci prima che sia
libero:
# losetup -d /dev/loop0
# losetup /dev/loop0 \
/home/aqu3l/recovery/hda10.img
66
In seguito bisogna ricostruire l'albero
– l'intera partizione verrà verificata,
invece qualsiasi resto dopo gli inode
verrà aggiustato e ripristinato. Per
fare ciò useremo il comando:
# reiserfsck –rebuild-tree -S \
-l /home/aqu3l/recovery/log /dev/loop0
Il parametro supplementare -S farà
sì che venga verificato l'intero disco,
e non soltanto la sua parte occupata. Il parametro -l con il parametro
/home/user/recovery/log registra un
file di log nella directory indicata.
Adesso creiamo la directory per
la nostra partizione e la montiamo:
# mkdir /mnt/recover; \
mount /dev/loop0 /mnt/recover
I file recuperati si possono trovare
in uno dei seguenti tre luoghi. Il primo è la directory originale del file
(trattiamo /mnt/recover/ come root
directory). Il secondo è la directory
lost+found nella nostra directory
temporale principale (/mnt/recover).
Il terzo è semplicemente la directory
principale della partizione.
Il file cercato quasi per certo si
troverà in una di tre luoghi elencati.
Se non lo troviamo lì, due possono
essere le spiegazioni: o era il primo
file sulla partizione ed è stato sovrascritto, oppure è stato erroneamente
spostato in un'altra directory. Nel primo caso dovremo rinunciare ai nostri
dati, invece nel secondo possiamo
trovarlo in un altro luogo, utilizzando
lo strumento find:
$ find /mnt/recover \
-name nostri_dati
Il recupero di un file
recentemente modificato
Concentriamoci adesso sul recupero
di un solo file, recentemente modificato. Questo metodo si può adattare
anche per i file più vecchi, però tale recupero dovrà essere basato su faticosi
calcoli uniti ad un'ottima conoscenza
del proprio file system e non ultimo
– ad una buona dose di fortuna.
Come si vede nella Fig. 1, nei
file system con journaling i nuovi file
www.hakin9.org
vengono registrati all'inizio stesso
del disco. In teoria il nostro file si
trova subito dietro al cosiddetto blocco principale (ingl. root block), ossia
il blocco del disco che determina
il luogo da dove cominciano i dati.
Per localizzare il nostro root block
bisogna eseguire il comando:
# debugreiserfs /dev/hda10 \
| grep "Root block"
Otterremo qualcosa simile a:
debugreiserfs 3.6.17 (2003 www.namesys)
Root block: 8221
Come è facile indovinare, 8221 è il
numero del nostro blocco principale.
Dobbiamo anche, almeno approssimativamente, stabilire la dimensione
del nostro file – diciamo che esso aveva 10 kB, quindi il triplo della dimensione dei blocchi dovrebbe essere
sufficiente. A questo punto possiamo
allora eseguire il comando:
# dd bs=4k if=/dev/hda10 \
skip=8221 count=3 \
> ~/recovered.003
Dopo il recupero dei dati bisogna
verificare la loro concordanza con
il file cercato:
# cat ~/recovered.003
Come nel caso di ext2fs alla fine del
file possiamo incontrare spazzatura
di ogni genere – con facilità l'elimineremo.
Facilitarsi la vita
Esistono dei programmi, che automatizzano i modi presentati di recupero
dati. Il maggior numero degli strumenti
di questo tipo funziona con il file system ext2. Raccomandabile è il pacchetto unrm e la libreria e2undel scritta
da Olivier Diedrich, funzionante con
il pacchetto e2fsprogs. Ovviamente
non dovremo sempre aspettarci di
riuscire a recuperare il 100 per cento
dei file cancellati (a volte è possibile)
– se riusciremo a salvare circa l'80 per
cento di un file di grandi dimensioni,
potremo considerarlo un successo. n
hakin9 N o 3/2005