Page 1 of 1

Modify iOS dyld behaviour

PostPosted: Mon Oct 07, 2019 10:23 am
by septium
Is it possible to intervene in dyld symbol-resolving at an early stage of process loading? I want that:
1. All LC_LOAD_DYLIB load commands have LC_LOAD_WEAK_DYLIB actual behaviour;
2. Also I want to prevent early stage crashing when some classes/methods/c-functions are not found in iOS system frameworks. For example by rebinding missing executable symbols to stub code returning void/nil/zeroed memfragments of custom size, based on the actual executable symbol signature. High-level system frameworks are mostly objc (or objc-compatible), pure swift is still rare in system code, so returning nil instead of object in -init...s will be more or less safe: further objc_msgSends will be perfectly valid.

What I actually want is launching iOS13 AppStore(*) apps on iOS12. iOS12 has some frameworks missing, the same is true for some symbols in existing frameworks. But if I omit safely all the iOS13-specific functionality there exist some chance that many apps will work with reduced capabilities. It's also possible to make app-specific stubbing for popular apps, and/or framework–specific stubbing to return customized fake values instead of nil/zeroed memfragments.

Reason is obvious: many iOS12 devices have lifetime JB and enough horsepower, but, obviously too, they cannot run iOS13+ apps.

(*): Modifying mach-o header, which is unencrypted in AppStore apps (because of fairplayed region offset) is not an option because of signature validity check by AMFI, as far as I understand this situation.

Re: Modify iOS dyld behaviour

PostPosted: Thu Oct 10, 2019 5:46 pm
by morpheus
Easiest way is to perform all these changes at the Mach-O layer. I'll be bringing back this functionality into jtool2's final update. Stay tuned.