dyld_decache segfault

[apocolipse]

dyld_decache is giving a segmentation fault: 11 when using it to decache dyld_shared_cache_armv7 for iOS5 (final) from iPhone 4

[kennytm]

The segfault is a known issue, it is due to some offsetting of addresses in the __DATA segments (maybe related to ASLR).

Not all address ranges are offset - some libraries e.g. TextInput_?? don't have it, some have, and some e.g. PhotoLibrary has an offset in some addresses and none in some other.

In the other words, the situation is a mess.

Fortunately, the offset is a fixed value, and now I have a reliable way to determine it. The only problem is to know when to apply it.

dyld_decache will not be fixed. Instead, you would use another program to "normalize" the dyld_shared_cache, and then pass the corrected file to dyld_decache.

[steventroughtonsmith]

So, from my experience - copying the dyld_shared_cache_armv7 from the device using an AFC connection (or through a dummy .app that copies it to the iTunes File Sharing sandbox) provides a binary that does not segfault with dyld_decache. Maybe this should be investigated?

[kennytm]

@steventroughtonsmith: Interesting... unfortunately I don't have an iOS 4+ device to check.

[Djayb6]

@kennytm I'm still getting the segfault, even by copying the shared cache to ~/Documents. What tool can "normalize" the DSC ?

[martepato]

I'm also getting the segfault with the dsc from my iPhone 4 on iOS 5...

Would be very interrested how to fix this / normalize dsc

[Tom-Le]

I can confirm that using iExplorer (which browses iDevices via an AFC connection) to copy dyld_shared_cache_armv7 on my iPod touch running iOS 5.0 produces a binary that doesn't cause dyld_decache to segfault. Successfully extracted every library, framework and private framework from the dyld cache. (So basically @stevenstroughtsonsmith is correct.)

[Lunat1k]

I also had the same problem and I can concur that copying over AFC does work where copying over WiFi does not.

[planetbeing]

When read by processes running on iOS that have ASLR enabled, /System/Library/Caches/com.apple.dyld/dyld_shared_cache_armv7 appears changed due to the ASLR being applied, despite not actually being changed on the filesystem. The good news is that when read by processes that do not have ASLR enabled, the file matches what is actually on the filesystem. You can compile a program that explicitly does not support ASLR with the -mdynamic-no-pic flag. Thus you can write a program compiled with no PIC that copies /System/Library/Caches/com.apple.dyld/dyld_shared_cache_armv7 to a new file (that won't be screwed with by the OS) and then scp it off to get around this problem.

[theiostream]

I've addressed most, if not all issues around here at http://theiostream.tumblr.com/post/38514643642/bozocache.

[bogardon]

I know I'm almost a decade too late, but what I found was if I built dyld_decache from source, I was able to dump everything without a segfault. In contrast, if I used dyld_decache v0.1c from the download section, I'll always segfault at the exact same place.

FWIW, my setup is high sierra, xcode 10.1, iphone5's dyld_shared_cache_armv7s, and boost libraries from homebrew. Perhaps it's been fixed somewhere?

EDIT:
Turns out I celebrated too soon, the "successfully" dumped libraries don't actually work :(