Apple Disk Image

The first noteable fact about the DMG file format is, that there is no DMG file format. DMGs come in a variety of sub-formats, corresponding to the different tools which create them, and their compression schemes. The common denominator of most of these is the existence of a 512-byte trailer at the end of the file. This trailer is identifiable by a magic 32-bit value, 0x6B6F6C79, which is "koly" in ASCII. As other references to this trailer call it the "koly" block, we can do the same. Note, that "most" is not "all": images created with hdiutil(1), for example, can simply be raw dd(1)-like images of the disk layout, with no metadata. In those cases, however, there is nothing special or noteworthy about the file, which can be read as any disk would, by its partition table (commonly APM, or GPT). Images created with the DiscRecording.Framework contain the koly block. The koly block, when present, is formatted according to the following: The most important elements in the koly block are the fields pointing to the XML plist: This property list, embedded elsewhere in the DMG, contains the DMG block map table. Commonly, the plist is placed in the blocks leading up to the koly block, which fits the simple algorithm to create a DMG: First compress the image blocks, then place the XML plist, and finalize with the koly block. This is shown in figure 1: The Data Fork: Disk blocks, compressed in various ways ... XML property list (variable) koly trailer (512 bytes) This method of creating DMGs also explains why commands such as "file" have a hard time identifying the DMG file type: In the absence of a fixed header, a DMG can start with any type of data (disk or partition headers), which can be further compressed by myriad means. DMG files compressed with BZlib, for example, start with a BZ2 header. They cannot be opened with bunzip2, however, since compression methods are intermingled, and bunzip2 will discard blocks which do not start with a bz2 header. root@Erudite (/tmp) file DMG/install flash player osx.dmg DMG/install flash player osx.dmg: bzip2 compressed data, block size = 100k root@Erudite (/tmp) hdiutil imageinfo DMG/install flash player osx.dmg grep Format Format Description: UDIF read-only compressed (bzip2) Format: UDBZ DMGs compressed with zlib often incorrectly appear as "VAX COFF", due to the zlib header. root@Erudite (/tmp) file DMG/xcode46.dmg DMG/xcode46.dmg: VAX COFF executable not stripped - version 376 root@Erudite (/tmp) hdiutil imageinfo DMG/xcode46.dmg grep Format Format Description: UDIF read-only compressed (zlib) Format: UDZO The XML Property list (which is uncompressed and easily viewable by seeking to the DOCTYPE declaration using more(1) or using tail(1)) is technically the resource fork of the DMG. The property list file contains, at a minimum, a "blkx" key, though it may contain other key/values, most commonly "plst", and sometimes a service level agreement (SLA) which will be displayed by the OS (specifically, /System/Library/PrivateFrameworks/DiskImages.framework/Versions/A/Resources/DiskImages UI Agent.app/Contents/MacOS/DiskImages UI Agent) as a pre-requisite to attaching the DMG . Due to XML parser restrictions, data in the property list is 7-bit. This forces all binary (8-bit) data to be encoded using Base-64 encoding (a wiser choice would have been using CDATA blocks). The output of such a property list is shown below: In other words, for each entry, the chunk of SectorCount sectors, starting at SectorNumber are stored at CompressedLength bytes, at offset CompressedOffset in the data fork. When expanded, each such chunk will take SectorCount SECTOR SIZE bytes. Each chunk of blocks in a given entry is stored using the same compression, but different entries can contain different compression methods. Question: What are two advantages of breaking the image into block chunks, as described above? (Answer at end of document) Note in the example above the mix of Zlib and RAW compression methods: Z