Was macht dd conv = sync, noerror?

Was ist also der Fall, wenn das Hinzufügen conv=sync,noerroreinen Unterschied macht, wenn eine gesamte Festplatte auf einer Image-Datei gesichert wird? Ist conv=sync,noerroreine Anforderung bei forensischen Sachen? Wenn ja, warum ist es in Bezug auf Linux Fedora der Fall?

Bearbeiten:

OK, wenn ich also auf dd verzichte conv=sync,noerrorund ddbeim Lesen des Blocks auf Lesefehler stoße (lasst uns 100M groß werden), überspringt dd einfach 100M Block und liest den nächsten Block, ohne etwas zu schreiben ( dd conv=sync,noerrorschreibt Nullen in 100M Ausgabe - was ist mit diesem Fall?) ?)?

Und wenn der Hash der Original-Festplatte und der Ausgabedatei anders ist, wenn nicht conv=sync,noerror ? Oder ist dies nur beim Lesen ein Fehler aufgetreten?

conv=sync erzählt dd jeden Block auf der linken Seite mit Nullen aufzufüllen, so dass der volle Block aufgrund eines Fehlers, wenn nicht gelesen werden kann, wird die volle Länge der Originaldaten erhalten, auch wenn die Daten nicht alle selbst im Bild enthalten sein können , . Auf diese Weise wissen Sie zumindest, wie beschädigt die Daten sind, was Ihnen möglicherweise forensische Hinweise liefert, und wenn Sie aufgrund von fehlerhaften Blöcken oder Ähnlichem überhaupt kein Bild aufnehmen können, können Sie keine der Daten analysieren. manche sind besser als keine.

conv=sync,noerrorist notwendig, um zu verhindern dd, dass ein Fehler auftritt und ein Dump ausgeführt wird. conv=syncist weitgehend bedeutungslos ohne Fehler.

http://linuxcommand.org/man_pages/dd1.html

http://vlinux-freak.blogspot.com/2011/01/how-to-use-dd-command.html

dd conv=sync,noerror(oder conv=noerror,sync) verfälscht Ihre Daten.

Abhängig vom aufgetretenen E / A-Fehler und der verwendeten Blockgröße (größer als der physische Sektor?) Bleiben die Eingabe- und Ausgabeadressen nicht synchron, sondern landen am falschen Versatz, wodurch die Kopie für Dateisystem-Images und andere unbrauchbar wird Dinge, bei denen Versätze eine Rolle spielen.

Viele Orte empfehlen die Verwendung conv=noerror,sync beim Umgang mit defekten Datenträgern zu verwenden. Ich selbst habe die gleiche Empfehlung gemacht. Es hat bei mir funktioniert, als ich vor einiger Zeit eine fehlerhafte Festplatte wiederherstellen musste.

Tests haben jedoch ergeben, dass dies in keiner Weise zuverlässig ist.

Verwenden Sie losetupund dmsetup, um ein A error BGerät zu erstellen :

truncate -s 1M a.img b.img
A=$(losetup --find --show a.img)
B=$(losetup --find --show b.img)
i=0 ; while printf "A%06d\n" $i ; do i=$((i+1)) ; done > $A
i=0 ; while printf "B%06d\n" $i ; do i=$((i+1)) ; done > $B

Die A, B-Loop-Geräte sehen folgendermaßen aus:

# head -n 3 $A $B
==> /dev/loop0 <==
A000000
A000001
A000002

==> /dev/loop1 <==
B000000
B000001
B000002

So ist es A, B mit inkrementierenden Zahlen, die uns helfen, Offsets später zu überprüfen.

Um nun einen Lesefehler zwischen die beiden zu setzen, mit freundlicher Genehmigung von Linux Device Mapper:

# dmsetup create AerrorB << EOF
0 2000 linear $A 0
2000 96 error
2096 2000 linear $B 48
EOF

Dieses Beispiel erstellt AerrorBwie in 2000Sektoren von A, gefolgt von 2*48Sektoren von Fehlern, gefolgt von 2000Sektoren vonB .

Nur zur Verifizierung:

# blockdev --getsz /dev/mapper/AerrorB
4096
# hexdump -C /dev/mapper/AerrorB
00000000  41 30 30 30 30 30 30 0a  41 30 30 30 30 30 31 0a  |A000000.A000001.|
00000010  41 30 30 30 30 30 32 0a  41 30 30 30 30 30 33 0a  |A000002.A000003.|
[...]
000f9fe0  41 31 32 37 39 39 36 0a  41 31 32 37 39 39 37 0a  |A127996.A127997.|
000f9ff0  41 31 32 37 39 39 38 0a  41 31 32 37 39 39 39 0a  |A127998.A127999.|
000fa000
hexdump: /dev/mapper/AerrorB: Input/output error

Es liest also bis A127999\n, da jede Zeile 8 Bytes hat, was 1024000 Bytes entspricht, was unseren 2000 Sektoren mit 512 Bytes entspricht. Alles scheint in Ordnung zu sein ...

Wird es sich mischen?

for bs in 1M 64K 16K 4K 512 42
do
    dd bs=$bs conv=noerror,sync if=/dev/mapper/AerrorB of=AerrorB.$bs.gnu-dd
    busybox dd bs=$bs conv=noerror,sync if=/dev/mapper/AerrorB of=AerrorB.$bs.bb-dd
done

ddrescue /dev/mapper/AerrorB AerrorB.ddrescue

Ergebnisse:

# ls -l
-rw-r--r-- 1 root root 2113536 May 11 23:54 AerrorB.16K.bb-dd
-rw-r--r-- 1 root root 2064384 May 11 23:54 AerrorB.16K.gnu-dd
-rw-r--r-- 1 root root 3145728 May 11 23:54 AerrorB.1M.bb-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.1M.gnu-dd
-rw-r--r-- 1 root root 2097186 May 11 23:54 AerrorB.42.bb-dd
-rw-r--r-- 1 root root 2048004 May 11 23:54 AerrorB.42.gnu-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.4K.bb-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.4K.gnu-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.512.bb-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.512.gnu-dd
-rw-r--r-- 1 root root 2162688 May 11 23:54 AerrorB.64K.bb-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.64K.gnu-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.ddrescue

An den Dateigrößen allein können Sie erkennen, dass einige Blockgrößen falsch sind.

Prüfsummen:

# md5sum *
8972776e4bd29eb5a55aa4d1eb3b8a43  AerrorB.16K.bb-dd
4ee0b656ff9be862a7e96d37a2ebdeb0  AerrorB.16K.gnu-dd
7874ef3fe3426436f19ffa0635a53f63  AerrorB.1M.bb-dd
6f60e9d5ec06eb7721dbfddaaa625473  AerrorB.1M.gnu-dd
94abec9a526553c5aa063b0c917d8e8f  AerrorB.42.bb-dd
1413c824cd090cba5c33b2d7de330339  AerrorB.42.gnu-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.4K.bb-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.4K.gnu-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.512.bb-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.512.gnu-dd
3c101af5623fe8c6f3d764631582a18e  AerrorB.64K.bb-dd
6f60e9d5ec06eb7721dbfddaaa625473  AerrorB.64K.gnu-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.ddrescue

ddstimmt ddrescuenur für Blockgrößen zu, die zufällig an unserer Fehlerzone ausgerichtet sind ( 512, 4K).

Lassen Sie uns die Rohdaten überprüfen.

# grep -a -b --only-matching B130000 *
AerrorB.16K.bb-dd:  2096768:B130000
AerrorB.16K.gnu-dd: 2047616:B130000
AerrorB.1M.bb-dd:   2113152:B130000
AerrorB.1M.gnu-dd:  2064000:B130000
AerrorB.42.bb-dd:   2088578:B130000
AerrorB.42.gnu-dd:  2039426:B130000
AerrorB.4K.bb-dd:   2088576:B130000
AerrorB.4K.gnu-dd:  2088576:B130000
AerrorB.512.bb-dd:  2088576:B130000
AerrorB.512.gnu-dd: 2088576:B130000
AerrorB.64K.bb-dd:  2113152:B130000
AerrorB.64K.gnu-dd: 2064000:B130000
AerrorB.ddrescue:   2088576:B130000

Die Daten selbst scheinen zwar vorhanden zu sein, sind jedoch offensichtlich nicht synchronisiert. Die Offsets sind für bs = 16K, 1M, 42,64K völlig aus dem Gleichgewicht ... nur diejenigen mit Offset 2088576sind korrekt, wie anhand des Originalgeräts überprüft werden kann.

# dd bs=1 skip=2088576 count=8 if=/dev/mapper/AerrorB 
B130000

Ist das erwartetes Verhalten von dd conv=noerror,sync? Ich weiß es nicht und die beiden Implementierungen, die ddich zur Verfügung hatte, stimmen nicht einmal überein. Das Ergebnis ist sehr nutzlos, wenn Sie ddeine performante Blockgrößenauswahl verwenden.

Die oben wurde hergestellt unter Verwendung von dd (coreutils) 8.25, BusyBox v1.24.2, GNU ddrescue 1.21.