ASIF: Apple's New Sparse Disk Format

At WWDC 2025, Apple announced macOS 26 Tahoe, which includes a new disk image format: ASIF (Apple Sparse Image Format). Designed for virtual machines under the Virtualization framework, ASIF is a sparse virtual disk format similar to VMDK, VHDX, or QCOW2. It stores a large virtual disk in a smaller file by only allocating space for written blocks.

A developer at schamper.dev reverse-engineered ASIF before the macOS Tahoe release, documenting the process from hex dumps to binary analysis. Here's what they found.

Creating a Test File

Using Apple's command-line tools, they created a 1 GiB ASIF file and wrote a test pattern of numbered 1 MiB blocks:

$ diskutil image create blank --fs none --format ASIF --size 1GiB file
file.asif created
$ diskutil image attach -nomount file.asif
/dev/disk4
$ python3
>>> fh = open("/dev/disk4", "wb")
>>> for i in range(255):
...     fh.write(bytes([i] * 1024 * 1024))
>>> fh.close()

Hex Dump Analysis

Initial hex dumps revealed the magic bytes "shdw" at offset 0, followed by big-endian integers. Using dissect.cstruct, they parsed the header:

asif_def = """
struct header {
    char    magic[4];
    uint32  field4;
    uint32  field8;
    uint32  fieldC;
    uint64  field10;
    uint64  field18;
    char    field20[16];
    uint64  field30;
    uint64  field38;
    uint32  field40;
    uint32  field44;
    uint32  field48;
    uint32  field4C;
};
"""
c_asif = cstruct(asif_def, endian=">")

The parsed values showed two 0x200 values (sector size 512 bytes) and a virtual disk size of 0x1dcd65 sectors (≈1 GiB). Field10 and field18 pointed to offsets in the file.

Larger hex dumps revealed data at 0x200, 0x41400, and a "meta" section at 0x200000 followed by an XML plist.

Finding the Binary

Using grep on system frameworks:

$ grep -r "ASIF" /System/Library/Frameworks /System/Library/PrivateFrameworks
Binary file .../diskimagescontroller matches

The binary diskimagescontroller in DiskImages2.framework contained ASIF-related strings and mangled symbols. Running strings revealed:

Invalid value for asif header field: %s
Size cannot exceed max ASIF size
Unexpected ASIF header length
asif_header

Reverse Engineering with IDA

Loading the binary into IDA and following references to these strings led to a function that parses raw ASIF header bytes into an in-memory structure. The function checks fields with error messages like "ASIF max_write size in header exceed the limit" and "Sector count is too large".

From this, the developer reconstructed the full header structure:

struct asif_header {
    uint32  header_signature;   // "shdw"
    uint32  header_version;     // 1
    uint32  header_size;        // 0x200
    uint32  header_flags;       // 0
    uint64  directory_offsets[2]; // [0x200, 0x41400]
    char    guid[16];           // UUID
    uint64  sector_count;       // 0x1dcd65 (≈1 GiB)
    uint64  max_sector_count;   // 0x80000000000
    uint32  chunk_size;         // 0x100000 (1 MiB)
    uint16  block_size;         // 0x200 (512 bytes)
    uint16  total_segments;     // 0
    uint64  metadata_chunk;     // 0xffffffff
    char    unk_50[16];
    uint32  read_only_flags;
    uint32  metadata_flags;
    uint32  metadata_read_only_flags;
};

Key Findings

  • The magic is "shdw" (shadow), not "ASIF".
  • The header is 0x50 (80) bytes, but header_size is 0x200 (512 bytes), suggesting padding or extended fields.
  • directory_offsets contains two 64-bit offsets pointing to directory structures (likely segment descriptors).
  • chunk_size (1 MiB) and block_size (512 bytes) define the granularity of sparse allocation.
  • The metadata_chunk field (0xffffffff) indicates no metadata chunk is used in this example.

Why It Matters

ASIF is Apple's new sparse disk image format for VMs, competing with QCOW2 and VHDX. Understanding its structure is crucial for developers working with macOS virtualization, backup tools, or forensic analysis. The reverse engineering approach—hex dumps, binary analysis, and IDA—is a reusable methodology for any unknown binary format.

Next Steps

If you're working with ASIF, the documented header structure is a starting point. The next step is to parse the directory structures at directory_offsets to understand how blocks are mapped. The schamper.dev article includes further analysis of these structures. For now, you can use the provided C struct to read ASIF headers in your own tools.