Il settore danneggiato e l'acquisizione forense

Di Admin (del 16/01/2010 @ 11:55:42, in Computer Forensics, linkato 7365 volte)

Se si deve acquisire un hard disk in maniera forense, ossia con tutti i crismi n
ecessari al fine di garantire che la copia sia identica all'originale, a tutti q
uelli che operano nel settore viene subito in mente l'uso di DD, DCFLDD o DC3DD
(nel mondo Open Source GNU/Linux), con le classice opzioni e parametri.
Gli approcci sono due:
1) Ottimistico (consideriamo il disco sano e tutti i settori sani)
2) Pessimistico (consideriamo che il disco abbia qualche settore danneggiato)
Nel caso in cui l'approccio ottimistico sia sconfessato, perch durante l'acquisiz
ione ci si ritrova con degli errori di lettura, allora si tender a porsi nell'ott
ica pessimistica, a volte anche ricominciando tutto d'accapo.
Esaminiamo gli scenari:
dd if=/dev/sdb of=/media/sdc1/disco.dd conv=noerror,sync bs=32K
Il suscritto comando legger blocchi da 32Kb dal disco /dev/sdb e scriver sul disco
destinazione /media/sdc1 (montato in scrittura) il file disco.dd, l'opzione con
v=noerror,sync serve a due cose:
1) Noerror - indica a dd di non fermarsi di fronte ad eventuali errori di lettur
a, ignorando i blocchi illeggibili, ma questo, senza il sync, cambierebbe l'indi
rizzamento del disco, poich l'immagine (disco.dd) del disco avrebbe una dimension
e finale errata, inferiore a quella del disco originale.
2) Sync - Il flag sync forza dd a scrivere i blocchi della dimensione prescelta
(es. BS=32K) e se non ci sono abbastanza dati per riempire il blocco, quest'ulti
mo sar riempito di zeri (0s padding). Questo crea un problema, il file immagine d
i destinazione avr una dimensione multipla del BS prescelto. Es. se il disco orig
ine di 6Kb ed il BS=4K, il file immagine avr come dimensione 8Kb.
Inoltre, con un BS=32K e conv=noerror,sync, se dovessimo incontrare dei settori
danneggiati, che per appartengono al buffer di lettura di 32Kb, il dd cos configur
ato andrebbe a riempire ben 32Kb di zeri, sacrificando anche i settori sani che
potrebbero esserci in quei 32Kb. Se ci sono solo due di settori danneggiati 512
bytes * 2 =1024 bytes = 1Kb, significa che i rimanenti 31Kb saranno azzerati, pe
rch dd ha letto un blocco da 32Kb ha incontrato degli errori ed ha fatto il riemp
imento di zeri su tutto il blocco letto.
Quindi la soluzione sarebbe quella di impostare dd con un BS=512, che la misura
minima di un settore, cos da leggere il disco, settore per settore e nel caso uno
di essi fosse illeggibile, sarebbe riempito di zeri (sync), mentre il settore s
uccessivo (leggibile) sarebbe letto correttamente, preservandone il suo contenut
o.
dd if=/dev/sdb of=/media/sdc1/disco.dd conv=noerror,sync bs=512
Il problema di questa configurazione che stressa di pi gli hard disk, costringend
oli a moltissime letture (sector by sector) e rende l'operazione pi lenta.
Come risolvere?
Ci sono dei tools alternativi come ddrescue o dc3dd, che permettono di leggere b
locchi di dimensioni maggiori di 512 bytes, ma nel momento in cui si trovano di
fronte ad un errore, questi useranno il block size di dimensione minima, 512 byt
es appunto e lo riempiranno di zeri.
DC3DD ha il default blocksize di 32768 bytes (32Kb), al fine di aumentarne la pe
rformance.
Il file immagine finale calibrato sulla dimensione del disco sorgente indipenden
temente dalla dimensione del blocco, cos la dimensione del file immagine esattame
nte la stessa, come se avessimo usato un BS=512.
Sector Error Recovery
Quando si incontra un errore ed il block size pi grande del settore del device so
rgente, e il parametro conv=sync,noerror impostato, dc3dd cerca dalla fine all'i
nizio del blocco e prova a leggere ciascun settore indvidualmente, cos i settori
buoni saranno acquisiti e quelli cattivi saranno rimpiazzati dagli zero. Questa
caratteristica permette di acquisire le aree non danneggiate del disco a velocit
maggiori, (dato che il BS=32K), senza perdere i blocchi di dati che circondano u
n bad sector
Per attivare questa modalit richiesto il direct I/O mode abilitato (iflag=direct
su Linux, /dev/rdisk* su Mac OS X).
dc3dd if=/dev/sdb of=/media/sdc1/disco.dd conv=noerror,sync bs=32k iflag=direct
oppure con ddrescue
ddrescue -d -r3 /dev/sdb /media/sdc1/disco.dd log.txt
In sostanza il parametro iflag=direct o -d per ddrescue, serve a bypassare la Ke
rnel Cache (pagecache)* e accedere direttamente al disco (direct I/O), considera
ndo cos la dimensione minima del settore.
Chi volesse usare DCFLDD con direct access non pu utilizzare il parametro iflag=d
irect, dato che dcfldd un fork di dd, quindi non segue lo stesso sviluppo di que
st'ultimo, ma pu accedere al device sorgente in direct I/O tramite il /dev/raw (p
er questo documentarsi sul device raw in Gnu/Linux).
E' chiaro che per uso forense si tende ad usare di pi uno strumento come DC3DD d
ato che ha anche caratteristiche di multiple hashing automatico, verifica, ecc.
Es.: dc3dd if=/dev/sdb of=/media/sdc1/disco.dd conv=noerror,sync bs=32k iflag=di
rect progress=on hash=md5,sha1 log=log.txt vf=/dev/sdb verifylog=log_verifica.t
xt
*La page cache il luogo in cui il kernel mantiene in RAM una copia dei dati, per
migliorare le prestazioni evitando l'I/O del disco, quando i dati che devono es
sere letti sono gi in RAM.
DC3DD basato su DD, quindi iflag=direct funziona anche con DD.
================================================================================
==================================================================