问题
I have the following scenario:
- A proprietary MacOS game that statically links a graphics framework MoltenVK into its main Mach-O x86-64 binary.
- The version of MoltenVK linked in is very old.
- I have a newer version of MoltenVK in the form of a
.dylib(along with newer versions of the SPIRV compiler, libVulkan, etc. if they are needed, also in dylib form). - The older and newer version of MoltenVK are ABI compatible, meaning the exported symbol names and function signatures should be identical from the old to the new version of MoltenVK.
And the root cause of this journey into MacOS linkage:
- The game does not run correctly on my version of macOS (10.15 Catalina Beta 3). I have isolated the problem to MoltenVK due to a crash backtrace.
- I want to test whether updating MoltenVK will solve the problem, both as a temporary workaround and to help the developers isolate the problem.
Is it possible to force the binary to use a version of the symbols defined in a dynamically loaded .dylib instead of the version defined within the binary itself? I want to patch all symbols available in each of the .dylibs I have, because it would probably break if I only patched some symbols but not others (presumably MoltenVK only works if the code of each symbol in the framework is from the same version of MoltenVK).
Note: I am unable to recompile the main Mach-O binary of the game because I do not have source code. I am willing to bypass security safeguards on my local system to do this if it is possible at all; I accept the risk of doing dangerous things while running a Beta (non-production) OS anyway.
I'd prefer if answers and comments focus on the technical solution to the question asked, but if further justification is needed, I am trying to isolate this problem as quickly as possible to give the game's developers as much time as possible to fix it before the final release of macOS 10.15. If I stay silent, the problem has a chance that it won't be detected; then folks will upgrade to the final macOS 10.15 and notice the game doesn't work. That's not fun for anyone, because then we have to either stay on Mojave and wait for the game developer to update their game, or go without the game for possibly weeks or months.
回答1:
Static linking implies the library gets effectively baked into your final executable binary. So there's no easy technical way of hooking the calls and redirecting them somewhere else (like DYLD_INTERPOSE or DYLD_INSERT_LIBRARIES allows for external dylibs).
Patching the binary would require going through each MoltenVK call the game makes and doing quite cumbersome post processing. By post processing I mean either:
- writing a dyld call using
dlopen&dlsymtandem. You would still needdlopen&dlsymsymbols already used in the binary (they're part of libSystem aka C std lib, but you still need the dedicated dyld opcodes to be able to actually use them). Eventually you'd need to put the assembly opcodes somewhere in binary to make everything work. This will be quite hard. - firing
lldbdebugger, preparing thedlsymaddresses to call by hand and patching the binary on the fly for each call (you'd probably need write permissions in__TEXTsegment to do it, but that's the easy part). If you know what you're doing this is probably the most feasible approach. The main drawback is it's volatile, if you break something you'd start from scratch. - Add a
LC_LOAD_DYLIBcommand to the binary and dyld opcodes referenced byLC_DYLD_INFO_ONLY, that would be super hard
In any case your best friends are Hopper dissassembler and MachOView to inspect the binary.
Elementary knowledge of x86 (and/or x86-64) assembly is a must to follow. I think playing with the original source code could be a way more viable option.
来源：https://stackoverflow.com/questions/56880169/replace-static-symbols-in-macos-mach-o-binary-with-external-symbols