{"id":29366,"date":"2020-06-26T16:16:31","date_gmt":"2020-06-26T20:16:31","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=29366"},"modified":"2025-07-08T21:56:52","modified_gmt":"2025-07-09T01:56:52","slug":"reverse-engineering-macos-11-0","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2020\/06\/26\/reverse-engineering-macos-11-0\/","title":{"rendered":"Reverse Engineering macOS 11.0"},"content":{"rendered":"

Apple<\/a>:<\/p>\n

New in macOS Big Sur 11 beta, the system ships with a built-in dynamic linker cache of all system-provided libraries. As part of this change, copies of dynamic libraries are no longer present on the filesystem. Code that attempts to check for dynamic library presence by looking for a file at a path or enumerating a directory will fail. Instead, check for library presence by attempting to dlopen()<\/code> the path, which will correctly check for the library in the cache.<\/p><\/blockquote>\n\n

Pierre Habouzit<\/a>:<\/p>\n

The only impact is if you are doing runtime detection\/search of library by path yourself. Which is a terrible idea for perf anyway.<\/p>\n

iOS has been like that for a decade already.<\/p>\n<\/blockquote>\n\n

The goal was optimization, but unfortunately it does make reverse engineering more difficult.<\/p>\n\n

Joe Groff<\/a>:<\/p>\n

\n

The shared cache isn’t encrypted or anything, and dyld is in the Darwin source dumps. The shared cache format may not be stable, but isn’t secret either<\/p>\n<\/blockquote>\n\n

The data is there, but there currently aren’t tools that can get it into a useful format like we had before.<\/p>\n\n

Steve Troughton-Smith<\/a>:<\/p>\n

\n

Incidentally, the new stripped framework cache on macOS 11 is horrendous<\/em> for disassembly. If you’re trying to track down why there’s a bug in your app, or how a system implementation works, you are screwed. This is going to hurt developers more than the ARM transition<\/p>\n<\/blockquote>\n\n

Jeff Johnson<\/a> (tweet<\/a>, also: zhuowei<\/a>):<\/p>\n

If the libraries are no longer present on the filesystem, that makes it awfully hard to disassemble them! Fortunately, there are ways to extract the system libraries from the cache. One way is provided by Apple itself: the dyld_shared_cache_util<\/code> command-line tool. Unfortunately, this tool does not come installed with macOS Big Sur. However, the tool is open source, so we can build it ourselves.<\/p><\/blockquote>\n\n

Jeff Johnson<\/a> (tweet<\/a>):<\/p>\n

Let’s take a look at an example from my favorite framework, AppKit.<\/p>\n

[…]<\/p>\n

It seems that prior to Big Sur, Objective-C references in a Mach-O file are offsets from the beginning on the file, whereas on Big Sur, Objective-C references in a Mach-O file are offsets from the beginning of the dyld shared cache. Roughly speaking.<\/p><\/blockquote>\n\n

You can also point Hopper<\/a> at the shared cache in the folder \/System\/Library\/dyld\/<\/tt>, and it will let you choose which library to load. But, as with dyld_shared_cache_util<\/code>, what you end up with is difficult to work with because the tools don’t know how to find the Objective-C selector information.<\/p>\n\n

Big Sur also adds another optimization that gets in the way of reverse engineering. Leo Natan<\/a>:<\/p>\n

\n

A lot of Apple’s private APIs are now peppered with direct and can no longer be swizzled.<\/p>\n<\/blockquote>\n\n

This makes it harder to debug and work around bugs. Unlike with the shared cache, this can’t be worked around with better tools. The information (and indirection) have been removed from the library entirely.<\/p>\n\n

Previously:<\/p>\n