How to Dump Objective-C and Swift Classes from dyld_shared_cache Using ipsw

The ipsw command-line tool extracts Objective-C runtime information and Swift metadata from Apple's dyld_shared_cache by parsing optimized hash tables and runtime structures, exposing class hierarchies, protocols, and selectors without requiring original binaries.

The blacktop/ipsw repository provides a specialized Go-based toolkit for analyzing Apple firmware and runtime binaries. When you need to dump Objective-C and Swift classes from dyld_shared_cache using ipsw, the tool leverages dedicated parsers in pkg/dyld to traverse optimized string hash tables and Swift metadata headers, reconstructing human-readable class definitions directly from the shared cache format.

Understanding the dyld_shared_cache Architecture

Apple's dyld_shared_cache (DSC) is a single file that consolidates system libraries to improve launch times and memory usage. The ipsw tool abstracts this complex format through pkg/dyld.File, which handles cache offset translation and VM address resolution via methods like GetOffset and GetCacheVMAddress. This foundation enables both Objective-C and Swift extraction pipelines to read raw bytes from the correct backing images.

Dumping Objective-C Classes

The Objective-C class dumping pipeline parses optimized string hash tables stored within the DSC to map VM addresses to selector, class, protocol, and category names.

How the ObjC Pipeline Works

In pkg/dyld/objc.go, the ParseAllObjc function orchestrates the extraction by performing three critical steps:

1. Load String Hash Tables: The code reads optimized StringHash structures using getSelectorStringHash and dumpOffsets to build maps of selectors, classes, and protocols.
2. Walk Class Lists: For each image, the parser examines __DATA.__objc_classlist (or the shared cache variant) to resolve class pointers into human-readable symbols.
3. Populate Symbols: Resolved names are injected into File.AddressToSymbol, enabling symbolic references in subsequent disassembly.

Key functions include GetAllObjCClasses, GetAllObjCSelectors, and GetAllObjCProtocols, which return comprehensive maps of runtime entities.

Command Examples

Use the hidden objc subcommand to inspect a specific class:

# Dump Objective-C class details (methods, properties, ivars)

$ ipsw objc NSFileManager
/usr/lib/libobjc.A.dylib
    NSFileManager
@methods
void createDirectoryAtPath:attributes:
...
@properties
NSString * currentDirectoryPath
...

For bulk extraction of all ObjC metadata from a DSC, the tool processes the entire cache automatically when using the swift-dump command with appropriate flags, though the ObjC-specific logic primarily serves symbol resolution for disassembly and analysis workflows.

Dumping Swift Classes and Metadata

Swift metadata extraction requires parsing the Swift optimization header and associated hash tables that store type descriptors, protocol descriptors, and foreign type references.

Swift Optimization Header and Hash Tables

In pkg/dyld/swift.go, the SwiftOptimizationHeader structure defines the layout of metadata tables. The SwiftHashTable type provides access to type and protocol entries. When processing a DSC, ipsw locates these structures to enumerate all Swift types efficiently.

Core Implementation Files

The primary implementation resides in internal/commands/macho/swift.go. The Swift struct encapsulates the dumping logic with methods including:

• DumpType: Extracts struct, class, and enum metadata
• DumpProtocol: Parses protocol descriptors and requirements
• DumpExtension: Handles extension definitions
• Dump: Main entry point for comprehensive extraction
• WriteHeaders: Generates Swift interface files when using --headers or --interface flags

Command Examples with Filters

Dump all Swift types from a shared cache:

# Dump every Swift type, protocol, and extension

$ ipsw swift-dump /usr/lib/swift/dyld_shared_cache_arm64e.dsc

Filter for specific protocols with demangling enabled:

# Dump UIKit protocols with readable names

$ ipsw swift-dump /usr/lib/swift/dyld_shared_cache_arm64e.dsc \
    --proto '^UIKit\.' --demangle

Extract metadata from a specific framework within the DSC:

# Target a private framework inside the shared cache

$ ipsw swift-dump /usr/lib/swift/dyld_shared_cache_arm64e.dsc \
    PrivateFrameworks/MyFramework.framework/MyFramework \
    --type 'MyClass' --demangle

Generating Swift Interface Files

Beyond terminal output, ipsw can generate .swift interface files that reconstruct the public API surface of frameworks. When you pass the --interface or --headers flags, the WriteHeaders method in internal/commands/macho/swift.go emits one file per type, protocol, and extension to the specified output directory.

# Generate Swift interface files for a private framework

$ ipsw swift-dump /usr/lib/swift/dyld_shared_cache_arm64e.dsc \
    PrivateFrameworks/MyFramework.framework/MyFramework \
    --headers --output ./swift-iface

This produces a folder containing reconstructable Swift declarations without requiring the original source code.

Summary

• ipsw objc provides hidden access to Objective-C class internals, parsing StringHash tables in pkg/dyld/objc.go to resolve selectors, classes, and protocols from the shared cache.
• ipsw swift-dump extracts Swift metadata via internal/commands/macho/swift.go, utilizing SwiftOptimizationHeader and SwiftHashTable structures to enumerate types and protocols.
• Both commands support the pkg/dyld.File abstraction for translating cache offsets and VM addresses to physical file locations.
• Advanced options include regex filtering (--type, --proto), demangling (--demangle), and interface generation (--headers, --interface).

Frequently Asked Questions

Can ipsw dump classes from individual Mach-O binaries?

Yes. While optimized for dyld_shared_cache processing, the swift-dump command accepts individual Mach-O files. The tool detects non-DSC inputs and uses go-macho parsers directly instead of the shared-cache hash table optimizations, as implemented in internal/commands/macho/swift.go.

What is the difference between the objc and swift-dump commands?

The objc command is a hidden utility specifically for inspecting single Objective-C class details (methods, properties, ivars) using the parser in pkg/dyld/objc.go. The swift-dump command is the primary interface for extracting Swift metadata and can also process Objective-C information when dealing with mixed frameworks, offering broader filtering and output options via internal/commands/macho/swift.go.

How does ipsw handle the dyld_shared_cache format internally?

The tool uses the pkg/dyld.File type to abstract the DSC format. This structure manages cache offset translation through methods like GetOffset and GetCacheVMAddress, allowing both Objective-C and Swift parsers to read raw bytes from the correct backing images without manually handling the complex sliding and mapping tables of the shared cache.

Can I filter specific classes or protocols when dumping?

Yes. The swift-dump command accepts --type and --proto flags that accept regular expressions. For example, --proto '^UIKit\.' matches only protocols in the UIKit namespace. These filters are applied during the hash table traversal in internal/commands/macho/swift.go to limit output before demangling and formatting.

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