Ich habe mehrere DMG-Dateien aus demselben Ordner erstellt - die Prüfsumme ist bei jeder anders?

Vor einiger Zeit ist mir aufgefallen, dass selbst wenn ich DMG-Dateien aus demselben Verzeichnis, mit denselben Dateien usw. erstelle, die Ergebnisse immer unterschiedlich sind. Nicht nur ihre Größe ist ~15 Bytes kürzer/länger voneinander, sondern ihre SHA-Prüfsummen (und ihr Inhalt, wenn sie vom HEX-Editor aus betrachtet werden) unterscheiden sich drastisch. Nur aus Neugier habe ich 5 komprimierte unverschlüsselte DMG-Dateien aus demselben Ordner erstellt, die nichts als eine einzige Textdatei enthalten. Die Ergebnisse sind:

  • 0.dmg | Größe - 26 204 Bytes, Prüfsumme - 5ba9ba0ee4d8ec5ba4718f1b491baf31c2c4e642
  • 1.dmg | Größe - 26 221 Byte, Prüfsumme - a86d76f6c07ee5a81c0aefb31b6fd40ef787ebd5
  • 2.dmg | Größe - 26 235 Byte, Prüfsumme - a31f4cf29e4e2858b7ac63c82574499200d81108
  • 3.dmg | Größe - 26 209 Byte, Prüfsumme - f3c19414279b6d6b94b90341453906e4a69e28dd
  • 4.dmg | Größe - 26 217 Byte, Prüfsumme - 9603c0334125762fc7908343e3ee400e038fe779

Ich habe im Internet gesurft, in der Hoffnung, irgendetwas über den "Daten-Randomizer in APFS" zu finden, aber ... konnte offensichtlich nichts finden, und außerdem wussten nicht viele Leute tatsächlich von dieser "Funktion". Gibt es Infos dazu?

Ich verwende macOS 10.12.6, die DMG-Dateien wurden mit dem Festplattendienstprogramm erstellt, aber ich erhalte die gleichen Ergebnisse mit hdiutil.

Wir benötigen mehr Informationen, um eine angemessene Antwort geben zu können. Ich vermute jedoch, dass sich die Quelle tatsächlich ändert, wenn auch nur in Metadaten (Zugriffszeitstempel usw.), und dass die DMG diese Änderungen widerspiegelt. Haben Sie versucht, mit verschiedenen Dateisystemen im Container zu testen?
Wenn sich die Bytes geändert haben, haben sich die Daten geändert, was bedeutet, dass sich die Prüfsumme geändert hat. Ich vermute, dass jsejcksn Recht hat und Metadaten geändert werden (15 Bytes sind sehr klein). Versuchen Sie zuerst, die Daten zu komprimieren, erstellen Sie dann eine dmg davon und prüfen Sie, ob die Daten und Prüfsummen gleich bleiben, oder schützen Sie das Verzeichnis, bevor Sie die dmg erstellen.
Ich habe das Dateisystem auf RW gesetzt und 2 DMG-Dateien erstellt, und eine davon ist 40 Byte größer als die zweite. Vielleicht haben Sie Recht, und die Metadaten dieser Textdatei ändern sich ("zuletzt geöffnet", vielleicht?). Ich werde versuchen, ein einfaches Skript zu schreiben, das die Informationen der Datei ausgibt, und hoffentlich wird ein nützliches Ergebnis angezeigt.
Ich werde die Datei auch sperren, wie Christian vorgeschlagen hat.
Okay, es ist also die Zugriffszeit, die sich ständig ändert. Ich habe es behoben, indem ich das "atime" in Start-Daemons deaktiviert habe, aber das neue Problem ist aufgetreten: Trotz der Tatsache, dass die Metadaten ziemlich gleich sind (Statistiken sind jetzt identisch), sind DMG-Dateien immer noch unterschiedlich. Was kann das sein...
@L0W_P1X3L: Sie müssten die detaillierte Struktur des Disk-Images untersuchen, um herauszufinden, was sich geändert hat. Dies wird viel einfacher sein, wenn es unkomprimiert ist. Aber im Allgemeinen sollten Sie nicht erwarten, dass dieselben Dateien genau dasselbe Disk-Image erzeugen – das Disk-Image-Format kann viele irrelevante Informationen enthalten (oder davon abhängen), die wahrscheinlich wirklich schwer zu kontrollieren sind. Ich bin mir nicht sicher, warum Sie dasselbe Disk-Image mehrmals erhalten möchten, aber was auch immer Ihr eigentliches Ziel ist, Sie sollten einen anderen Weg finden, es zu erreichen.

Antworten (1)

Kopien einer bestehenden Datei dmgsind identisch, aber separat erstellte dmgDateien nicht.

Effektiv Garantierte Abweichung

Das Apple Disk Image- .dmg Format garantiert effektiv, dass keine zwei Disk-Images Bit für Bit identisch sind. Die Gleichheit zwischen Disk-Images mit denselben Inhalten ist keine praktische Anforderung des Formats.

UUID innerhalb des 0x6B6F6C79/ koly-Blocks

Innerhalb des dmgDateiformats ist die kolyStruktur . Diese Struktur enthält eine SegmentID vom Typ uuid_t. Dies ist ein 128-Bit-Universally Unique Identifier ( UUID ). Allein die SegmentID-Kennung stellt sicher, dass sich jede dmgDatei um mehr als ein Bit unterscheidet.

Die Verwendung von HFSleuth auf dem Disk-Image von iTunes 11.0 zeigt die eingebettete UUID:

HFSleuth> ver
Verbose output is on
HFSleuth> fs iTunes11.dmg
KOLY header found at 200363895:
    UDIF version 4, Header Size: 512
    Flags:1
    Rsrc fork: None
    Data fork: from 0, spanning 200307220 bytes
    XML plist: from 200307220, spanning 56675 bytes (to 200363895)
    Segment #: 1, Count: 1
    Segment UUID: 626f726e-7743259b-6086eb93-4b42fb65
    Running Data fork offset 0
    Sectors: 1022244

Im obigen Beispiel Segment UUID: 626f726e-7743259b-6086eb93-4b42fb65ist die Zeile eine universell eindeutige Kennung, die in das Disk-Image eingebettet ist.

Ein-Bit-Unterschiede und Hash-Funktionen

Ein Unterschied in einem Bit sollte zu einer Änderung von 50 % oder mehr in der Ausgabe einer kryptografischen Hash-Funktion führen, z. B. SHA-2.

Die Verwendung einer UUID innerhalb der Struktur soll nicht sicherstellen, dass jedes Disk-Image eindeutig ist, sondern um die Segmentidentifikation innerhalb des Disk-Images zu erleichtern. Dass eine UUID Eindeutigkeitseigenschaften über den Bereich des Disk-Image hinaus bietet, ist ein Nebenprodukt der Verwendung der UUID.