Mach-O symbol stubs (IOS)

Question

I am trying to understand how Mach-o files work, and have made a good deal of progress with the online resources available (In particular, the Apple page here: http://developer.

Answer 1

I will describe the situation with the current iOS, it's somewhat different in the old versions.

The symbol stubs indeed load into the PC a function pointer. For the standard "lazy" (on-demand) imports, the pointer resides in the __lazy_symbol section and initially points to a helper routine in the __stub_helper section, e.g.:

__symbolstub1 _AudioServicesAddSystemSoundCompletion
__symbolstub1 LDR  PC, _AudioServicesAddSystemSoundCompletion$lazy_ptr
__symbolstub1 ; End of function _AudioServicesAddSystemSoundCompletion

__lazy_symbol _AudioServicesAddSystemSoundCompletion$lazy_ptr DCD _AudioServicesAddSystemSoundCompletion$stubHelper

__stub_helper _AudioServicesAddSystemSoundCompletion$stubHelper
__stub_helper LDR R12, =nnn ; symbol info offset in the lazy bind table
__stub_helper B   dyld_stub_binding_helper

The function dyld_stub_binding_helper is the fist one in the __stub_helper section and essentially is just a trampoline to the dyld_stub_binder function in dyld, passing to it what I call "symbol info offset" value. That value is an offset inside the lazy binding info stream (pointed to by the LC_DYLD_INFO or LC_DYLD_INFO_ONLY load command), which is a sort of bytecode stream with commands for dyld. Typical sequence for a lazy import looks like this:

72: BIND_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB(M, 0xYYYYY)
19: BIND_OPCODE_SET_DYLIB_ORDINAL_IMM(NNNN)
40: BIND_OPCODE_SET_SYMBOL_TRAILING_FLAGS_IMM(0x00, '_AudioServicesAddSystemSoundCompletion')
90: BIND_OPCODE_DO_BIND()

here dyld would do the following:

1. look up function named '_AudioServicesAddSystemSoundCompletion' from a dylib number NNNN in the list of dylibs listed in the load commands.
2. look up the executable's segment number M (most likely __DATA)
3. write the function pointer at the offset YYYYY.
4. jump to the looked up address so that the actual function does its job

The address written to happens to be the _AudioServicesAddSystemSoundCompletion$lazy_ptr slot. So, the next time the _AudioServicesAddSystemSoundCompletion is called, it will jump directly to the imported function, without going via dyld.

N.B.: you should not look at the offset 05fc0 in the file right away. The addr field is the virtual address, you should look up the containing segment command and see at what VA it starts and what is its file offset, then do the math. Usually the __TEXT segment starts at 1000.

However, the actual symbol stubs do look like you pasted, probably you have a fat mach-o with the fat header taking the first 1000 bytes, so the offsets line up.