Repository navigation
Switch from objdump to dlopen on macOS BS to detect nested dependencies #2
Description
macOS BS has the "dyld shared cache" which breaks running objdump on the dependencies. E.g. this results in BS Safari not having any features detected.
$ otool -L /Applications/Safari.app/Contents/MacOS/Safari
/Applications/Safari.app/Contents/MacOS/Safari (architecture x86_64):
/System/Library/PrivateFrameworks/Safari.framework/Versions/A/Safari (compatibility version 528.0.0, current version 610.2.6)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.0.0)
/Applications/Safari.app/Contents/MacOS/Safari (architecture arm64e):
/System/Library/PrivateFrameworks/Safari.framework/Versions/A/Safari (compatibility version 528.0.0, current version 610.2.6)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.0.0)
W/ the "dyld shared cache", the /System/Library/PrivateFrameworks/Safari.framework doesn't actually exist on disk anymore (hence objdump can't analyse it).
Maybe we can use dlopen to load and open an executable and then somehow traverse the link list (w/o actually executing the binary)?
Activity
saagarjha commentedon Oct 4, 2020
Alternatively, you could dump the shared cache and save the link graph, as I expect this to only be a problem if an app links a system framework that transitively links AppKit.
Alternatively you can just launch the app, stop it, and see what's loaded into the process.
helje5 commentedon Oct 5, 2020
How would I do this?
saagarjha commentedon Oct 7, 2020
You can use something like https://github.com/saagarjha/dyld-shared-cache-big-sur to grab all the files and they read the dependencies from everything.