Erstellen Sie ein zufälliges ISO-Image mit dd

Ich möchte eine ISO-Datei zum Testen von optischen Laufwerken mit der hier genannten Methode erstellen . Ich möchte eine ISO-Datei mit zufälligen Daten erstellen, damit ich sie auf eine CD brennen, zurücklesen und mit der ursprünglichen ISO vergleichen kann. Ich denke, der Befehl unten wird tun, was ich will.

dd if=/dev/urandom of=cd-rom_test.iso bs=2048 count=333000

Bei einigen Dingen bin ich mir jedoch nicht sicher.

Was soll die Blockgröße sein? Enthalten ISO-Images die Header- und Fehlerkorrekturdaten auf einer CD? Sollte die Blockgröße 2048 (ohne Header- und Fehlerkorrektur) oder 2352 (mit Header- und Fehlerkorrektur) sein?

Zweitens ein paar Seiten haben mir begegnet ist syncin der convOption (Beispiel hier ). Was, soweit ich sehen kann, die Header- und Fehlerkorrekturinformationen mit Nullen füllt, was sicherlich nicht richtig ist.

dd iso data-cd

— Robingrindrod
quelle

In den Beispielen auf der Seite, die Sie verlinkt haben, besteht die Option "Fehler und Synchronisierung" darin, Lesefehler auf dem zu lesenden Gerät zu behandeln. Wenn Sie beispielsweise eine zerkratzte CD hatten und mit Fehler lesen, synchronisieren Sie - die Fehlerblöcke, die vom Eingabegerät aktiviert wurden, werden in der Ausgabedatei auf Null gesetzt.

— Sean C.

Ok, ich verstehe jetzt besser. Vielen Dank.

— Robingrindrod

Ich bin etwas verwirrt darüber, was genau Sie versuchen und warum Sie eine ISO mit zufällig generierten Daten benötigen, anstatt eine normale ISO wie Linux CD Image zu verwenden.

— Karlson

333000 ist die Anzahl der Sektoren für eine 650-MB-CD. Eine 700 MB CD besteht aus 360000 Sektoren.

— Francesco Turco

Außerdem sollte die Blockgröße 2048 und nicht 2352 verwendet werden, da das ISO 9660-Dateisystem nicht in denselben Bytes geschrieben ist, die für Header-Informationen und Fehlerkorrekturdaten reserviert sind.

— Francesco Turco

Antworten:

Da Sie mit in eine Datei schreiben, ddändert die Blockgröße die resultierende Ausgabe nicht. Die Blockgröße spielt nur beim Schreiben auf Geräte eine Rolle.

Sie lesen von einem Gerät, das niemals kurze Lesevorgänge zurückgibt, sodass Sie keine syncBlöcke auffüllen müssen.

Hat in keinem Fall ddLese- oder Schreibzugriff auf die Fehlerkorrekturdaten. Wie bei magnetischen Medien verwaltet das Laufwerk diese Daten und Sie sehen nur die fehlerkorrigierten Blöcke.

— Kyle Jones
quelle

Danke für deine Hilfe. Es macht jetzt viel mehr Sinn. Der Grund, warum ich die Blockgröße angegeben habe, ist, dass ich die Anzahl angegeben habe. Die Blockgröße beeinflusst also die Datenmenge, die ich erhalte, nicht wahr?

— Robingrindrod

Selbst beim direkten Schreiben auf eine CD ist die Blockgröße nur eine Frage der Leistung. Die Blockgröße spielt nur beim Schreiben auf Bandgeräte eine Rolle.

— Gilles 'SO - hör auf böse zu sein'

Basierend auf dem, was Sie beschrieben haben, sollten Sie Folgendes tun:

dd if=/dev/urandom of=testfile bs=1M count=699
mkisofs -o test_cdrom.iso testfile

Sobald Sie fertig sind, können Sie nach Herzenslust auf und von den optischen Medien lesen und schreiben.

Eine Sache, die ich vorschlagen würde, ist, anstatt das optische Medium vorab zu testen und dann zu versuchen, die tatsächliche ISO zu schreiben und dann zu überprüfen, ob Sie die Zieldaten ISO auch einmal schreiben können, da dies genau das gleiche Ergebnis liefert, das Sie versuchen zu erreichen, ohne Zeit zu verbringen Write->Read->Verify->Format

— Karlson
quelle

Das Erstellen eines Bildes aus zufälligen Bytes ist keine gute Idee, da dies zu einem offensichtlich ungültigen ISO 9660-Dateisystem führt. Sie sollten stattdessen eine große Zufallsdatei erstellen, die weiterhin in einem gültigen ISO-Dateisystem abgelegt werden kann. Anschließend brennen Sie dieses ISO-Image und lesen den Inhalt der CD zum Vergleich mit der Originaldatei auf der Festplatte, z. B. mit entweder md5sumoder sha1sum. Wenn die Prüfsummen gleich sind, kann Ihr Laufwerk sowohl CDs schreiben als auch lesen.

— Francesco Turco
quelle

Vielen Dank für Ihre Hilfe. Würde es Ihnen etwas ausmachen zu klären, warum es wichtig ist, wenn die Daten ein gültiges ISO 9600-Dateisystem sind? Alles, was mich wirklich interessiert, sind die Rohdaten und ob sie richtig gelesen werden.

— Robingrindrod

Zuerst dachte ich, dass eine CD-Brennsoftware das Schreiben eines ungültigen ISO-Images ablehnen könnte, aber es scheint, dass dies nicht der Fall ist. Fügen Sie der Zufallsbilddatei nur nicht das .isoSuffix hinzu, da es sich nicht um ein ISO 9660-Dateisystem handelt. Wie auch immer , wenn Sie ISO - Images anstelle des Inhalts von ISO - Images vergleichen könnte es kleinere Probleme mit null Byte Hinter (siehe dies für weitere Details).

— Francesco Turco

Vielen Dank für den Tipp zu den nachgestellten Nullen. Haben Sie eine Idee, was dies verursacht? Haben Sie auch eine Quelle, um zu überprüfen, ob ISO-Images nur ISO 9660-Dateisysteme enthalten können, da auf der Wikipedia-Seite angegeben ist , dass "der Name ISO aus dem ISO 9660-Dateisystem stammt, das mit CD-ROM-Medien verwendet wird, aber als ISO bezeichnet wird Das Bild enthält möglicherweise auch ein UDF-Dateisystem (ISO / IEC 13346) oder ein DVD- oder Blu-ray Disc-Bild (BD). "

— Robingrindrod

Leider weiß ich nicht, was das Vorhandensein von nachgestellten Nullen verursacht. Andere Bilder als ISO 9660-Dateisysteme habe ich noch nie gesehen. Aber bitte bedenken Sie, dass ich kein Experte bin. Lassen Sie uns abwarten, ob jemand anderes mehr weiß als wir.

— Francesco Turco

In diesem Beitrag wird erwähnt, dass die nachfolgenden Nullen möglicherweise den letzten Block auffüllen, wenn die Daten nicht gleichmäßig in die Blöcke passen. Ist es das, worauf Sie sich bezogen haben, oder haben Sie zusätzliche Blöcke mit Nullen erlebt?

— Robingrindrod