Support for new dyld_shared_cache format in iOS 15/macOS 12

[zcutlip]

The dyld_shared_cache format in iOS 15 & macOS 12 has changed and is now been split into 2 or more slices. Ghidra is no longer able to open it.

It would be helpful if Ghidra could be updated to open these shared cache clusters.

Below are examples of the shared cache layout directory on iOS & macOS

macOS 12:

❱ ls -1 System/Library/dyld/dyld_shared_cache_arm64*
System/Library/dyld/dyld_shared_cache_arm64e
System/Library/dyld/dyld_shared_cache_arm64e.1
System/Library/dyld/dyld_shared_cache_arm64e.map

iOS 15:

❱ ls -1 System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64*
System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64
System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64.1
System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64.2
System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64.3
System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64.4
System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64.5
System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64.symbols

[ryanmkurtz]

Thanks for the heads up. This is definitely something we'll want to support.

[ryanmkurtz]

Do you have any links that describe the new format? I don't have access to these at the moment.

[zcutlip]

There's not much, unfortunately. It's anticipated that Apple will release updated dyld source in the fall, but that often lags final releases by quite a bit.

There are a couple projects that are actively working on it: DyldExtractor and blacktop's IPSW. Here's a GH issue for DyldExtractor with, with participation from blacktop:
arandomdev/DyldExtractor#15

Hopper has (very) preliminary support, but I don't think it does much yet.

If binary analysis is an option for you, I'd look at dsc_extractor.bundle in the latest Xcode betas. Each SDK in Xcode except macOS has one. But the iOS version can be loaded on arm64 macOS, and can parse arm64 macOS shared cache. Watching it do its thing in lldb would probably reveal a lot. Here's a project that loads it on macOS and is able to parse the macOS shared cache:
https://github.com/keith/dyld-shared-cache-extractor

Hope that helps. I'll see what else I can find.

Zach

[mumbel]

So you're saying that is something that would eventually be found here https://opensource.apple.com/source/dyld/ ? does it report which version of the format is used in the current files

[zcutlip]

If the past is any indication, yes, that's where new dyld source will go, which will include header files describing the new format, as well as C++ code that parses it. I'd expect to see source for that probably in October/November. Apple isn't super consistent on this.

As far as versioning, there are header fields that report versions in various ways, but it's not a very tidy "look at the version field to see what format version we're dealing with."

Probably the best example of version detection is DyldExtractor, referenced above. They do a pretty good job of dealing with an assortment of format variants. It's a combination of looking at a few explicit version fields in different structs, and heuristics (e.g., if this field is NULL, look for some additional fields at the end).

[ryanmkurtz]

I got some samples and should be able to make some initial guesses about how things are laid out. The biggest issue I see up front is that our Loader framework isn't designed to bring in more than 1 file. A Loader can support the Add to Program feature, but I am seeing that these files cross references each other in terms of memory layout definitions and DYLIB locations, so we'll have to think a little bit about how to best handle this.

[astrelsky]

There's not much, unfortunately. It's anticipated that Apple will release updated dyld source in the fall, but that often lags final releases by quite a bit...

I got some samples and should be able to make some initial guesses about how things are laid out...

Time to roll up the sleeves and do it the old fashioned way.

Not entirely accurate but still applies I guess

meme

[mstange]

I've also done some research on the format and have written down my findings in gimli-rs/object#358.

[ryanmkurtz]

I've also done some research on the format and have written down my findings in gimli-rs/object#358.

Thanks, I'm working on this now.

[ryanmkurtz]

I put up a PR for this if anyone wants to try it (#3666)

[Kentzo]

I'm using 10.1.2 bug Ghidra doesn't seem to load anything from /System/Library/dyld/*. Are there extra options that need to be set for this feature to work?

[ryanmkurtz]

What is an example file you are trying to load? Are you selecting Single File or File System?

[Kentzo]

I’m trying /usr/bin/tmutil. I have extracted the x86_64 with lipo and loading it as a single file with a checked option to load external libraries.

…

On Apr 18, 2022, at 9:22 PM, Ryan Kurtz ***@***.***> wrote:  What is an example file you are trying to load? Are you selecting Single File or File System? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[ryanmkurtz]

I just imported that file without any issues. I opened it in the File System Browser, then right clicked on the x86-64-cpu0x31 "file" and clicked import. I'm on macOS 12.3.1.

[Kentzo]

Did it also load linked external libraries into the project for analysis? Best Regards Ilya Kulakov

…

On Apr 19, 2022, at 12:00 AM, Ryan Kurtz ***@***.***> wrote:  I just imported that file without any issues. I opened it in the File System Browser, then right clicked on the x86-64-cpu0x31 "file" and clicked import. I'm on macOS 12.3.1. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[ryanmkurtz]

Ah, I'll have to try that again tonight when I'm on my mac again. Can you please open a new ticket describing your issue in detail so it doesn't get lost in this already closed one?