Skip to content
Tech News
← Back to articles

Dissecting Apple's Sparse Image Format (ASIF)

read original more articles
Why This Matters

Apple's introduction of the new ASIF format in macOS 26 Tahoe signifies a strategic move to optimize virtual disk storage, aligning with industry standards for sparse virtual disks. This development impacts both developers and consumers by enabling more efficient virtual machine management and storage solutions, potentially influencing future virtualization technologies. The detailed reverse engineering process also offers valuable insights for the tech community interested in file format analysis and virtualization innovations.

Key Takeaways

Dissecting Apple's Sparse Image Format (ASIF)

At WWDC 2025, Apple announced macOS 26 Tahoe. One of the new features in macOS Tahoe is a new disk image format: ASIF. Designed for use with virtual machines (its documentation lives under the Virtualization framework), ASIF takes a lot of inspiration from existing virtual disk formats. Practically, that means it’s another sparse virtual disk format, and functions very similar to sparse VMDK, VHDX or QCOW2 files (for the uninitiated, it allow you to store a large disk, or file, in a smaller, “sparse” manner).

Shortly before the release of macOS Tahoe (late 2025), I thought it’d be a fun exercise to try and write a parser for ASIF files. It’s been a while since then, but I wanted to go back and show my process on how I approach these kinds of problems. Maybe someone unfamiliar with reverse engineering file formats can pick up a thing or two. For that reason, you can find the occasional “Research note” sprinkled throughout this post with some additional insights.

Let’s create a test file with the command listed in the Apple documentation, write a test pattern to it and get started:

Research note For testing purposes, I usually like to write a test pattern that allows me to verify the content matches the “offset”. In this case, basically just numbered 1 MiB blocks of bytes. There are definitely better test patterns, but for an initial peek at the file format, it’s also important to just fill up the file with anything. Having a predictable and verifiable pattern can make later steps easier.

❯ diskutil image create blank --fs none --format ASIF --size 1GiB file file.asif created ❯ diskutil image attach -nomount file.asif /dev/disk4 ❯ python3 Python 3.14.0 (main, Oct 7 2025, 09:34:52) [Clang 17.0.0 (clang-1700.3.19.1)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> fh = open("/dev/disk4", "wb") >>> for i in range(255): ... fh.write(bytes([i] * 1024 * 1024)) >>> fh.close() ❯ hdiutil detach disk4 "disk4" ejected.

Eyeball hexdumps

As usual, we start by eyeballing some hexdumps to see if we can discern some details.

❯ xxd file.asif | head -5 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0000 0000 73 68 64 77 00 00 00 01 00 00 02 00 00 00 00 00 s h d w · · · · · · · · · · · · 0000 0010 00 00 00 00 00 00 02 00 00 00 00 00 00 04 14 00 · · · · · · · · · · · · · · · · 0000 0020 8a f9 ea d2 cf 38 49 c0 8e ec 00 95 cf 5c 78 99 · · · · · 8 I · · · · · · \ x · 0000 0030 00 00 00 00 00 1d cd 65 00 00 08 00 00 00 00 00 · · · · · · · e · · · · · · · · 0000 0040 00 10 00 00 02 00 00 00 00 00 00 00 ff ff ff ff · · · · · · · · · · · · · · · ·

We can immediately spot some kind of file magic, followed by some big endian looking integers.

... continue reading