Apple Disk Image
The Apple Disk Image, commonly identified by the file extension .dmg, is a proprietary disk image file format developed by Apple Inc. for macOS and other Apple operating systems. It encapsulates the full contents, file system structure, and metadata of a physical or virtual disk or folder, enabling it to be mounted directly in Finder as a read-write or read-only volume, similar to inserting a physical disk.[1][2] Created and managed primarily through the built-in Disk Utility application on Mac, Apple Disk Images support a range of internal formats, including APFS (Apple File System) for modern macOS volumes, HFS+ (Hierarchical File System Plus) for legacy compatibility, MS-DOS (FAT) for cross-platform use with Windows, and ExFAT for larger volumes exceeding 32 GB.[3] They can be configured as sparse images that dynamically expand to accommodate added data, compressed variants for efficient storage and transfer (such as UDZO, a read-only zip-compressed format), or encrypted options to secure sensitive information using 128-bit or 256-bit AES encryption.[3][4] These images play a central role in software distribution on Apple platforms, particularly for packaging applications outside the Mac App Store, where they can be digitally signed with a Developer ID to verify integrity and prevent tampering.[4] Developers often customize .dmg files with visual elements like backgrounds, arranged icons, and symbolic links to the Applications folder to streamline user installation. Beyond distribution, they facilitate data backups (e.g., via Time Machine with sparse bundle images), creation of bootable installers for macOS recovery, and production of physical media like CDs or DVDs by burning the image directly.[3][2] To access contents, users simply double-click the .dmg file, which mounts it on the desktop or in a Finder sidebar for browsing and interaction, and it can be ejected when no longer needed.[1]Introduction
Definition and Purpose
An Apple Disk Image, commonly known by its primary file extension .dmg, is a file-based disk image format developed by Apple Inc. for use on macOS and other Apple platforms. It encapsulates the contents of a virtual disk, partition, or logical volume, allowing the image to be mounted directly in the macOS Finder as if it were a physical disk or optical media. This format emulates hardware storage devices, such as hard drives or DVDs, enabling seamless access to the contained files and folders without requiring additional hardware.[5][3] The primary purposes of Apple Disk Images include software distribution, where they serve as containers for application installers and updates, facilitating easy download and installation over the internet. They are also widely used for data backups and archival, preserving entire filesystems or selected folders in a single, portable file that supports compression and encryption for security. Additionally, these images support the creation of bootable media, such as installers for macOS or recovery volumes, allowing users to replicate and restore system environments efficiently. The format's MIME type is application/x-apple-diskimage, which identifies it for proper handling in web browsers and file transfer protocols.[3][6] Apple Disk Images were specifically developed to overcome limitations in earlier disk image formats, particularly in preserving the resource forks of Macintosh files during transfers across mixed networks or the internet, where such metadata could otherwise be lost or corrupted. Resource forks, which store structured data like icons and application resources separate from the main data fork, were integral to classic Mac OS compatibility, and the .dmg format embeds this information reliably within a unified structure.[7]Compatibility and File Systems
Apple Disk Images, commonly known as DMG files, exhibit native compatibility with macOS starting from version 10.0 (Cheetah), where basic disk image mounting is supported through tools like Disk Copy. The Universal Disk Image Format (UDIF), the primary structure underlying most DMG files, was introduced in macOS 10.0 (Cheetah). Advanced features such as sparse images and encryption were added in macOS 10.1 (Puma), with zlib compression introduced in 10.2 (Jaguar).[8] On iOS and iPadOS, compatibility is limited to extraction via the Files app or third-party applications, without native mounting akin to macOS, as these platforms lack Disk Utility and full hdiutil equivalents. For non-Apple operating systems, partial support exists on Windows and Linux through third-party tools; for instance, 7-Zip or HFSExplorer on Windows allows extraction of contents, while dmg2img on Linux converts DMG files to mountable IMG formats.[9][10] Regarding hardware compatibility, DMG files are fully supported on both Intel-based and Apple Silicon Macs, as the format operates at the file system and tool level rather than being architecture-specific.[3] Backward compatibility extends to older PowerPC systems running macOS up to 10.5 Leopard (or 10.6 Snow Leopard in PowerPC mode), where earlier disk image formats like NDIF and basic UDIF can be mounted, though modern UDIF images created on later systems may require flattening for recognition on these platforms.[8][11] DMG files support a variety of file systems to ensure interoperability, including Hierarchical File System (HFS), HFS Plus (HFS+), Apple File System (APFS, introduced in macOS 10.13 High Sierra), MS-DOS FAT, and ExFAT for cross-platform use.[12] Additionally, they accommodate optical media formats such as ISO 9660 and Universal Disk Format (UDF) for hybrid CDs/DVDs, allowing raw disk images from other operating systems to be attached and read.[8] APFS integration within DMG files, available since macOS High Sierra, enables advanced features like snapshots—read-only point-in-time copies of volumes—and encryption at the container level, where multiple volumes share a single encrypted wrapper for efficient key management.[13][14] This container-level approach in APFS-based DMGs supports formats such as APFS (Encrypted) or APFS (Case-sensitive, Encrypted), enhancing security without hardware-specific dependencies.[12] As of macOS 26 Tahoe (released in 2025), Apple introduced the Apple Sparse Image Format (ASIF), a new disk image format optimized for near-native speeds in encrypted volumes, complementing UDIF-based .dmg files.[15]Historical Development
Early Formats and Motivations
The development of early Apple disk image formats was primarily driven by the need to preserve the integrity of Macintosh files during transfer and storage, particularly due to the classic Mac OS file system's dual-fork structure consisting of a data fork and a resource fork. The resource fork contained critical elements like icons, menus, and code resources, but common archiving tools such as ZIP or TAR often fragmented or discarded it when transferring files over networks or the internet, leading to incomplete or non-functional applications. Disk images addressed this by bundling both forks into a single, mountable file that emulated a physical disk, enabling reliable distribution of software and emulation of legacy floppy disks for running older programs on newer hardware.[16][7] The earliest prominent format, Disk Copy 4.2 (often abbreviated as DC42), emerged in the late 1980s as part of Apple's Disk Copy utility, which was included starting with System 6 in 1988. This format targeted the replication of 400K and 800K single- and double-sided floppy disks, using extensions like .dc or .sit for compressed variants created with third-party tools such as StuffIt. It allowed users to create exact bit-for-bit copies of floppies for backup and distribution, solving the challenge of physically duplicating media in an era when floppy disks were the primary storage medium for software installation. However, Disk Copy 4.2 was inherently limited to floppy-sized images (typically 400 KB to 800 KB), lacked built-in compression or encryption, and did not robustly support resource forks in a unified manner, making it prone to corruption during cross-platform transfers.[17][18][19] To overcome these shortcomings, Apple introduced the New Disk Image Format (NDIF) around 1999 with the release of Mac OS 9 and Disk Copy 6.0. NDIF files, typically using .img or .smi extensions, were designed as self-mounting images that natively preserved resource forks, supported zlib compression for smaller file sizes, and allowed for read-only variants suitable for software distribution. This format formalized the disk image as a versatile tool for internet-based file sharing, addressing the growing demand for efficient Mac-specific archiving as online connectivity expanded. Despite these advances, NDIF suffered from limited cross-platform compatibility, as it relied on Macintosh-specific mounting mechanisms that failed on non-Apple systems, and it lacked integrated encryption, leaving files vulnerable to tampering. These constraints highlighted the need for a more universal successor.[19][7][18]Introduction and Evolution of UDIF
The Universal Disk Image Format (UDIF), commonly associated with the .dmg file extension, was introduced by Apple in Mac OS X 10.1 Puma in 2001 as the successor to the New Disk Image Format (NDIF), addressing limitations in cross-platform compatibility and resource fork handling for disk images.[7][16] UDIF standardized the .dmg extension for macOS-native disk images, enabling a single-file structure that encapsulates raw block data, partition maps, and metadata without relying on dual forks, which facilitated easier distribution over the internet and support for compression from the outset using Apple's proprietary ADC method.[7][20] This format quickly became central to software installation and archival tasks in macOS, allowing images to emulate physical disks or optical media while integrating seamlessly with the operating system's kernel extensions for mounting.[21] A key milestone occurred in Mac OS X 10.2.3 in 2003, when Apple introduced compressed and Internet-Enabled .dmg files, incorporating XML-based metadata plists for block mapping and checksum verification to ensure data integrity during downloads.[22][20] The Internet-Enabled feature, enabled via the hdiutil command, automates post-download verification and extraction, prompting users to mount or copy contents while discarding the image to save space, a capability that enhanced secure software distribution by validating checksums against embedded XML data.[21] Subsequent enhancements included bzip2 compression support in Mac OS X 10.4 Tiger (2005), offering better ratios for larger images; LZFSE compression in OS X 10.11 El Capitan (2015) for faster decompression on modern hardware; LZMA in macOS 10.15 Catalina (2019) for superior compression efficiency; and APFS container support in macOS 10.13 High Sierra (2017), allowing disk images to leverage the Apple File System's snapshot and cloning features.[21][7] UDIF's evolution reflects macOS's shift toward enhanced security and efficiency, including a transition to big-endian metadata encoding in its trailer structures to maintain compatibility with PowerPC architectures during the Intel transition.[20] Post-2012, integration with Gatekeeper in OS X 10.8 Mountain Lion and later notarization requirements in macOS 10.14 Mojave enabled .dmg files to carry developer signatures and undergo automated Apple scans for malware, streamlining verified app distribution while blocking unsigned images.[23] By 2025, UDIF saw no fundamental structural changes, though macOS Sonoma (14.x, 2023) and Ventura (13.x, 2022–2024) incorporated enhanced safety checks in the Disk Images framework to mitigate sandbox escapes and privilege escalations during mounting or verification.[24][25] In June 2025, macOS Tahoe introduced the Apple Sparse Image Format (ASIF) as a new complementary disk image format optimized for high-performance scenarios like virtual machines, achieving near-native speeds while coexisting with UDIF.[15] These updates addressed vulnerabilities like arbitrary code execution in hdiutil, reinforcing UDIF's role in secure, containerized storage without altering its core block-based design.[26]File Format Specifications
Overall Structure
The Universal Disk Image Format (UDIF) functions as a container for raw disk data blocks, enabling the representation of virtual disks in a single-file format suitable for macOS. This core structure allows for optional encoding layers, such as CUDIFEncoding for compression and CEncryptedEncoding for security, which wrap the underlying block data to enhance portability and protection without altering the logical disk layout.[20][8] Key components of the UDIF include header and trailer sections that define the file's boundaries and attributes, the primary block data area consisting of UDIF blocks that mirror the physical disk sectors, and provisions for emulating resource forks through integrated metadata structures. These elements ensure the image can be mounted as a volume while preserving compatibility with legacy Macintosh file system features. The block size is standardized at 512 bytes, aligning with traditional sector sizes for efficient mapping to storage devices.[20][27][28] The format also accommodates sparse images, which allocate storage only for used blocks, thereby optimizing space for volumes with significant unused areas. Additionally, hybrid modes facilitate CD/DVD emulation by layering ISO and UDF file systems over the UDIF container, allowing cross-platform readability for optical media simulations.[20][3]Metadata and Resource Forks
Apple Disk Images in the Universal Disk Image Format (UDIF) incorporate metadata embedded as an XML property list at the end of the file, with its offset and length specified in the UDIF resource file structure via fields such asfUDIFXMLOffset and fUDIFXMLLength.[20][29] This plist is accessed through the kUDIFResourceFileKey, which points to block index data under the blkx key, allowing for detailed file system information without external dependencies.[20][30] The metadata's placement in the file trailer integrates it with the broader UDIF architecture, ensuring self-contained image integrity.[20]
A key role of this metadata is the emulation of resource forks for legacy Hierarchical File System (HFS) and HFS+ volumes, where non-fork data—such as resource streams traditionally stored separately—is preserved within the plist to prevent file splitting during transmission or archiving.[20][29] This approach maintains compatibility with older Macintosh file structures while adapting to modern single-fork environments, avoiding the need for auxiliary files like those in the deprecated NDIF format.[30]
The XML plist contains essential elements including CRC32 checksums for data verification (via keys like DataChecksum and fUDIFDataForkChecksum), partition maps (such as Apple Partition Map or GUID Partition Table details), and volume headers that describe the image's block layout and file system parameters.[20][29] Due to the absence of official Apple documentation, these components have been reverse-engineered through disassembly of private frameworks like DiskImages.framework and analysis of sample images.[20][29]
The size of the metadata plist is variable, typically ranging up to several kilobytes depending on the complexity of the image, and it has supported Unicode paths for international file names along with extended attributes since macOS 10.4 (Tiger).[20][30] This evolution enhances the format's robustness for diverse file systems and global use cases.[29]
Compression Methods
The compression layer in Apple Disk Images is applied through the CUDIFEncoding mechanism within the Universal Disk Image Format (UDIF), which enables efficient reduction of file sizes to facilitate distribution and storage.[8] This encoding wraps the underlying data blocks, allowing for selective compression while preserving the overall disk image structure.[31] Several algorithms are supported for compressing UDIF-based disk images, each introduced at different points in macOS evolution to balance compression ratios, speed, and compatibility. The early Apple Data Compression (ADC) algorithm, used in the UDCO format, was deprecated in favor of more standard options but provided asymmetric compression optimized for rapid decompression in read-only scenarios.[8] Zlib, employing the DEFLATE method in the UDZO format, became the default since macOS 10.3 and remains widely used for its cross-platform compatibility and adjustable levels, typically set to level 6 for a balance of size and performance in disk images.[8] Bzip2, via the UDBZ format introduced in macOS 10.4, offers higher compression ratios at the cost of slower processing and is now considered deprecated.[8] Later enhancements include LZFSE in the ULFO format, added in macOS 10.11 for faster decompression speeds suitable for modern hardware, and LZMA in the ULMO format, introduced in macOS 10.15 to achieve superior compression ratios for large files.[8] LZFSE and LZMA are part of Apple's Compression framework, prioritizing efficiency on Apple silicon and Intel architectures without tying to specific file systems.[32] Implementation occurs on a per-block basis within the UDIF structure, where compressible blocks are encoded individually to minimize overhead, while sparse writable images (such as those in UDSB format) forgo compression to support dynamic resizing.[8] Hybrid approaches may combine compressed and uncompressed segments for integrity verification during mounting. Compression ratios vary by content; for instance, text-heavy files often achieve approximately 2:1 reduction with zlib or LZMA, establishing key efficiency for software distribution.[8]Encryption Protocols
Apple Disk Images support two primary encryption standards: 128-bit AES, which is considered legacy and offers faster performance due to its smaller key size, and 256-bit AES, which provides enhanced security against brute-force attacks and has been the recommended option in Disk Utility since macOS 10.7 Lion.[33][34] These ciphers operate in CBC mode and can be applied via password-based authentication, where a user passphrase derives the encryption key, or certificate-based methods, which utilize an RSA private key for decryption in advanced configurations.[35][36] The encryption protocols evolved through two main versions to address security and compatibility needs. Version 1 (v1), used in images prior to macOS 10.5 Leopard, employs trailer encryption, where the encryption header (identified by the 'cdsaencr' tag) is located at the end of the file, wrapping the data in a single passphrase-derived key without support for modern file systems like APFS.[35] In contrast, version 2 (v2), introduced with macOS 10.5 Leopard and standard in subsequent releases, features header encryption with the 'encrcdsa' tag at the file's beginning, enabling compatibility with APFS volumes and accommodating multiple key types, including keybags for institutional recovery.[35][5] At the core of these protocols is the CEncryptedEncoding layer, which encapsulates the compressed or raw data blocks (often in UDIF format) to provide confidentiality, wrapping them after any compression layer in the overall disk image architecture.[5] Key derivation for v2 encryption relies on PBKDF2 (Password-Based Key Derivation Function 2) with HMAC-SHA-1, using a salt and a high iteration count—typically 250,000 rounds for 256-bit AES—to generate a DES key that unwraps the primary AES and HMAC keys, mitigating dictionary attacks.[35][37] Initialization vectors for block encryption are derived via HMAC-SHA1 using the block number, though reverse-engineering efforts have highlighted ambiguities in blkx (block index) positioning relative to encrypted boundaries, potentially complicating forensic analysis.[35] Encrypted disk images mounted in read-only mode exhibit faster mounting times compared to read-write configurations, as they avoid the overhead of on-the-fly re-encryption for modifications, making them suitable for distribution or archival purposes.[38] Additionally, v2 encryption integrates with FileVault's key management for system recovery images, allowing derived keys from the full-disk encryption setup to unlock protected DMGs during boot or restoration processes.[39]Features and Capabilities
Mounting and Verification
Apple Disk Images, commonly known as .dmg files, can be mounted on macOS systems through user-friendly graphical interfaces or command-line tools. In the Finder, users mount a disk image by double-clicking the .dmg file, which triggers the Disk Image Mounter to attach it as a virtual disk visible under /Volumes.[3][8] This process presents the image's contents as a removable volume, complete with an eject option in the Finder sidebar for safe detachment. Alternatively, the hdiutil command-line utility facilitates mounting via the attach verb, such ashdiutil attach image.dmg, which similarly exposes the image as a mounted volume and supports options like specifying mount points or suppressing automatic filesystem mounting.[8][40]
Verification of Apple Disk Images ensures data integrity, particularly for files downloaded from the internet. Internet-enabled disk images, prepared using hdiutil internet-enable, automatically perform checksum validation upon mounting post-download, typically employing SHA-1 or other supported algorithms like MD5 or CRC32 stored in the image's metadata.[8] If the verification fails due to corruption or alteration, macOS quarantines the image and may display a warning prompt, preventing automatic mounting to protect system security.[41] Users can manually verify images using hdiutil verify image.dmg, which checks against embedded checksums without mounting.[8] This process briefly references checksum details embedded in the image's metadata for integrity assessment.[42]
By default, mounted Apple Disk Images operate in read-only mode to preserve the original data structure, appearing as non-writable volumes unless specified otherwise.[8] For editing capabilities, users can mount in read-write mode using hdiutil attach -readwrite image.dmg or employ shadow files for non-destructive modifications on read-only images.[8] Sparse image variants, such as UDSP (single-file sparse) or UDSB (sparse bundle), support dynamic sizing during write operations, allowing volumes to grow as needed up to predefined limits like 128 PB for UDSP.[8] Additionally, disk images support multi-partition configurations, enabling multiple filesystems within a single .dmg, which mount as separate volumes.[43] Hybrid formats facilitate optical media burning; for instance, HFS+/ISO hybrid images created via hdiutil makehybrid can be burned to CDs or DVDs using hdiutil burn or Disk Utility, ensuring cross-platform readability.[8] In modern macOS, mounting relies on the DiskImages framework and associated kernel extensions for low-level device attachment, akin to FUSE mechanisms in user-space filesystem handling.[44]
In macOS 26 Tahoe (released September 15, 2025), Apple introduced the Apple Sparse Image Format (ASIF), a new sparse disk image type that offers significantly faster write performance—up to 1,000% faster than traditional sparseimages—while maintaining dynamic allocation for efficient storage. ASIF images start small and expand as needed, similar to UDSP and UDSB, but with improved handling for large volumes and multiple partitions.[15]
Security and Distribution Enhancements
Apple Disk Images (DMGs) incorporate code signing and notarization as key security enhancements, introduced with macOS 10.14 Mojave, to verify the developer's identity and ensure the integrity of the image contents. Code signing uses digital certificates issued by Apple to authenticate the software developer, while notarization involves submitting the DMG to Apple for automated analysis to detect malware or vulnerabilities before distribution. These processes confirm that the DMG has not been tampered with since signing, providing users with assurance when installing applications.[45][46] macOS Gatekeeper further enforces these protections by blocking the execution of unsigned DMGs or those from unidentified developers, preventing potential malware from running without user intervention. In macOS 15.1 Sequoia and later, Gatekeeper has been strengthened by removing the right-click "Open" bypass option for unsigned applications, requiring users to employ Terminal commands (such as removing quarantine attributes) or disable System Integrity Protection to override these checks. This layered approach ensures that only verified DMGs can be mounted and their contents accessed seamlessly.[47][48] For software distribution, DMGs are the preferred format for bundling macOS applications due to their support for tamper-evident checksums, which allow users to verify the image's integrity against published hashes before installation. This is particularly valuable for app bundles, as it detects any alterations during download or transit, reducing the risk of corrupted or malicious payloads. Additionally, sparse disk images enable efficient incremental updates by dynamically allocating space only for new or modified data, minimizing file sizes and bandwidth for software patches without requiring full image recreation.[49][50] Modern macOS integrations extend these safeguards through quarantine attributes applied to downloaded DMGs, which flag files from the internet and prompt Gatekeeper warnings upon mounting to mitigate risks from untrusted sources.[51][52] In the macOS Sequoia 15.7.2 security update (released November 3, 2025), Apple addressed vulnerabilities including code-signing downgrade issues and a sandbox escape in disk images, enhancing overall integrity checks for DMGs.[53]Associated Utilities
Native macOS Tools
Disk Utility serves as the primary graphical user interface for managing Apple Disk Images on macOS, enabling users to create, convert, format, encrypt, and burn these images directly from the application found in /Applications/Utilities/. To create a new blank disk image, users select File > New Image > Blank Image, where they can specify the image name, size, file system format—such as APFS for volumes on macOS 10.13 and later or Mac OS Extended (HFS+) for compatibility—and encryption options including 128-bit or 256-bit AES.[3] Additional creation methods include imaging from a selected disk or device via File > New Image > Image from [device name], which supports read-only, compressed, or raw formats, or from a folder using File > New Image > Image from Folder for read-only or hybrid images.[3] For conversion, Disk Utility allows selecting Images > Convert to transform an existing image to formats like read-only (UDRO), read/write sparse bundle (UDSB), or DVD/CD master, with optional encryption applied during the process.[54] Burning capabilities integrate with the Finder to produce optical media from master images, supporting APFS and HFS+ volumes for distribution.[3] Thehdiutil command-line tool provides a programmatic interface to the DiskImages framework for attaching, detaching, creating, verifying, and converting Apple Disk Images, offering greater flexibility for automation and scripting on macOS.[55] For instance, creating a compressed and encrypted image from a source folder uses the command hdiutil create -srcfolder <source> -format UDZO -encryption AES-256 -o <output.dmg>, where UDZO specifies zlib compression and AES-256 provides strong encryption requiring a password.[8][4] Attachment and detachment are handled via hdiutil attach <image.dmg> to mount the image and hdiutil detach <mountpoint> to unmount it, with options like -stdinpass for password input in scripts.[8] Verification ensures image integrity using hdiutil verify <image.dmg>, while conversion employs hdiutil convert <input> -format <newformat> -o <output>, supporting formats such as UDRO for read-only or UDSB for sparse bundles.[8] The tool supports scripting through the -plist option, which outputs results in property list format for integration into automation workflows, and features like hdiutil internet-enable <image> to optimize images for web downloads by enabling post-processing.[8][4]
Disk Copy, a legacy utility predating macOS 10.3 (Panther), handled basic creation and management of disk images in earlier versions of Mac OS X and Classic Mac OS, but it was superseded by Disk Utility for more advanced features.[3] Images produced with Disk Copy remain mountable on modern macOS systems via Disk Utility or hdiutil attach, preserving compatibility for archival purposes despite the tool's obsolescence.[3]