Understanding dyld Cache Sliding: How ipsw Analyzes Slid vs Non-Slid Binaries

dyld cache sliding is the ASLR mechanism that randomizes the load address of the dyld shared cache by rebasing internal pointers per-page using slide-info metadata, and ipsw provides dedicated CLI and library functions to inspect these slid vs non-slid states.

The blacktop/ipsw open-source tool offers deep introspection into Apple’s dynamic linker (dyld) shared cache format. When analyzing iOS or macOS system libraries, understanding dyld cache sliding is essential for mapping raw disk images to runtime memory layouts.

What Is dyld Cache Sliding?

When iOS or macOS boots, the dyld shared cache (DSC)—a large read-only image containing most system libraries—is mapped into memory at a random address to implement Address Space Layout Randomization (ASLR).

This randomization is achieved by sliding the cache: every pointer referencing an address inside the cache is rebased by adding a slide offset. Rather than storing a single global offset, the DSC contains per-page metadata describing exactly which bytes require adjustment.

The Slide-Info Structure

The slide mechanism is encoded in a slide-info structure stored within the DSC itself. Key characteristics include:

• Per-page granularity: Each page in the cache may have its own chain of pointers requiring rebasing.
• Versioned formats: The slide-info format has evolved through versions 1–5, with each version encoding pointer chains differently (e.g., CacheSlideInfo5 uses 64-bit authenticated pointers).
• Read-only preservation: By storing rebase metadata separately, the cache remains read-only in memory while still supporting ASLR.

In pkg/dyld/types.go, the various slide-info structures are defined, including CacheSlideInfo, CacheSlideInfo2, and CacheSlideInfo5, along with pointer helpers like CacheSlidePointer5.

Slid vs Non-Slid Binaries

A non-slid binary represents the raw DSC as it exists on disk. In this state, internal pointer values reference the cache’s base address (typically 0x0 or a static link address). After the OS loads the cache and applies the slide-info metadata, the result is a slid binary where pointers point to actual randomized runtime addresses.

Analyzing the difference between these states is critical for:

• Reverse engineering system libraries
• Debugging runtime memory corruption
• Verifying kernel slide calculations
• Extracting accurate symbol addresses for security research

How ipsw Analyzes dyld Cache Sliding

The ipsw tool provides a dedicated dyld slide sub-command and supporting library functions to parse slide-info data and compare slid versus non-slid states.

Dumping Slide Tables

The DumpSlideInfo function in pkg/dyld/file.go provides a human-readable view of each page’s rebasing information. When you run the CLI command, it iterates through all mappings containing slide info and prints the raw slide tables, showing which offsets within each page require pointer adjustment.

# Human-readable dump of all slide entries in a DSC

ipsw dyld slide /path/to/dyld_shared_cache.arm64e

Exporting Rebase Information

For programmatic analysis, GetRebaseInfoForPages (also in pkg/dyld/file.go) extracts detailed rebase metadata and exports it as JSON Lines (JSONL). Each line represents a single rebase operation containing:

• CacheFileOffset: The offset within the cache file
• Target: The rebased target address
• Symbol: The resolved symbol name (if available)
• Original pointer value (in non-slid state)

# Export rebasing entries as JSONL

ipsw dyld slide /path/to/dyld_shared_cache.arm64e \
    --json --output ./slide-output

This creates slide-output/slide_info.jsonl, allowing you to diff slid vs non-slid pointer values or import the data into analysis tools.

Filtering Authenticated Pointers

Modern ARM64e caches use authenticated pointers (PAC). The ipsw CLI supports filtering for these via the --auth flag, implemented in cmd/ipsw/cmd/dyld/dyld_slide.go. When enabled, the tool only displays mappings where extMapping.Flags.IsAuthData() returns true, helping security researchers focus on signed pointer chains.

ipsw dyld slide /path/to/dyld_shared_cache.arm64e --auth --json

Working with Multiple DSCs

The dyld.Open function in pkg/dyld/file.go handles cache loading and automatically creates an address-to-symbol map from the cache’s symbol tables. This mapping is crucial for resolving pointer targets to human-readable names when analyzing slid binaries. The library supports split caches (multiple DSC files) and symlinks, ensuring you can analyze complex iOS/macOS system configurations.

Practical Examples

Analyzing Slide Info via CLI

To inspect the slide metadata of an iOS 17 shared cache:

# View human-readable slide tables

ipsw dyld slide iOS17_DSC/dyld_shared_cache_arm64e

# Export to JSON for further processing

ipsw dyld slide iOS17_DSC/dyld_shared_cache_arm64e \
    --json --output ./analysis

# Filter for authenticated pointers only

ipsw dyld slide iOS17_DSC/dyld_shared_cache_arm64e --auth

Programmatic Analysis with Go

For custom tooling, use the ipsw Go library to compare slid vs non-slid states:

package main

import (
    "fmt"
    "github.com/blacktop/ipsw/pkg/dyld"
)

func main() {
    // Open the DSC (creates address-to-symbol map)
    f, err := dyld.Open("/path/to/dyld_shared_cache.arm64e")
    if err != nil {
        panic(err)
    }
    defer f.Close()

    // Build symbol table for name resolution
    if err := f.ParseSymbolTable(); err != nil {
        panic(err)
    }

    // Iterate through mappings with slide info
    for uuid := range f.Mappings {
        for _, mapping := range f.MappingsWithSlideInfo[uuid] {
            // Extract all rebase entries (slid vs non-slid comparison)
            rebases, err := f.GetRebaseInfoForPages(uuid, mapping, 0, 0)
            if err != nil {
                panic(err)
            }
            
            fmt.Printf("Mapping %s: %d rebases found\n", mapping.Name, len(rebases))
            
            // Show first 5 rebases: file offset -> target address
            for i, r := range rebases {
                if i >= 5 {
                    break
                }
                fmt.Printf("  Offset %#x → Target %#x (Symbol: %s)\n", 
                    r.CacheFileOffset, r.Target, r.Symbol)
            }
            break
        }
        break
    }
}

This example uses dyld.Open, ParseSymbolTable, and GetRebaseInfoForPages from pkg/dyld/file.go to programmatically compare the non-slid file offsets with their slid runtime targets.

Summary

• dyld cache sliding implements ASLR by rebasing internal pointers when the shared cache loads at a random memory address.
• The slide-info structure (versions 1–5) stores per-page metadata describing which pointers require rebasing, allowing the cache to remain read-only.
• A non-slid binary contains pointers relative to the base address (disk state), while a slid binary contains runtime addresses after rebase.
• The ipsw tool provides the dyld slide command to dump slide tables, export JSONL rebase data, and filter authenticated pointers.
• Core implementation resides in pkg/dyld/file.go (DumpSlideInfo, GetRebaseInfoForPages) and cmd/ipsw/cmd/dyld/dyld_slide.go.

Frequently Asked Questions

What is the difference between a slid and non-slid dyld shared cache?

A non-slid dyld shared cache represents the file as stored on disk, where internal pointers reference the cache's static base address (typically 0x0). A slid cache is the in-memory version after the kernel applies the slide offset during loading; pointers now reference the actual randomized runtime addresses. The ipsw dyld slide command lets you inspect both states by showing the original file offsets and their corresponding slid targets.

How does ipsw extract rebase information from slide-info metadata?

ipsw parses the slide-info structures (versions 1–5) embedded in the DSC using the parseSlideInfo function in pkg/dyld/file.go. When you run ipsw dyld slide --json, the tool calls GetRebaseInfoForPages to iterate through each page's pointer chains, extracting the file offset, original pointer value, slid target address, and resolved symbol name. This data is exported as JSON Lines for programmatic analysis.

Can ipsw filter for authenticated pointers during slide analysis?

Yes. Modern ARM64e caches use authenticated pointers (PAC) for security. The ipsw dyld slide command supports the --auth flag, implemented in cmd/ipsw/cmd/dyld/dyld_slide.go. When enabled, the tool filters mappings to only those where extMapping.Flags.IsAuthData() returns true, allowing security researchers to focus exclusively on signed pointer chains within the slide metadata.

What Go functions does ipsw provide for programmatic slide analysis?

The ipsw Go library in pkg/dyld/file.go exposes several key functions for analyzing slid binaries:

• dyld.Open(): Loads the DSC and initializes the address-to-symbol map.
• ParseSymbolTable(): Builds the symbol resolution table needed for naming slid targets.
• DumpSlideInfo(): Prints human-readable slide tables for a given mapping.
• GetRebaseInfoForPages(): Extracts detailed rebase entries (file offset, target address, symbol) as structured data.

These functions allow developers to build custom tools that compare non-slid file offsets against their slid runtime addresses programmatically.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}