DMG File Documentation

Summary

A DMG (Apple Disk Image) file is a mountable disk-image container that macOS uses to distribute software. It holds a complete filesystem — usually APFS or HFS+ — often compressed and sometimes AES-encrypted, in Apple’s UDIF format. Unusually, a DMG has no signature at the start: it is identified by a 512-byte koly trailer at the end of the file. Its MIME type is application/x-apple-diskimage. On a Mac you double-click to mount it; on Windows you can only extract or convert its contents.

Technical details

FeatureValue
Full nameApple Disk Image (UDIF)
File extension.dmg
MIME typeapplication/x-apple-diskimage
Format typeDisk-image container (mountable volume)
UDIF full nameUniversal Disk Image Format
DeveloperApple
Introduced2000s (Mac OS X), replacing older .img/NDIF
Embedded filesystemAPFS (modern) or HFS+ (historical)
CompressionOptional — zlib, bzip2, LZFSE, or LZMA per block
EncryptionOptional AES-128 / AES-256 (encrcdsa header)
Byte orderBig-endian (UDIF trailer fields)
Signature locationEnd of file, not the start
Magic number6B 6F 6C 79 (“koly”) at offset EOF−512
Trailer size512 bytes (the UDIF koly block)
Block mapXML property list (blkx) referenced by the trailer
Open standardNo — Apple proprietary
Related extensions.sparseimage, .sparsebundle, .img, .iso, .pkg
File signature (magic bytes)
6B 6F 6C 79

ASCII koly, the UDIF trailer magic. Unlike almost every other format, a modern DMG has no fixed signature at offset 0 — the bytes there depend on the embedded filesystem and compression. The identifying marker sits at the end of the file: the koly block is the last 512 bytes, so the magic is at offset EOF−512. Tools detect a DMG by seeking to 512 bytes before end-of-file and matching 6B 6F 6C 79. AES-encrypted images differ, starting with an encrcdsa header at offset 0 instead.

What is a DMG file?

DMG is short for Apple Disk Image, the disk-image format macOS uses to package and distribute software. A .dmg behaves like a virtual disk: when you open it on a Mac, the operating system mounts it as a volume that appears on the desktop, and you install the software by dragging its application onto the Applications folder. Apple introduced the format with Mac OS X in the early 2000s, replacing the older NDIF and .img images, and the modern flavour is called UDIF (Universal Disk Image Format). Its MIME type is application/x-apple-diskimage.

Internally a DMG is not just a file, it is an image of a whole filesystem — historically HFS+, now usually APFS — which is why one image can carry an application, a background picture for the drag-to-install window, an alias to /Applications, and a licence agreement, all at once. The image data can be split into compressed blocks and can be AES-encrypted. The rest of this article covers the piece that makes the format unusual: the koly trailer that lives at the end of the file and acts as its table of contents.

The koly trailer at the end of the file

Most binary formats put a magic number at offset 0. UDIF does the opposite. Because the start of a DMG is raw filesystem or compressed data whose first bytes vary, there is nothing constant to match at the front. Instead, the format is identified and described by a fixed 512-byte trailer in the last block of the file, called the koly block (or UDIF footer). A reader detects a DMG by seeking to 512 bytes before end-of-file and checking for the four-byte magic.

offset (in trailer)  field                     bytes
0x000  Signature      0x6B6F6C79 ('koly')          4
0x004  Version        UDIF version (1)             4
0x008  HeaderSize     512                          4
0x00C  Flags                                       4
0x010  RunningDataForkOffset                       8
0x018  DataForkOffset  (start of the data, 0)      8
0x020  DataForkLength                              8
0x028  RsrcForkOffset                              8
0x030  RsrcForkLength                              8
0x038  SegmentNumber / SegmentCount                8
0x040  SegmentID (UUID)                           16
0x058  DataChecksum (type, size, 128 x uint32)   136
0x0DC  XMLOffset      (offset of the plist)         8
0x0E4  XMLLength      (length of the plist)         8
       ... reserved / code-signature fields ...
0x1D8  MasterChecksum                            136
0x260  ImageVariant                                4
0x264  SectorCount                                 8

All multi-byte fields are big-endian. The two that matter most for parsing are XMLOffset and XMLLength at offsets 0xDC and 0xE4: they point to an embedded XML property list stored in the bytes just before the trailer. DataForkOffset and DataForkLength bound the actual image payload, and SectorCount gives the size of the decompressed volume in 512-byte sectors. Two checksum fields (a data checksum and a master checksum) let Disk Utility verify the image, which is what the “verifying…” step does before a DMG mounts.

The XML plist and the blkx block map

The property list that XMLOffset points to is the image’s block map. It is a standard Apple plist containing a resource-fork dictionary, and inside it an array of blkx entries, one per partition or region of the disk image. Each blkx entry is a base64-encoded binary table that describes how to reconstruct that region: a list of chunks, where each chunk records its type, the sector range it covers in the output, and the byte range it occupies in the compressed data fork.

each blkx chunk:
  EntryType   0x00000001 = raw (uncompressed)
              0x80000004 = Apple ADC
              0x80000005 = zlib / DEFLATE
              0x80000006 = bzip2
              0x80000007 = LZFSE
              0x80000008 = LZMA
              0x00000002 = ignore / zero-fill
              0xFFFFFFFF = terminator (last chunk)
  SectorStart, SectorCount   where it lands in the volume
  CompressedOffset, CompressedLength   where it lives in the file

This is what makes a DMG both compressible and randomly mountable. A mounting driver reads the block map, and when the volume asks for a given sector it looks up the chunk covering that sector, seeks to the chunk’s CompressedOffset in the data fork, decompresses just that chunk with the codec named by EntryType, and returns the requested sectors. Because the map is chunk-granular, macOS never has to decompress the whole image to read one file. Zero-filled regions are stored as ignore chunks with no data at all, so an image of a mostly-empty volume stays small.

UDZO, UDBZ and the hdiutil image types

Which codec a DMG uses is chosen at creation time and reflected in the chunk types above. The common hdiutil image formats map directly onto them: UDZO is zlib-compressed, UDBZ is bzip2, ULFO is LZFSE (fast on Apple silicon), and ULMO is LZMA (smallest, slowest). A read/write image (UDRW) or a raw read-only image (UDRO) stores its blocks uncompressed. Sparse images (.sparseimage) and sparse bundles (.sparsebundle) are related Apple formats that grow on demand rather than fixing their size up front; a sparse bundle stores the volume as many small band files inside a directory, which is why Time Machine over a network uses it. Converting between these types is exactly what hdiutil convert does: it rewrites the block map and re-compresses chunks, producing a new koly trailer.

Encrypted DMGs and the encrcdsa header

An encrypted DMG is the one case where the file does have a recognisable header at offset 0. Apple’s encrypted disk-image wrapper begins with the ASCII string encrcdsa, followed by a header that stores the cipher (AES-128 or AES-256), the key-derivation parameters, and the wrapped keys. The underlying UDIF image, with its koly trailer and blkx map, sits inside this encrypted envelope: you cannot read the block map until the password unlocks the keys. This is why an AES DMG will not extract in a generic archiver — the tool sees the encrcdsa wrapper, not a koly trailer, and has no key to decrypt the payload.

Why a DMG cannot run its app on Windows

A DMG is a container, and the software inside it is compiled for macOS. On Windows or Linux you can open the container — 7-Zip and PeaZip can extract the files, and dmg2img converts a UDIF image to a raw .img or ISO that other tools mount — but the .app bundle you extract is a Mach-O macOS program and will not install or launch on Windows. Converting the DMG to an ISO changes the container, not the operating system the code targets, so “convert DMG to EXE” is not a real operation; the fix is to download the software’s native Windows build. Extraction on Windows is low-risk precisely because the Mac binary cannot execute there. The closest cross-platform analogue is a plain ISO 9660 image, which is why the ISO conversion is the one that genuinely works.

Frequently asked questions

Why is the DMG signature at the end of the file?

Because the front of a UDIF image is raw filesystem or compressed block data with no constant first bytes, there is nothing fixed to match at offset 0. Putting the 512-byte koly trailer at the end lets a tool append the index after writing the (possibly streamed) image data, and readers simply seek to EOF−512 to find it.

What is the “verifying” step when a DMG mounts?

The koly trailer stores a data checksum and a master checksum over the image blocks. Disk Utility recomputes them and compares before mounting, which catches an incomplete or corrupted download. A DMG that reports “image not recognized” usually failed this check because the file is truncated — re-download it.

References