|
Universal Disk Image Format
Das Universal Disk Image Format (UDIF) ist ein von Apple Computer, Inc. für Mac OS X entwickeltes proprietäres Dateiformat für Image-Dateien. Es ersetzte das zuvor mit Disk Copy 6.0 eingeführte New Disk Image Format (NDIF), bei dem die Metadaten in der resource fork gespeichert waren. Bei UDIF sind alle Daten – data fork, resource fork und Metadaten – in der Datei selbst gespeichert, was den Datenaustausch über das Internet oder Macintosh-fremde Medien erleichtert. Die erste Veröffentlichung von Mac OS X Public Beta (10.0, „Kodiak,“ 2000) beinhaltete bereits Betriebssystem-seitige Unterstützung für das Universal Disk Image Format, die mit der Dateinamenserweiterung Unter klassischem Mac OS wird UDIF nicht unterstützt. Es existieren jedoch eine Entwicklerversion von Disk Copy 6.4 sowie die Betaversion 6.5, die unkomprimierte, unverschlüsselte UDIF-Images unter Mac OS 9 unterstützen.[4] Für weitere Betriebssysteme gibt es per Reverse Engineering entstandene Programme zum Konvertieren von UDIF-Abbildern in andere Formate. Integration in Mac OS X/OS X/macOSUnter Mac OS X, das 2012 in OS X und 2016 in macOS umbenannt wurde, kann ein UDIF-Image mit mehreren Programmen erstellt werden. Auf der Kommandozeile kann mit Ebenfalls ab Mac OS X Panther kümmert sich die Der DiskImageMounter kann jedoch auch einfache Abbilddateien, wie sie etwa auch mit AufbauEin UDIF-Abbild besteht aus mehreren, teils komprimierten Abschnitten. Meist ist im Image auch eine Partitionstabelle enthalten. Die Daten sind, weil Mac OS X ursprünglich für die PowerPC-Architektur entwickelt wurde, in Big Endian kodiert. In der Regel beginnt die Datei mit dem binären Abbild, gefolgt von Metadaten wie der aus NDIF bekannten Resource Fork und einer Property List, gefolgt von einem Koly-Block. Die Resource Fork ist 1:1 das, was bei NDIF noch in einem alternativen Datenstrom im Dateisystem gespeichert war. Da diese Daten nun in der Datei selbst vorgehalten werden, kann eine UDIF-Datei gefahrlos und ohne Verlust der Metadaten über das Internet oder Macintosh-fremde Medien kopiert werden. Bei neueren Versionen von Mac OS X wird die Resource Fork in dieser binären Form üblicherweise weggelassen, weil die Daten zur Gänze in der Eine UDIF-Datei kann mehrere solche Segmente enthalten, sodass pro UDIF-Datei mehrere unabhängige Abbilder enthalten sein können. Ebenso kann mittels Partitionstabelle in einem Abbild mehr als eine Partition enthalten sein. Ein typischer Aufbau sieht demnach wie folgt aus:[5]
ImageDie Daten, die als Abbild eines Datenspeichers als UDIF gesichert werden, können in unterschiedlicher Form vorliegen, etwa als eine 1:1-Kopie oder als verschlüsselte Partition. Für UDIF ist nur wichtig, dass auch eine Blocktabelle und ein Koly-Block vorhanden ist, der die Form der Daten beschreibt. Meistens sind die Daten komprimiert. Insofern ist UDIF nicht auf eine spezielle Partitionstabelle oder ein spezifisches Dateisystem festgelegt. Abbilder von ISO-9660-Medien (auch als Hybrid) wie CD-ROMs oder DVDs sind ebenso gängig wie kleine Installations-Abbilder für Mac-Applikationen, die meist aus APM- oder GPT-Partitionstabelle mit einer Datenpartition im Apple-üblichen Dateisystem HFS+ oder APFS aufgebaut sind. BlocktabelleDie Blocktabelle vereinfacht durch das vorhalten von Blockadressen das Finden der richtigen Daten bzw. Partition innerhalb des Abbilds. Die Liste ist als Property List in XML verfasst und enthält in den meisten Fällen eine Aufteilung in Partitionen. Unter Mac OS X/OS X/macOS sind die beiden meistgenutzten Partitionstabellen die Apple Partition Map, daher finden sich in der In jedem Fall hält die Property List für jeden Bereich, wie einer Partition oder einem Dateisystem, einen Eintrag innerhalb des <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>resource-fork</key>
<dict>
<key>blkx</key>
<array>
<dict>
<key>Attributes</key>
<string>0x0050</string>
<key>CFName</key>
<string>Protective Master Boot Record (MBR : 0)</string>
<key>Data</key>
<data>
bWlza…
</data>
<key>ID</key>
<string>-1</string>
<key>Name</key>
<string>Protective Master Boot Record (MBR : 0)</string>
</dict>
</array>
<key>plst</key>
<array>
<dict>
<key>Attributes</key>
<string>0x0050</string>
<key>Data</key>
<data>
…
</data>
<key>ID</key>
<string>0</string>
<key>Name</key>
<string></string>
</dict>
</array>
</dict>
</dict>
</plist>
Durch die innerhalb des Der Bereich innerhalb typedef struct {
uint32_t Signature; // Magic ('mish')
uint32_t Version; // Current version is 1
uint64_t SectorNumber; // Starting disk sector in this blkx descriptor
uint64_t SectorCount; // Number of disk sectors in this blkx descriptor
uint64_t DataOffset;
uint32_t BuffersNeeded;
uint32_t BlockDescriptors; // Number of descriptors
uint32_t reserved1;
uint32_t reserved2;
uint32_t reserved3;
uint32_t reserved4;
uint32_t reserved5;
uint32_t reserved6;
UDIFChecksum checksum;
uint32_t NumberOfBlockChunks;
BLKXChunkEntry [0];
} __attribute__((__packed__)) BLKXTable;
// Where each BLXKRunEntry is defined as follows:
typedef struct {
uint32_t EntryType; // Compression type used or entry type (see next table)
uint32_t Comment; // "+beg" or "+end", if EntryType is comment (0x7FFFFFFE). Else reserved.
uint64_t SectorNumber; // Start sector of this chunk
uint64_t SectorCount; // Number of sectors in this chunk
uint64_t CompressedOffset; // Start of chunk in data fork
uint64_t CompressedLength; // Count of bytes of chunk, in data fork
} __attribute__((__packed__)) BLKXChunkEntry;
Folgende Blocktypen der Variable
Koly-BlockAls letzten 512-Byte-Block enthält ein
Da der Koly-Block so gut wie immer am Ende der Datei steht, kann man ihn relativ einfach nutzen, um die Property List zu finden: Die Werte für ErkennungDa sich die Information, dass es sich um eine Datei im Universal Disk Image Format handelt, als Koly-Block am Ende der Datei nach den unterschiedlichsten binären Daten befindet, ist eine inhaltsbasierte Erkennung einer UDIF-Datei über die verbreiteten Methode, den Header zu analysieren, nicht möglich. So werden Dateien mit der Endung Unter macOS gibt das Kommando user@Mac:~$ hdiutil imageinfo Datei.dmg | grep Format
Format Description: UDIF read-only compressed (zlib)
Format: UDZO
KompatibilitätAllgemein können keine UDIF-Dateien in älteren Mac-OS-X-Versionen verwendet werden, wenn diese den benutzten Kompressionsalgorithmus oder die genutzte Partitionstabelle oder das genutzte Dateisystem nicht unterstützen. Auf anderen Betriebssystemen sind die proprietären Kompressionsverfahren ADC und LZFSE nicht verfügbar, sodass nur zLib- und bz2-komprimierte Daten behandelt werden können. Unter den ganz alten Versionen von Mac OS X, 10.0 („Cheetah,“ 2001) und 10.1 („Puma,“ 2001), werden nur UDIF-Dateien mit vorhandener Resource Fork unterstützt. Ab Mac OS X Tiger 10.4.7 (Juni 2006) werden allerdings beim Erstellen einer UDIF-Datei die Felder Weblinks
Einzelnachweise
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
