[DSC] iOS 15: cross-image calls show as bare addresses, rather than names

[bdash]

Version and Platform (required):

• Binary Ninja Version: 5.2.8258-dev Ultimate, 42dff25b
• OS: macos
• OS Version: 26.0
• CPU Architecture: arm64

Bug Description:
After the changes in #7399, iOS 15 shared caches now load, apply Obj-C type information, and can be saved successfully.

One problem remains: Cross-image calls show as bare addresses, rather than names.

The stub functions reside in __stubs sections within library images, rather than in stub islands or other region types. We automatically load stub island regions to allow stub symbols to be resolved, but intentionally avoid loading images.

I don't see any obvious pattern as to which images the stubs are in. objc_msgSend is found in SwiftUI, __os_log_pack_fill is in AVFCore, ___error is in AppSupport.

The context menu correctly shows which library the stub function resides in and loading it applies the correct symbol name, but has the obvious consequence of analyzing that entire image

Steps To Reproduce:
Open 19D50__iPhone10,3_6 and look at the implementation of _sigaltstack at 0x18a8f17ac. It is in libSystem.dylib and should load by default.

Note the call:

18a8f17cc        *0x1886b39b8() = 0xc

This should be:

18a8f17cc        *j____error() = 0xc

But the stub is in /System/Library/PrivateFrameworks/AppSupport.framework/AppSupport so our current approach cannot resolve it automatically.

[bdash]

I'm not sure how feasible it is to address this in a manner that doesn't tank performance. More investigation required.

[WeiN76LQh]

Would using exported symbols and a render layer work? Exported symbols to identify the target function name and then a render layer to change its representation in the IL.

[bdash]

The stub functions themselves are not in the exported symbols list.

To get the name of the symbol being accessed we'd need to:

1. Detect that the address lives inside the __stubs section of an image
2. Load enough of that section to be able to resolve the target address of the indirect call within the stub function
3. Without loading the entire __TEXT segment of that image.

That would give us an address that does correspond to an exported symbol.