dyld_shared_cache clarification

Questions and Answers about all things *OS (macOS, iOS, tvOS, watchOS)

dyld_shared_cache clarification

Postby darkknight » Thu May 03, 2018 10:56 pm

@S1guza
So there was a question about using a shared_cache from iOS 11 on iOS 10 http://www.newosxbook.com/forum/viewtopic.php?f=7&t=17164 and you had said :
If you replace the cache on disk, your OS is toast - trust cache signature checks will fail and your device will boot loop. Putting the cache somewhere else and loading it over the other one might be possible, but sounds extremely tedious. In order to avoid a horrible ending, you'd at least have to tear down userland (in a "launchctl reboot userspace"-style way), inject yourself into launchd (to continue running at that point), stop all threads except your own, write your injected code to not depend on any library whatsoever, patch the shared cache out of XNU memory, patch the new one in, and then do an actual userspace reboot. If you manage to bypass shared cache checks, you might also be able to just call the API (syscall 438 "shared_region_map_and_slide_np()"), and if you manage to bypass KPP you could actually do it all the dual-boot-way, but nevertheless this remains an extremely ambitious goal.


Here Morpheus seems to indicate it could work:
http://www.newosxbook.com/forum/viewtopic.php?f=7&t=17061
Since iOS 11 is not publicly jailbroken, you're in a predicament. One idea that would work is to back port the app with a private DYLD shared cache (from 11) into iOS 10.x which is jailbroken, and then inject into it.


Just seeking clarification on how what Morpheus referred to could be accomplished. Or maybe I misunderstood and am conflating the issues?
darkknight
 
Posts: 86
Joined: Mon Apr 18, 2016 10:49 pm

Re: dyld_shared_cache clarification

Postby Siguza » Thu May 03, 2018 11:34 pm

Well, once you have defeated code signing, you can map whatever file you like into your address space. Dyld even has some debugging features to load a different cache than the normal one, or none at all. To the best of my knowledge those features are disabled in iOS release builds, but with kernel access you could certainly replicate them somehow.
The point is that you'd put that cache some place other than your native cache. Because as I said in that post you linked to, replacing the original cache would break your system. The way that would happen is, when the device boots up, code signing has not yet been defeated, and the cache is subject to it as well. When XNU wants to spawn launchd, it first has to invoke dyld, which will try to resolve all imports and to that end, load the cache. If that fails, launchd will crash, XNU will panic (yes, it does that if PID 1 ever exits), and your device will reboot to start the story all over again until it runs out of battery power you forcibly shut it down.
User avatar
Siguza
Unicorn
 
Posts: 195
Joined: Thu Jan 28, 2016 10:38 am

Re: dyld_shared_cache clarification

Postby darkknight » Fri May 04, 2018 1:35 am

Ok kewl....thanks for clearing that up....makes sense now....
darkknight
 
Posts: 86
Joined: Mon Apr 18, 2016 10:49 pm


Return to Questions and Answers

Who is online

Users browsing this forum: No registered users and 1 guest

cron