Difference between revisions of "Dyld shared cache"

From iPhone Development Wiki
Jump to: navigation, search
(Not working since iOS 11)
(Path formatting fix in Cache retrieval)
Line 108: Line 108:
 
* Copy the cache through AFC (filesystem browsers which use an AFC connection are fine) - on iOS 7 and 8, you'll want to install the package ''Apple File Conduit "2"'', hosted/maintained by saurik.
 
* Copy the cache through AFC (filesystem browsers which use an AFC connection are fine) - on iOS 7 and 8, you'll want to install the package ''Apple File Conduit "2"'', hosted/maintained by saurik.
 
* Pull the cache off a decrypted root filesystem DMG which you can find inside the IPSW.
 
* Pull the cache off a decrypted root filesystem DMG which you can find inside the IPSW.
* Use the copy that is probably laying around on your computer in "~/Library/Developer/Xcode/iOS DeviceSupport/" if you have Xcode.
+
* Use the copy that is probably laying around on your computer in <tt>~/Library/Developer/Xcode/iOS DeviceSupport/</tt> if you have Xcode.
  
 
Alternatively, [https://github.com/npupyshev/dt.fetchsymbols dt.fetchsymbols] can be used to extract the cache from an iOS device. This tool doesn't require file system access (jailbreak) or app installation.
 
Alternatively, [https://github.com/npupyshev/dt.fetchsymbols dt.fetchsymbols] can be used to extract the cache from an iOS device. This tool doesn't require file system access (jailbreak) or app installation.

Revision as of 09:52, 2 May 2020


Since iPhone OS 3.1, all system (private and public) libraries have been combined into a big cache file to improve performance. The original files are redundant and thus eliminated from the system.

If you're looking for binaries or libraries inside of /System/Library/Frameworks or /System/Library/PrivateFrameworks (or other directories) and can't, this is why.

OS X also uses a shared cache. Unlike iOS, OS X ships with the source binaries still on-disk, particularly so it can be updated with update_dyld_shared_cache. The cache is only vaguely documented in dyld man pages.

Cache location

The cache is located in /System/Library/Caches/com.apple.dyld/dyld_shared_cache_armX, where X can be:

X Device ARM Architecture
v6 ARMv6
v7 ARMv7
v7s
v7k
64 ARMv8
64e ARMv8.3

Cache extraction

It used to be possible to compile and link from an iOS device without an SDK, but the introduction of dyld_shared_cache has made using an SDK a necessity. Alternatively, one may need to extract the appropriate dylibs from the dyld_shared_cache, if it's not available in the SDK.

Starting with iOS 8, the framework binaries shipped with the iOS SDK only contain the symbols, not the compiled code anymore. Binaries extracted from the dyld_shared_cache contain all compiled code and are therefore useful for reverse-engineering purposes.

Options:

  • dyld_decache by KennyTM~ to extract these dylibs.
  • DySlim by comex to mount the whole cache file on Mac OS X.
  • decache by phoenixdev to nearly perfectly extract dylibs from iOS <= 6 cache file.
  • dsc_extractor (source code). More info here. It produces the best results among all tools, but without branch islands workaround.
  • jtool is another option starting from iOS 8.
  • yasce by comex is/was the best option for iOS 8 (and above), but you will need a nightly build version of rust; something like "rustc 1.9.0-nightly (339a409bf 2016-03-01)".
  • dyld_cache_extract by macmade that works on macOS and provides a complete GUI. Clone repo and do 'git submodule update --remote' before buidling. It was reported to be not working on iOS 10.2's dyld_shared_cache_armv7s; gave a 561.1MB executable file.

Example usage for decache

This will extract the binary of the private framework SpringBoardServices

decache -c path/to/dyld_shared_cache -x /System/Library/PrivateFrameworks/SpringBoardServices.framework/SpringBoardServices -o SpringBoardServices

If you get a message about an unsupported load command, ignore it. decache does not support some newer mach-o load commands, so the binary won't be able to run probably in the most cases. But for linking or reverse-engineering purposes it is still usable.

Example usage for jtool

To extract a specific binary from the cache ("UIKit" can be replaced with a different framework or library):

jtool -extract UIKit path/to/dyld_shared_cache

An example of one way to dump all the binaries at once (be careful with this, it creates huge files):

cache=dyld_shared_cache_arm64
mkdir -p extracted && jtool -lv $cache | cut -c 24- | tail +5 | while read line; do mkdir -p extracted/"$(dirname "$line")"; jtool -extract $line $cache; mv $cache."$(basename "$line")" extracted/$line; done

Problems with jtool

Please be aware that decache produces currently (16.04.15) better and more usable results then jtool, as jtool fails to resolve and fix the "uniqued" objectiv c selectors correctly.

Apple "uniques" objectiv c selectors, such as "alloc" (alloc is used almost everywhere), which are used in more then one place, into a single one. When extracting an image from the cache, the address of such a shared selector will most likely not be in the extracted image anymore, so this needs to fixed, which jtool apparently fails to do. (For more information: http://opensource.apple.com/source/dyld/dyld-132.13/launch-cache/update_dyld_shared_cache.cpp, look at the class ObjCSelectorUniquer)

Not working since iOS 11

jtool2 is the newer version this user reports it not working on the iOS 11 shared cache - shows a warning "File is likely truncated (or header corrupt?)" and then doesn't get past "LC_DYLD_INFO..." http://newosxbook.com/forum/viewtopic.php?f=3&t=19577&start=50#p24183 Still same error exists on the cache from iOS 13.

$ ./jtool2 -e Stocks ./dyld_shared_cache_arm64 
Warning: File is likely truncated (or header corrupt?) Binding opcodes falls outside file
Warning: File is likely truncated (or header corrupt?) Binding opcodes falls outside file
Warning: File is likely truncated (or header corrupt?) LC_FUNCTION_STARTS falls outside file
0x176d9000-0x17731000 __TEXT   (360448 bytes)
0x2ccc2070-0x2ccd54a8 __DATA_CONST   (78904 bytes)
0x30571f60-0x30575f60 __DATA   (16384 bytes)
0x314c9a28-0x314ca000 __DATA_DIRTY   (1496 bytes)
0x316b3000-0x37064000 __LINKEDIT   (94048256 bytes)
   0x31e3c4d0-0x31e3eaf8 Exports   (9768 bytes)
   0x34689f18-0x346912f8 Symbol Table   (29664 bytes)
   0x35a46500-0x35a46b90 Function Starts   (1680 bytes)
   0x35bb1930-0x35bb1960 Data In Code   (48 bytes)
   0x35d66710-0x37029aba String Table   (19674026 bytes)
LC_DYLD_INFO...

Cache retrieval

Since ASLR was implemented in iOS, trivial ways to pull the cache off the device have provided a "broken" cache, which can't be processed correctly by the aforementioned tools. This is because when read by processes in which ASLR is enabled, some offsetting is applied to the cache too. In order to circumvent this issue and pull a "valid" shared cache off the device, there are different options:

  • Copy the cache off the device using a program on which ASLR has been explicitly disabled, using the -mdynamic-no-pic compile flag.
  • Read the cache explicitly from the filesystem by setting the F_NOCACHE flag on the cache's file descriptor.
  • Copy the cache through AFC (filesystem browsers which use an AFC connection are fine) - on iOS 7 and 8, you'll want to install the package Apple File Conduit "2", hosted/maintained by saurik.
  • Pull the cache off a decrypted root filesystem DMG which you can find inside the IPSW.
  • Use the copy that is probably laying around on your computer in ~/Library/Developer/Xcode/iOS DeviceSupport/ if you have Xcode.

Alternatively, dt.fetchsymbols can be used to extract the cache from an iOS device. This tool doesn't require file system access (jailbreak) or app installation.

Class dumping

See this section of Reverse Engineering Tools.

External Links

  • Cache or Check? — an analysis of the dyld_shared_cache system by D. Howett.
  • dsc_fix — an IDA script that aids in reverse engineering dyld_shared_cache libraries