Conversation
- This functionality has only been tested against iOS dyld shared caches. - dyld shared caches from iOS must be retrieved directly from the decrypted firmware. Caches from the live device (retrieved through scp, etc.) have a slide applied and cannot be used.
|
I don’t see the point of adding dyld shared cache support directly into class-dump. There’s already a tool to extract the dyld cache into Mach-O files: dyld_decache. Then you can inspect the extracted files with class-dump or any other tool which can read Mach-O files. |
|
That doesn't work properly, hence I added this feature. The problem is that those tools will only extract parts of the dyld cache directly mapped by the Mach-O header in question. However, the libraries in the dyld cache will in fact at times reference memory locations outside the "library", but inside other libraries, probably due to optimizations meant to coalesce common class definitions, selectors etc. There's no way for a tool like dyld_decache to guarantee it will extract out all relevant pieces of the dyld cache for class-dump to completely work on a particular binary without doing everything class-dump does. The particular example that prompted me to write the patch in the first place is the BackRow framework for AppleTV 4.3. |
|
Actually, my apologies, I was wrong about dyld_decache not working in that case. I was originally passing a bad (ASLR'ed) dyld cache through that program. dyld_decache in fact correctly pulls out the coalesced information. Still, class-dump is able to produce the same results with considerably less complexity and effort, without regard for future optimizations Apple may do, so it's up to you guys if you want to accept the patch. |
|
I just learnt that Apple itself provides a tool to extract the dyld shared cache!
For the sake of completeness: |
Added support for using class-dump directly against dyld caches.
Caches from the live device (retrieved through scp, etc.) have a slide applied and
cannot be used. (The only way I've reliably found to get around this is to read the
file directly off the raw block device, otherwise the kernel screws with the file like
a rootkit).