Forensische Image-Erstellung mit dd und dcfldd
Verwendungszweck
- Wenn Sie eine forensische Kopie eines verdächtigen Laufwerks für Untersuchungen benötigen
- Bei der Incident-Response, bevor Sie flüchtige Datenträgerdaten analysieren
- Für Strafverfolgungs- oder Gerichtsverfahren, die eine verifizierte bitgenaue Kopie erfordern
- Vor der Durchführung zerstörender Analysen an einem Speichergerät
- Bei der Image-Erstellung von physischen Laufwerken, USB-Geräten oder Speicherkarten
Voraussetzungen
- Linux-basierte Forensik-Workstation (SIFT, Kali oder eine beliebige Linux-Distribution)
dd(vorinstalliert auf allen Linux-Systemen) oderdcfldd(erweiterte forensische Version)- Hardware-Schreibblocker oder konfigurierter Software-Schreibschutz
- Ziellaufwerk mit ausreichend Speicherplatz (größer als die Quelle)
- Root-/sudo-Rechte auf der Forensik-Workstation
- SHA-256- oder MD5-Hash-Dienstprogramme (
sha256sum,md5sum)
Ablauf
Schritt 1: Zielgerät identifizieren und Schreibschutz aktivieren
# Alle angeschlossenen Blockgeräte auflisten, um das Ziel zu identifizieren
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL
# Gerätedetails überprüfen
fdisk -l /dev/sdb
# Software-Schreibblockierung aktivieren (falls kein Hardware-Blocker vorhanden)
blockdev --setro /dev/sdb
# Schreibschutz-Status überprüfen
blockdev --getro /dev/sdb
# Ausgabe: 1 (bedeutet Schreibschutz aktiv)
# Alternativ: Udev-Regeln für dauerhaften Schreibschutz
echo 'SUBSYSTEM=="block", ATTRS{serial}=="WD-WCAV5H861234", ATTR{ro}="1"' > /etc/udev/rules.d/99-writeblock.rules
udevadm control --reload-rules
Schritt 2: Ziel vorbereiten und Quelle dokumentieren
# Verzeichnisstruktur für den Fall anlegen
mkdir -p /cases/case-2024-001/{images,hashes,logs,notes}
# Quell-Laufwerksinformationen dokumentieren
hdparm -I /dev/sdb > /cases/case-2024-001/notes/source_drive_info.txt
# Seriennummer und Modell notieren
smartctl -i /dev/sdb >> /cases/case-2024-001/notes/source_drive_info.txt
# Vorab-Hash des Quellgeräts erstellen
sha256sum /dev/sdb | tee /cases/case-2024-001/hashes/source_hash_before.txt
Schritt 3: Image mit dd erstellen
# Basis dd-Akquise mit Fortschrittsanzeige und Fehlerbehandlung
dd if=/dev/sdb of=/cases/case-2024-001/images/evidence.dd \
bs=4096 \
conv=noerror,sync \
status=progress 2>&1 | tee /cases/case-2024-001/logs/dd_acquisition.log
# Für komprimierte Images (Platzersparnis)
dd if=/dev/sdb bs=4096 conv=noerror,sync status=progress | \
gzip -c > /cases/case-2024-001/images/evidence.dd.gz
# Verwendung von dd mit einer bestimmten Anzahl für partielle Images
dd if=/dev/sdb of=/cases/case-2024-001/images/first_1gb.dd \
bs=1M count=1024 status=progress
Schritt 4: Akquise mit dcfldd (bevorzugte forensische Methode)
# Installation von dcfldd (falls nicht vorhanden)
apt-get install dcfldd
# Image mit integriertem Hashing und segmentierter Ausgabe erstellen
dcfldd if=/dev/sdb \
of=/cases/case-2024-001/images/evidence.dd \
hash=sha256,md5 \
hashwindow=1G \
hashlog=/cases/case-2024-001/hashes/acquisition_hashes.txt \
bs=4096 \
conv=noerror,sync \
errlog=/cases/case-2024-001/logs/dcfldd_errors.log
# Große Images in handhabbare Segmente aufteilen
dcfldd if=/dev/sdb \
of=/cases/case-2024-001/images/evidence.dd \
hash=sha256 \
hashlog=/cases/case-2024-001/hashes/split_hashes.txt \
bs=4096 \
split=2G \
splitformat=aa
# Akquise mit Verifikationsdurchlauf
dcfldd if=/dev/sdb \
of=/cases/case-2024-001/images/evidence.dd \
hash=sha256 \
hashlog=/cases/case-2024-001/hashes/verification.txt \
vf=/cases/case-2024-001/images/evidence.dd \
verifylog=/cases/case-2024-001/logs/verify.log
Schritt 5: Image-Integrität überprüfen
# Hash des erstellten Images generieren
sha256sum /cases/case-2024-001/images/evidence.dd | \
tee /cases/case-2024-001/hashes/image_hash.txt
# Hash von Quelle und Image vergleichen
diff <(sha256sum /dev/sdb | awk '{print $1}') \
<(sha256sum /cases/case-2024-001/images/evidence.dd | awk '{print $1}')
# Bei segmentierten Images: jedes Segment überprüfen
sha256sum /cases/case-2024-001/images/evidence.dd.* | \
tee /cases/case-2024-001/hashes/split_image_hashes.txt
# Quell-Hash erneut erstellen, um sicherzustellen, dass keine Änderungen aufgetreten sind
sha256sum /dev/sdb | tee /cases/case-2024-001/hashes/source_hash_after.txt
diff /cases/case-2024-001/hashes/source_hash_before.txt \
/cases/case-2024-001/hashes/source_hash_after.txt
Schritt 6: Akquiseprozess dokumentieren
# Akquisebericht erstellen
cat << 'EOF' > /cases/case-2024-001/notes/acquisition_report.txt
PROTOKOLL DER DATENTRÄGER-IMAGE-ERSTELLUNG
==========================================
Fallnummer: 2024-001
Datum/Uhrzeit: $(date -u +"%Y-%m-%d %H:%M:%S UTC")
Prüfer: [Name]
Quellgerät: /dev/sdb
Modell: [aus hdparm-Ausgabe]
Seriennummer: [aus hdparm-Ausgabe]
Größe: [aus fdisk-Ausgabe]
Akquise-Tool: dcfldd v1.9.1
Blockgröße: 4096
Schreibblocker: [Modell Hardware/Software]
Imagedatei: evidence.dd
Image-Hash (SHA-256): [aus Hash-Datei]
Quell-Hash (SHA-256): [aus Hash-Datei]
Hash-Übereinstimmung: JA/NEIN
Fehler während der Akquise: [aus Fehlerprotokoll]
EOF
# Protokolle für die Archivierung komprimieren
tar -czf /cases/case-2024-001/acquisition_package.tar.gz \
/cases/case-2024-001/hashes/ \
/cases/case-2024-001/logs/ \
/cases/case-2024-001/notes/
Schlüsselkonzepte
| Konzept | Beschreibung |
|---|---|
| Bitgenaue Kopie | Exaktes Abbild der Quelle, einschließlich nicht zugewiesenen Speicherplatzes und Slack-Space |
| Schreibblocker | Hardware- oder Softwaremechanismus, der Schreibzugriffe auf Beweismittelmedien verhindert |
| Hash-Verifikation | Kryptografischer Hash-Vergleich von Quelle und Image zum Nachweis der Integrität |
| Blockgröße (bs) | Übertragungsblockgröße, die die Geschwindigkeit beeinflusst; 4096 oder 64K typisch für Forensik |
| conv=noerror,sync | Bei Lesefehlern fortfahren und mit Nullen auffüllen, um die Offset-Ausrichtung zu erhalten |
| Beweismittelkette | Dokumentierte Nachweiskette, die belegt, dass Beweismittel nicht manipuliert wurden |
| Split-Imaging | Aufteilung großer Images in kleinere Dateien für Speicherung und Transport |
| Raw/dd-Format | Bitgenaues Image-Format ohne Container-Metadaten-Overhead |
Werkzeuge und Systeme
| Werkzeug | Zweck |
|---|---|
| dd | Standard- Unix-Datenträger-Duplizierungsdienstprogramm für Raw-Imaging |
| dcfldd | Erweiterte Version von dd des DoD Computer Forensics Laboratory mit Hashing |
| dc3dd | Eine weitere forensische dd-Variante des DoD Cyber Crime Center |
| sha256sum | SHA-256-Hash-Berechnung zur Integritätsprüfung |
| blockdev | Linux-Befehl zum Setzen des Schreibschutz-Modus für Blockgeräte |
| hdparm | Laufwerksidentifikation und Parameterabfrage |
| smartctl | S.M.A.R.T.-Datenabruf zur Laufwerksgesundheit und -identifikation |
| lsblk | Auflistung und Identifikation von Blockgeräten |
Häufige Szenarien
Szenario 1: Image-Erstellung einer verdächtigen Laptop-Festplatte
Schließen Sie das Laufwerk über einen Tableau T35u Hardware-Schreibblocker an, identifizieren Sie es als /dev/sdb, verwenden Sie dcfldd mit SHA-256-Hashing, teilen Sie es in 4GB-Segmente für die DVD-Archivierung auf, überprüfen Sie die Hash-Übereinstimmung und dokumentieren Sie alles in den Fallnotizen.
Szenario 2: Image eines USB-Flash-Laufwerks von einer kompromittierten Workstation
Verwenden Sie Software-Schreibblockierung mit blockdev --setro, akquirieren Sie mit dcfldd und MD5- und SHA-256-Doppel-Hashing. Das Image ist klein genug für eine einzelne Datei. Überprüfen und speichern Sie es auf einem verschlüsselten Falllaufwerk.
Szenario 3: Fernakquise über Netzwerk
Verwenden Sie dd, das durch netcat oder ssh geleitet wird, für die Fernakquise: ssh root@remote "dd if=/dev/sda bs=4096" | dd of=remote_image.dd bs=4096. Hashen Sie beide Enden unabhängig, um die Übertragungsintegrität zu überprüfen.
Szenario 4: Image von einem defekten Laufwerk
Verwenden Sie zuerst ddrescue, um lesbare Sektoren wiederherzustellen, dann dd mit conv=noerror,sync, um Lücken mit Nullen zu füllen. Dokumentieren Sie die nicht lesbaren Sektoren im Fehlerprotokoll.
Ausgabeformat
Akquise-Zusammenfassung:
Quelle: /dev/sdb (500 GB Western Digital WD5000AAKX)
Ziel: /cases/case-2024-001/images/evidence.dd
Werkzeug: dcfldd 1.9.1
Blockgröße: 4096 Bytes
Dauer: 2h 15m 32s
Kopierte Bytes: 500.107.862.016
Fehler: 0 defekte Sektoren
Quell-SHA-256: a3f2b8c9d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1
Image-SHA-256: a3f2b8c9d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1
Verifikation: BESTANDEN - Hashes stimmen überein