Dyld Shared Cache¶

API

Introduction¶

LIEF Extended can inspect Apple’s Dyld shared cache, enumerate its libraries, and extract them as Mach-O binaries.

Load a cache and list its libraries¶

One can load a shared cache using the function:

import lief
dyld_cache: lief.dsc.DyldSharedCache | None = lief.dsc.load("macos-15.0.1/")

#include <LIEF/DyldSharedCache.hpp>
std::unique_ptr<LIEF::dsc::DyldSharedCache> dyld_cache =
    LIEF::dsc::load("macos-15.0.1/");

let dyld_cache = lief::dsc::load_from_path("macos-15.0.1/", "");

Note

Pass a directory to to load the whole cache, or an explicit set of files to load a subset. Keep the main cache and its matching subcache files together: an extraction may need data from more than one file.

From this object, we can inspect the embedded as follows:

dyld_cache: lief.dsc.DyldSharedCache

for dylib in dyld_cache.libraries:
    print(f"{dylib.address:#016x}: {dylib.path}")

std::unique_ptr<LIEF::dsc::DyldSharedCache> dyld_cache;

for (const LIEF::dsc::Dylib& dylib : dyld_cache->libraries()) {
  std::cout << dylib.address() << ' ' << dylib.path() << '\n';
}

let dyld_cache: &lief::dsc::DyldSharedCache = some_dyld_cache;

for dylib in dyld_cache.libraries() {
    println!("0x{:016x}: {}", dylib.address(), dylib.path());
}

Extract a library¶

Find a , then use to extract a for analysis. Check both the library lookup and the extraction result before using the Mach-O object:

dyld_cache: lief.dsc.DyldSharedCache

liblockdown = dyld_cache.find_lib_from_name("liblockdown.dylib")

macho = liblockdown.get()

for segment in macho.segments:
    print(segment.name)

std::unique_ptr<LIEF::dsc::DyldSharedCache> dyld_cache;

std::unique_ptr<Dylib> liblockdown =
    dyld_cache->find_lib_from_name("liblockdown.dylib");

std::unique_ptr<LIEF::MachO::Binary> macho = liblockdown->get();
for (const LIEF::MachO::SegmentCommand& segment : macho->segments()) {
  std::cout << segment.name() << '\n';
}

let dyld_cache: &lief::dsc::DyldSharedCache = some_dyld_cache;

let liblockdown = dyld_cache.find_lib_from_name("liblockdown.dylib").unwrap();

let macho = liblockdown.get().unwrap();

for segment in macho.segments() {
    println!("{}", segment.name());
}

Use to save the extracted object to a file:

dyld_cache: lief.dsc.DyldSharedCache

liblockdown = dyld_cache.find_lib_from_name("liblockdown.dylib")

macho = liblockdown.get()
macho.write("on-disk-liblockdown.dylib")

std::unique_ptr<LIEF::dsc::DyldSharedCache> dyld_cache;

std::unique_ptr<Dylib> liblockdown =
    dyld_cache->find_lib_from_name("liblockdown.dylib");

std::unique_ptr<LIEF::MachO::Binary> macho = liblockdown->get();
macho->write("on-disk-liblockdown.dylib");

let dyld_cache: &lief::dsc::DyldSharedCache = some_dyld_cache;

let liblockdown = dyld_cache.find_lib_from_name("liblockdown.dylib").unwrap();
let mut macho = liblockdown.get().unwrap();

macho.write("on-disk-liblockdown.dylib");

Warning

By default, LIEF retains Dyld shared cache optimizations. Review when the extracted library needs references and other cache-specific structures recovered. Writing a Mach-O file alone does not guarantee it can be loaded independently of the cache.

Performance Considerations¶

Dyld shared cache files are quite large, meaning they cannot be processed in the same way as standard or binaries.

The Dyld shared cache support in LIEF follows the principle: don’t pay overhead for what you don’t access. This is the opposite of the implementation of , , and .

Note

These functions parse all format structures (with decent performance) because:

Most binary sizes are less than one gigabyte.
A complete representation is required for modifying binaries.

From a technical perspective, LIEF uses a LIEF::FileStream to access Dyld shared cache structures on demand. Thus, in-memory consumption is limited to the size of the structures being accessed. The drawback of using FileStream is that because it uses file-based access, it takes more time compared to a LIEF::VectorStream.

Additionally, LIEF’s Dyld shared cache implementation heavily relies on the iterator pattern to follow the principle: don’t pay overhead for what you don’t access.

For instance, returns an iterator over the . Therefore, if you don’t iterate, you don’t pay for the access and parsing of the objects.

Where possible, LIEF implements the random access iterator trait [1] so that we can programmatically do:

dyld_cache: lief.dsc.DyldSharedCache

# No cost
libraries = dyld_cache.libraries

# O(1) cost
first_lib = libraries[0]

# O(len(libraries)) cost
for lib in libraries:
    print(lib.path)

std::unique_ptr<LIEF::dsc::DyldSharedCache> dyld_cache;

// No cost
auto libraries = dyld_cache->libraries();

// O(1) cost: the iterator is random access, so an arbitrary library can be
// reached by index without materializing the ones before it.
std::cout << "First library: " << libraries[0]->path() << '\n';

// O(libraries.size()) cost
for (const Dylib& dylib : libraries) {
  std::cout << dylib.path() << '\n';
}

When extracting a from a object using , the extraction can take a substantial amount of time, especially if certain deoptimizations are enabled (c.f. ).

For instance, may require iterating over the Dyld shared cache’s stub islands several times. To improve overall performance, LIEF provides a cache-based optimization that can be enabled and configured with:

When should you turn caching on?

You can skip LIEF’s caching if:

You don’t plan to extract libraries from the shared cache.
You plan to extract only one library from the shared cache and only once
You don’t want to have LIEF cache artifacts on your system.

For all other situations, you should turn on .

By default, the cache mechanism is not enabled.

References¶

Python API

C++ API

Rust API: lief::dsc