Un “prontuario” pratico su dd, dcfldd e dc3dd per l’uso in digital forensics: differenze, buone prassi e comandi pronti all’uso.

Cos’è e cosa cambia

dd (GNU coreutils)

Strumento standard Unix/Linux per copiare e convertire file, ma privo di funzionalità avanzate come il calcolo di checksum multipli, più file di output o una modalità di verifica. In pratica:

• copia byte-per-byte da/un device o file (immagini “raw” .dd);
• è ovunque (Linux, macOS, molti live-CD);
• fa poche cose, bene: per hashing, split, log ecc. bisogna usare altri tool (es. sha256sum, split, pv).

dcfldd (forensic dd)

dcfldd è un fork avanzato di dd, sviluppato dal Dipartimento della Difesa degli Stati Uniti per scopi di informatica forense. Le differenze chiave sono che dcfldd offre la possibilità di specificare più file di output, calcola checksum multipli simultaneamente, include una modalità di verifica per confrontare file e visualizza una percentuale di avanzamento del processo, tutte funzionalità non disponibili in dd. Quindi, in pratica:

• hashing on-the-fly (hash=sha256/sha1/md5/sha512) con salvataggio automatico (hashlog=);
• log degli errori e dei settori danneggiati (errlog=);
• progress/stato periodico (statusinterval=);
• split automatico in chunk forensi (ofsplit=) e output multipli (più of= nella stessa acquisizione);
• verifica post-acquisizione contro l’originale (vf=/verifyfile=);
• pattern write (es. bonifica con pattern=00) — utile per sanificare dischi di destinazione, non per l’evidenza.

In breve: dd è minimale e universalmente disponibile; dcfldd riduce gli errori operativi e velocizza le procedure forensi (hash, log, split, verifica) in un solo passaggio.

Buone prassi prima di acquisire

• Write-blocker hardware (preferibile). Se non disponibile, montare read-only:

# 1) Elenca dischi con flag RO
lsblk -o NAME,RO,SIZE,TYPE,MODEL,SERIAL

# 2) Imposta sola lettura (sul device intero, non sulla partizione)
sudo blockdev --setro /dev/sdX

# 3) Verifica che sia in sola lettura (1 = RO abilitato)
sudo blockdev --getro /dev/sdX

# 4) Rivedi lo stato
lsblk -d -o NAME,RO,SIZE,MODEL,SERIAL
----
Per tornare R/W:
sudo blockdev --setrw /dev/sdX

• Identifica il device giusto e fotografa lo stato: sudo fdisk -l /dev/sdX
• Prepara la cartella di caso con naming coerente (case ID, data ISO, operatore).
• Registra in un log: modello/seriale supporto, hash pre/post, tool/parametri, orari, errori e contromisure.

---

Esempi con dd (baseline)

1) Acquisizione raw con gestione errori e progresso

sudo dd if=/dev/sdX of=/evidence/Caso123/disk.dd \
  bs=4M conv=noerror,sync status=progress iflag=fullblock

• conv=noerror,sync: ignora errori di lettura e riempie con zeri per mantenere allineamento;
• iflag=fullblock: evita letture parziali (utile con pipe/stream);
• status=progress: barra di avanzamento (GNU dd).

2) Hash post-acquisizione (consigliato SHA-256)

cd /evidence/Caso123
sha256sum disk.dd | tee disk.dd.sha256.txt

---

Esempi con dcfldd (forensic-friendly)

1) Acquisizione + hash on-the-fly + log

sudo dcfldd if=/dev/sdX of=/evidence/Caso123/disk.dd \
  bs=4M conv=noerror,sync \
  hash=sha256 hashlog=/evidence/Caso123/disk.dd.sha256.txt \
  errlog=/evidence/Caso123/dcfldd.errors.log \
  statusinterval=30

• un unico passaggio produce immagine + hash + log errori;
• statusinterval=30: stampa stato ogni 30 s.

2) Doppia destinazione (originale + copia di lavoro)

sudo dcfldd if=/dev/sdX \
  of=/evidence/Caso123/disk.dd \
  of=/lab/Caso123/disk_working.dd \
  bs=4M conv=noerror,sync \
  hash=sha256 hashlog=/evidence/Caso123/disk.dd.sha256.txt \
  errlog=/evidence/Caso123/dcfldd.errors.log \
  statusinterval=30

• Riduce l’eventuale rischio di divergenze tra “master” e “working copy” in caso di dispositivi danneggiati.

3) Split automatico in chunk (es. 2 GiB) per storage/FAT32

sudo dcfldd if=/dev/sdX of=/evidence/Caso123/disk.dd \
  bs=4M conv=noerror,sync \
  ofsplit=2G \
  hash=sha256 hashlog=/evidence/Caso123/disk.dd.sha256.txt \
  statusinterval=30
# Ricomposizione:
cat /evidence/Caso123/disk.dd.* > /restore/disk.dd

4) Verifica che immagine e device coincidano

# A freddo, con il device ancora in sola lettura:
sudo dcfldd if=/dev/sdX vf=/evidence/Caso123/disk.dd \
  hash=sha256 statusinterval=30

• vf= (verify file) confronta i flussi (utile anche dopo trasferimenti/copie disk).

5) Log dettagliato dei settori danneggiati

sudo dcfldd if=/dev/sdX of=/evidence/Caso123/disk.dd \
  bs=512 conv=noerror,sync \
  errlog=/evidence/Caso123/badsectors.log \
  statusinterval=30

• Con bs=512 ottieni il dettaglio settore-per-settore (più lento ma più preciso per i bad blocks).

---

Note operative e suggerimenti

• Dimensione blocco (bs): 4M è un buon compromesso prestazioni/affidabilità. Per supporti instabili puoi scendere (1M o 512B) per aumentare la granularità dei retry/riempimenti;
• cache OS: in alcuni contesti si usa oflag=direct/iflag=direct per bypassare la cache. Verifica che il tuo dd li supporti e valuta l’impatto sulle performance;
• formati: dd/dcfldd producono RAW. Se il tuo flusso richiede E01/Ex01 (metadata + compressione + segmentazione nativa), usa gli strumenti libewf (ewfacquire) in alternativa;
• conservazione: mantieni master immodificato; lavora sempre su una working copy verificata e documenta ogni passaggio;
• sanificazione dei dischi di destinazione prima del riuso (non dell’evidenza!): # Esempio: azzera un disco di DESTINAZIONE sudo dcfldd if=/dev/zero of=/dev/sdY bs=4M pattern=00 statusinterval=30
• ambienti non Linux: su Windows è comune operare da live Linux o appliance forense. In alternativa, considera tool dedicati (FTK Imager, ecc.) quando la policy lo consente.

---

Mini “cheat-sheet”

• dd, acquisizione rapida + progress dd if=/dev/sdX of=case/img.dd bs=4M conv=noerror,sync status=progress iflag=fullblock sha256sum case/img.dd > case/img.dd.sha256.txt
• dcfldd, acquisizione completa (hash+log) dcfldd if=/dev/sdX of=case/img.dd bs=4M conv=noerror,sync \ hash=sha256 hashlog=case/img.dd.sha256.txt errlog=case/errors.log statusinterval=30
• dcfldd, split + doppia uscita + verifica dcfldd if=/dev/sdX of=case/img.dd of=/backup/img.dd \ ofsplit=2G bs=4M conv=noerror,sync \ hash=sha256 hashlog=case/img.dd.sha256.txt statusinterval=30 dcfldd if=/dev/sdX vf=case/img.dd hash=sha256 statusinterval=30

Cos’è dc3dd

dc3dd è una versione di dd patchata dal DoD Cyber Crime Center (DC3) pensata per la forensics. Aggiunge funzioni native come hashing on-the-fly (MD5/SHA-1/SHA-256/SHA-512), log dettagliati (anche machine-readable), split in segmenti, progress, error-logging raggruppato e funzioni di wipe/verify.

In più, a differenza di dcfldd (che è un fork), dc3dd è una patch di dd: in linea di massima segue gli aggiornamenti di dd e ha un set di opzioni diverso (non 1:1 con dcfldd).

Differenze chiave (dd vs dcfldd vs dc3dd)

• dd (baseline): minimale e ovunque; per hash/split/log serve combinarlo con altri tool.
• dcfldd (fork): pensato per DFIR; hash=… + hashlog=…, errlog=…, ofsplit=…, vf= per verifica contro l’originale; output multipli ripetendo of=.
• dc3dd (patch): comandi e nomi opzioni propri:
• Hashing: hash=md5|sha1|sha256|sha512; log in log= e/o hlog= (totali e piecewise), mlog= per log “machine-readable”.
• Split: usa set di file con ofs=BASE.FMT + ofsz=BYTES (es. estensioni 0000, 0001, …); diverso da ofsplit= di dcfldd.
• Output multipli & verifica: oltre a of= puoi usare hof=/hofs=: l’output viene hashato e verificato confrontando gli hash in/out; fhod= estende l’hash a tutto il device.
• Error handling: di default, se l’input è un device, riempie di zeri i settori illeggibili; con rec=off si ferma al primo errore. (In dd/dcfldd l’equivalente pratico è conv=noerror,sync.)
• Wipe/sanitize: wipe=/dev/sdY (zerofill o pattern), hwipe= con verifica post-wipe; puoi impostare pattern con pat=/tpat=.
• Tuning: ssz= forza la sector size; bufsz= regola il buffer I/O per performance; verb=on per report verboso.

Esempi pratici con dc3dd (DFIR)

1) Imaging + hash + log (singolo file)

sudo dc3dd if=/dev/sdX of=/evidence/Caso123/disk.dd \
  hash=sha256 log=/evidence/Caso123/logs/dc3dd.log \
  hlog=/evidence/Caso123/logs/dc3dd.hashlog

• Calcola SHA-256 on-the-fly e scrive log e hash (totali + piecewise).

2) Split in chunk da 2 GiB (naming automatico)

sudo dc3dd if=/dev/sdX ofs=/evidence/Caso123/disk.dd.0000 \
  ofsz=2G hash=sha256 \
  log=/evidence/Caso123/logs/dc3dd.log hlog=/evidence/Caso123/logs/dc3dd.hashlog

• Usa ofs=BASE.FMT (qui 0000) e ofsz=2G per segmentare in disk.dd.0000, 0001, …

3) Master + working copy con verifica automatica

sudo dc3dd if=/dev/sdX \
  of=/evidence/Caso123/disk_master.dd \
  hof=/lab/Caso123/disk_working.dd \
  hash=sha256 log=/evidence/Caso123/logs/dc3dd.log hlog=/evidence/Caso123/logs/dc3dd.hashlog

• hof= produce una copia con calcolo e verifica dell’hash rispetto all’input nella stessa passata.

4) Acquisizione con dischi “difficili” (settori e buffer)

sudo dc3dd if=/dev/sdX of=/evidence/Caso123/disk.dd \
  hash=sha256 ssz=512 bufsz=1M log=/evidence/Caso123/logs/dc3dd.log

• Forza sector size a 512 B e limita il buffer per aumentare la resilienza su device instabili.

5) Sanificazione del disco di destinazione (non dell’evidenza!)

# Zero-fill con verifica
sudo dc3dd hwipe=/dev/sdY

# Wipe con pattern 0x00 (senza verifica)
sudo dc3dd wipe=/dev/sdY pat=00

• Utile per preparare/bonificare i supporti di destinazione prima del riuso.

Quando preferirlo

• Vuoi split flessibile con naming prevedibile (ofs + ofsz) e verifica integrata sugli output (hof/hofs).
• Cerchi log ricchi (anche piecewise e machine-readable via mlog=) direttamente dal tool.

Note operative

• Come per dcfldd, mantieni master e working copy separati e documenta hash/log nel fascicolo.
• Puoi sostituire dcfldd con dc3dd mantenendo le stesse prassi (hash, split, log), adattando però i nomi opzione (ofsplit → ofs+ofsz, hashlog → hlog, verifica: vf → hof/hofs).

Confronto operativo (dd vs dcfldd vs dc3dd)

Attività / Feature	dd (baseline)	dcfldd (forensic fork)	dc3dd (patch DC3)
Imaging RAW	dd if=/dev/sdX of=img.dd bs=4M conv=noerror,sync status=progress	dcfldd if=/dev/sdX of=img.dd bs=4M conv=noerror,sync statusinterval=30	dc3dd if=/dev/sdX of=img.dd
Hash on-the-fly	— (usa sha256sum dopo)	hash=sha256 hashlog=img.sha256.txt	hash=sha256 hlog=hashes.txt (+ log= opzionale)
Log dettagliati	reindirizza std{out,err}	errlog=errors.log + output stato	log=dc3dd.log (testuale), mlog=machine.log (machine-readable)
Split immagine	esterno: split -b 2G	ofsplit=2G → img.dd.000, .001…	ofs=img.dd.0000 ofsz=2G → .0000, .0001…
Doppia uscita in una passata	— (fai copia dopo)	ripeti più of= nella stessa riga	hof=working.dd (output con hash & verifica)
Verifica contro sorgente	esterno: ricalcolo hash	vf=img.dd	con hof= verifica automaticamente la corrispondenza degli hash
Gestione settori danneggiati	conv=noerror,sync	conv=noerror,sync	riempie con zeri per default; puoi cambiare politica (fermarsi al primo errore)
Wipe/sanitize (solo dischi di destinazione)	dd if=/dev/zero of=/dev/sdY	pattern=00 su destinazione	wipe=/dev/sdY (o hwipe= con verifica post-wipe)

Regola pratica: dd = portabilità + minimalismo; dcfldd = “tutto-in-uno” semplice (hash/log/split/verify); dc3dd = control-freak con log ricchi, split robusto e verifica integrata dell’output (hof).

---

Esempi pratici

1) Imaging con hash e log

dcfldd

sudo dcfldd if=/dev/sdX of=case/disk.dd bs=4M conv=noerror,sync \
  hash=sha256 hashlog=case/logs/disk.sha256.txt errlog=case/logs/errors.log \
  statusinterval=30

dc3dd

sudo dc3dd if=/dev/sdX of=case/disk.dd \
  hash=sha256 hlog=case/logs/dc3dd.hashlog log=case/logs/dc3dd.log

2) Split a 2 GiB

dcfldd

sudo dcfldd if=/dev/sdX of=case/disk.dd ofsplit=2G \
  hash=sha256 hashlog=case/logs/disk.sha256.txt
# join:  cat case/disk.dd.* > case/disk.dd

dc3dd

sudo dc3dd if=/dev/sdX ofs=case/disk.dd.0000 ofsz=2G \
  hash=sha256 hlog=case/logs/dc3dd.hashlog
# join:  cat case/disk.dd.0* > case/disk.dd

3) Master + working copy, una sola passata

dcfldd

sudo dcfldd if=/dev/sdX of=case/disk_master.dd of=lab/disk_working.dd \
  hash=sha256 hashlog=case/logs/disk.sha256.txt

dc3dd (con verifica integrata dell’output)

sudo dc3dd if=/dev/sdX of=case/disk_master.dd \
  hof=lab/disk_working.dd \
  hash=sha256 hlog=case/logs/dc3dd.hashlog log=case/logs/dc3dd.log

4) Bonifica del destinazione (non dell’evidenza!)

dcfldd

sudo dcfldd if=/dev/zero of=/dev/sdY bs=4M pattern=00 statusinterval=30

dc3dd

sudo dc3dd hwipe=/dev/sdY    # wipe + verifica
# oppure:
sudo dc3dd wipe=/dev/sdY     # wipe senza verifica

---

“Option mapping” veloce

Hashing

• dd → sha256sum img.dd > img.dd.sha256.txt (post-acq)
• dcfldd → hash=sha256 hashlog=FILE
• dc3dd → hash=sha256 hlog=FILE (+ log=/mlog=)

Split

• dd → split -b 2G img.dd img.dd.
• dcfldd → ofsplit=2G → img.dd.000, .001…
• dc3dd → ofs=img.dd.0000 ofsz=2G → .0000, .0001…

Doppia uscita

• dd → cp/rsync dopo
• dcfldd → più of= nella stessa riga
• dc3dd → hof= / hofs= (con hashing/verifica)

Verifica

• dd → ricalcolo hash device vs file
• dcfldd → vf=img.dd
• dc3dd → con hof= l’output è verificato contro l’input

Errori lettura

• dd / dcfldd → conv=noerror,sync
• dc3dd → default riempie gli errori con zeri; modalità “stop on first error” selezionabile