search

kennytm / Miscellaneous

This repository contains stuff which would be helpful for jailbroken iOS development.
293 stars 85 forks source link

dyld_decache segfault #1

Open apocolipse opened 12 years ago

apocolipse commented 12 years ago

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

kennytm commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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

Djayb6 commented 12 years ago

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

martepato commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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

planetbeing commented 12 years ago

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 commented 11 years ago

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

bogardon commented 5 years ago

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 :(