2

I am trying to make a dyld extractor similar to dyld_decache and dsc_extractor. But I am having trouble parsing the __objc_selrefs section.

For testing purposes I used libsystem_trace.dylib, and was able to find and parse its mach_header and its segments and sections. But looking at the __DATA.__objc_selrefs section I find pointers like 0x201b8647fc8 and 0x201b860d716, which are way too high and point outside the cache.

In contrast, in a normal Macho file, the pointers in the __objc_selrefs section point to their corresponding string in the __TEXT.__objc_methname section.

I know that dyld slides and rebases sections, but after a lot of tinkering, I still could not fix the pointers. Any guidance would be amazing, especially given how little resources there is out there.

ArandomDev
  • 125
  • 2
  • 10

1 Answers1

3

These "addresses" don't just point outside the cache, they point outside the maximum range iOS allocates for the userland address space.
The thing is that these aren't raw addresses, they're addresses with some flags mixed into them. I've seen at least 0x20000000000 and 0x40000000000, and they seem to be exclusive to Objective-C code. I have no idea what they mean or what the true bitmask for these flags is, but so far keeping the lower 40 bits (0xffffffffff) of the addresses has done the job for me.
That would turn e.g. your 0x201b8647fc8 value into 0x1b8647fc8, which should be well inside the shared cache boundaries.

Siguza
  • 21,155
  • 6
  • 52
  • 89
  • 2
    This worked wonderfully! I did have to convert the VMAddr to the physical address, but that was a simple fix. Also, I found the mask in the dyld_cache_slide_info2 structure, so you were right on. – ArandomDev Mar 29 '20 at 00:36