INFORMATICA - DIGITAL-FORENSICS - dd

Dicembre 2007

Durante le lezioni di computer e network forensics che svolgo soprattutto nelle Facoltà di Ingegneria è comune che degli studenti si sentano scandalizzati dal fatto che la mia fiducia verso il comando dd sia limitata esattamente come quella verso tutti gli altri strumenti di imaging di memorie di massa.

Come ribadito nella pagina sui write-blocker non sono interessato al funzionamento corretto in ambiente ottimale del tool quanto alla sua capacità di gestione delle eccezioni che possono capitare durante il suo impiego in ambiente reale e precisamente in situazioni inerenti il forensics. Purtroppo nell'ambiente citato gli errori fisici e logici sulla memoria di massa sono piuttosto comuni. Il perchè di questo è abbastanza chiaro se si è avvezzi alle attività del computer forensics: la copia e l'analisi sono procedure che stressano enormemente qualsiasi supporto fisico che li riguardi e quindi, (1) sia il reperto originale durante la copia, che si trova ad operare settore per settore in un'operazione di scansione dell'area fisica che raramente se non mai è avvenuta in precedenza e poi (2) i supporti su cui viene riversata l'immagine della memoria clonata, i quali dopo alcuni mesi di impiego iniziano già a mostrare evidenti segni di cedimento a seguito dell'impegno massivo di letture/scritture e seeking.

Si potrebbe osservare, senza tema di smentite, che le memorie digitali comuni non sono state progettate per l'impiego nel settore forensics e quindi repertamento dati ed analisi portano in media problemi ed errori di accesso che inevitabilmente devono essere gestiti da software e workstation forensi.

Tornando a dd e fermo restando in quale situazione lo si intende impiegare, bisogna ora puntualizzare alcuni importanti punti:

(a) Cos'è dd? ad oggi, comunemente, si considera dd il comando delle GNU coreutils - basic operations la cui interfaccia è definita in http://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.html e quindi, riprendendo testualmente quanto nel link: "dd copies a file (from standard input to standard output, by default) with a changeable I/O block size, while optionally performing conversions on it." Questa domanda non è banale perchè sebbene il comando dd esista in diversi ambienti rispondendo a specifiche funzionali analoghe non è detto che sia implementato nella stessa maniera. Si pensi che dd è nato come sostitutivo in ambiente Unix di un comando DD (Dataset Definition) degli IBM System 360 operante in JCL (Job Control Language)... http://www.linuxjournal.com/article/1320

(b) Cosa interessa di dd dal punto di vista forense? Anche in questo caso basta far riferimento alla letteratura scientifica in proposito rifacendosi al sito del NIST http://www.ncjrs.gov/pdffiles1/nij/203095.pdf che testualmente cita:

- The tool shall make a bit-stream duplicate or an image of an original disk or partition.

- The tool shall not alter the original disk.

- The tool shall log I/O errors.

- The tool’s documentation shall be correct.

A questo, rifacendomi al codice di procedura penale italiano, aggiungo (o forse meglio, puntualizzo) la necessità di operare in maniera perfettamente deterministica e ripetibile, anche in caso di errori.

La prima domanda che ci si pone è quindi la seguente: il dd può emettere verso la memoria-reperto dei comandi che direttamente o indirettamente ne possano alterare il contenuto? La risposta più generale e valida è che dipende da come il dd è stato implementato a livello di codice. Dato che esiste anche solo un velato dubbio che il codice del dd considerato possa creare qualche problema il tecnico forense opta per l'impiego di un write-blocker hardware durante le attività di imaging.

In questo modo si sposta il problema del danneggiamento del reperto fisico iniziale sulla certificata possibilità del write-blocker di impedire che qualsivoglia implementazione del dd inoltri comandi inadeguati all'hardware della memoria di massa.

La seconda domanda è: cosa accade quando dd incontra un errore in lettura? (situazione di estrema rilevanza nel nostro studio) In questo caso la risposta si può trovare nelle specifiche funzionali del comando. Impiegando le direttive noerror/sync si può ottenere di andare avanti nella copia nonostante l'errore e di ricostruire, nel file immagine, il blocco mancato pieno di null oppure di escluderlo definitivamente.

Bisogna fare molta attenzione al fatto che si è parlato di blocco e non di settore fisico...

Con un piccolo passo indietro ricordiamo che Unix, tra le sue eccezionali feature ha quella di considerare quasi tutto come un file, anche le periferiche interne o esterne quali le memorie di massa. Il file va letto/scritto a blocchi. Se si considera ad esempio un hard disk come device la lettura dei suoi dati avviene in blocchi che raccolgono un certo numero di settori fisici.

Torniamo quindi alla situazione proposta dalla seconda domanda: se il dd intercetta un errore in lettura esclude un blocco o lo sostituisce. Di seguito alcune considerazioni:

(1) se l'errore è su un preciso settore fisico (come è plausibile) l'esclusione del blocco può determinare l'esclusione di settori adiacenti (nella lettura fisica) a quello errato che non necessariamente presentano problemi in I/O da cui si potrebbe avere una perdita di informazioni (il reperto-dati o clone non sarà conforme all'originale);

(2) la dimensione del blocco (opzione di dd) determina quanta informazione plausibilmente si può perdere per cui converrebbe ridurre il blocco ad 1 solo settore fisico e non si avrebbero perdite correlate;

(3) l'esperienza insegna che diminuendo la dimensione del blocco le operazioni di I/O con dd divengono estremamente lente fino ad essere inapplicabili da cui è necessario tenere il blocco di dimensioni adeguate.

Non voglio poi dilungarmi molto su cosa accade al valore di hash del file immagine se si scelgono dimensioni di blocchi o opzioni di sostituzione differenti (queste scelte vanno ben documentate durante l'attività ovviamente). Le problematiche citate ed altre che considero minori ma comunque importanti (come il logging, l'hashing a blocchi, ecc.) hanno determinato la progettazione di particolari dd orientati al forensics che potrebbero essere impiegati in luogo del GNU dd. Alcuni esempi sono(cito le indicazioni degli URL riportati per una veloce valutazione del lettore):

  • rdd (http://sourceforge.net/projects/rdd & http://www.forensics.nl) is a forensic copy program developed at and used by the Netherlands Forensic Institute (NFI). Unlike most copy programs, rdd is robust with respect to read errors, which is an important property in a forensic operating environment.

  • dcfldd (http://dcfldd.sourceforge.net/) is an enhanced version of GNU dd with features useful for forensics and security. Based on the dd program found in the GNU Coreutils package, dcfldd has the following additional features:
  1. Hashing on-the-fly - dcfldd can hash the input data as it is being transferred, helping to ensure data integrity.
  2. Status output - dcfldd can update the user of its progress in terms of the amount of data transferred and how much longer operation will take.
  3. Flexible disk wipes - dcfldd can be used to wipe disks quickly and with a known pattern if desired.
  4. Image/wipe Verify - dcfldd can verify that a target drive is a bit-for-bit match of the specified input file or pattern.
  5. Multiple outputs - dcfldd can output to multiple files or disks at the same time.
  6. Split output - dcfldd can split output to multiple files with more configurability than the split command.
  7. Piped output and logs - dcfldd can send all its log data and output to commands as well as files natively.
  1. dd_rescue does not provide character conversions.
  2. The command syntax is different. Call dd_rescue -h.
  3. dd_rescue does not abort on errors on the input file, unless you specify a maximum error number. Then dd_rescue will abort when this number is reached.
  4. dd_rescue does not truncate the output file, unless asked to.
  5. You can tell dd_rescue to start from the end of a file and move bcakwards.
  6. It uses two block sizes, a large (soft) block size and a small (hard) block size. In case of errors, the size falls back to the small one and is promoted again after a while without errors.
  7. It does not (yet) support non-seekable in- or output.
  • sdd (http://directory.fsf.org/project/sdd/)  'sdd' is a replacement for a program called 'dd'. sdd is much faster than dd in cases where input block size (ibs) is not equal to the output block size (obs)...

marcomattiucci.it

Informatica:

Digital Forensics - articoli:

Digital forensics: