Marques Brownlee (tweet, MacRumors):
Some insight with Craig Federighi about the iOS 14 and the more controversial 2020 announcements!
He starts off with a question about why iOS 14 doesn’t let you set the default maps app. I like the way he intersperses additional commentary and reactions with clips from the interview itself.
Previously:
Microsoft (via MacRumors, Hacker News):
The company’s retail team members will continue to serve customers from Microsoft corporate facilities and remotely providing sales, training, and support. Microsoft will continue to invest in its digital storefronts on Microsoft.com, and stores in Xbox and Windows, reaching more than 1.2 billion people every month in 190 markets. The company will also reimagine spaces that serve all customers, including operating Microsoft Experience Centers in London, NYC, Sydney, and Redmond campus locations. The closing of Microsoft Store physical locations will result in a pre-tax charge of approximately $450M, or $0.05 per share, to be recorded in the current quarter ending June 30, 2020.
I will miss the stores as an easy way to try out Microsoft’s new hardware products. Perhaps Apple can lease some of those spaces, to help deal with overcrowding and increase Genius Bar capacity. Many of the locations are within eyesight of the Apple store in the same mall.
Previously:
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()the path, which will correctly check for the library in the cache.
The only impact is if you are doing runtime detection/search of library by path yourself. Which is a terrible idea for perf anyway.
iOS has been like that for a decade already.
The goal was optimization, but unfortunately it does make reverse engineering more difficult.
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
The data is there, but there currently aren’t tools that can get it into a useful format like we had before.
Incidentally, the new stripped framework cache on macOS 11 is horrendous 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
Jeff Johnson (tweet, also: zhuowei):
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_utilcommand-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.
Let’s take a look at an example from my favorite framework, AppKit.
[…]
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.
You can also point Hopper at the shared cache in the folder /System/Library/dyld/, and it will let you choose which library to load. But, as with dyld_shared_cache_util, what you end up with is difficult to work with because the tools don’t know how to find the Objective-C selector information.
Big Sur also adds another optimization that gets in the way of reverse engineering. Leo Natan:
A lot of Apple’s private APIs are now peppered with direct and can no longer be swizzled.
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.
Previously:
Update (2020-07-06): Anton Sotkov:
Modifications to Apple’s dyld project to fix Objective-C information when extracting dyld_shared_cache from macOS Big Sur to help Hopper generate readable pseudocode.
Update (2020-07-27): Jeff Johnson:
Static disassembly tools such as otool and llvm-objdump have not been updated to handle the dyld shared cache on Big Sur. However, one tool that does handle it is lldb, the debugger.
[…]
I hope that my little hack helps you to disassemble system libraries on Big Sur. It’s a bid tedious, but it mostly works, and you only have to do it once for each library you’re interested in.
See also: Hopper for Apple Silicon and Big Sur
Update (2020-11-25): nevyn Bengtsson:
Remember when I complained months ago how bad it would be for everyone if Big Sur really did ship without system library binaries? Less open, harder to develop, etc etc. Well, now even the latest version of CMake doesn’t understand how to make Big Sur apps, it seems.
Here’s the solution. Replace
-framework AVFoundationwithFIND_LIBRARIES. Now it finds the .tbd and links with that INSTEAD.But I find it absurd to break decades-old foundations in every build tool that isn’t Xcode >12.2.
Update (2021-09-08): Steve Troughton-Smith:
Apple’s changes to how its system frameworks are packaged in macOS 11+, rendering them stripped & extremely difficult to reverse-engineer, is proving disastrous for finding & fixing framework-level bugs 😪
Update (2024-02-01): Wade Tregaskis:
The good news for Hopper is that it has since been updated to work around this – you can access the Apple framework binaries through File > Read File from DYLD Cache… There’s also tools like dyld-shared-cache-extractor which can resurrect the binaries from the cache.
Note also that in Sonoma, at least, the cache lives at /System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/ (in previous macOS releases it was apparently in /System/Library/dyld/).
What makes me most angry at what has happened to the log and Console is that Apple’s concepts and engineering are outstanding: the log has a remarkably low latency, retains a great deal of invaluable data in structured and compact format, and should be an essential resource to anyone who takes their Mac seriously. Instead of building on those unique strengths, Apple has provided token support which must leave even its own engineers wishing for better, as they wade through the logarchives supplied in
sysdiagnosedumps.
macOS 11 continues to improve the logging APIs, but from what I can tell it’s still difficult to actually use the log from Console.
Previously:
