Support for iOS 18 Objective-C Optimizations in dyld_shared_cache

Open
#6,054 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
objective-c

Research direction

Reproduce the issue by loading the Contacts image from an iOS 18 dyld shared cache and inspect the Objective-C metadata path around BNDSCViewLoadImageWithInstallName in the provided backtrace. Confirm the repeated ivar-processing failures and establish that analysis completes without the apparent infinite loop.

Written by the indexing model from the issue text.

Description

Effort: Low File Format: SharedCache Impact: Medium

Version and Platform (required):

  • Binary Ninja Version: 4.2.6304-dev (65f49c87)
  • OS: macOS
  • OS Version: 15.0
  • CPU Architecture: M1

Bug Description:
Sometimes loading a certain image from DSC results in Binary Ninja getting caught in what appears to be an infinite loop (probably finite bound to a very large number). During this time BN prints the following to the log view:

[SharedCache.ObjC] Failed to process an ivar at offset 0x180ded9a8

The address value at the end is an example. This line will keep being printed over and over, and the address value will increment by 0x20 each time. I'm guessing there's something wrong with the metadata parsing causing it to think there's a huge number of ivars to process.

Steps To Reproduce:

  1. Open a copy of DSC extracted from an iOS 18.0 beta 4 ipsw (22A5316j) for an iPhone 15 Pro Max (iPhone16,2) in Binary Ninja
  2. Wait for the initial analysis to complete
  3. Load the image /System/Library/Frameworks/Contacts.framework/Contacts

Binary:
Extract the DSC from an iOS 18.0 beta 4 ipsw (22A5316j) for an iPhone 15 Pro Max (iPhone16,2). This has been a problem with other copies of DSC and other images within DSC, this is just one I know to be problematic with the contacts framework.

Additional Information:
I believe this is a back trace for the thread thats doing the Objective-C metadata parsing. Hopefully its helpful without symbols given the version and platform information above.

* thread #39, name = 'Worker PRI '
  * frame #0: 0x000000018b2116dc dyld`invocation function for block in dyld3::MachOFile::forEachSegment(void (dyld3::MachOFile::SegmentInfo const&, bool&) block_pointer) const + 40
    frame #1: 0x000000018b1c42dc dyld`dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command const*, bool&) block_pointer) const + 300
    frame #2: 0x000000018b211688 dyld`dyld3::MachOFile::forEachSegment(void (dyld3::MachOFile::SegmentInfo const&, bool&) block_pointer) const + 172
    frame #3: 0x000000018b1e4e90 dyld`dyld4::JustInTimeLoader::contains(dyld4::RuntimeState&, void const*, void const**, unsigned long long*, unsigned char*) const + 260
    frame #4: 0x000000018b1f6fa4 dyld`invocation function for block in dyld4::APIs::findImageMappedAt(void const*, dyld3::MachOLoaded const**, bool*, char const**, void const**, unsigned long long*, unsigned char*, dyld4::Loader const**) + 144
    frame #5: 0x000000018b1d0404 dyld`dyld4::RuntimeLocks::withLoadersReadLock(void () block_pointer) + 100
    frame #6: 0x000000018b1f6da4 dyld`dyld4::APIs::findImageMappedAt(void const*, dyld3::MachOLoaded const**, bool*, char const**, void const**, unsigned long long*, unsigned char*, dyld4::Loader const**) + 756
    frame #7: 0x000000018b1fa6a4 dyld`dyld4::APIs::_dyld_find_unwind_sections(void*, dyld_unwind_sections*) + 124
    frame #8: 0x0000000198f7ddf0 libunwind.dylib`libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_arm64>::setInfoBasedOnIPRegister(bool) + 140
    frame #9: 0x0000000198f82288 libunwind.dylib`unw_set_reg + 636
    frame #10: 0x000000018b50436c libc++abi.dylib`__gxx_personality_v0 + 384
    frame #11: 0x0000000198f83080 libunwind.dylib`unwind_phase2 + 596
    frame #12: 0x0000000198f82e14 libunwind.dylib`_Unwind_RaiseException + 804
    frame #13: 0x000000018b503c7c libc++abi.dylib`__cxa_throw + 84
    frame #14: 0x000000011df0f6e4 libsharedcache.dylib`___lldb_unnamed_symbol3202 + 412
    frame #15: 0x000000011deb4d58 libsharedcache.dylib`___lldb_unnamed_symbol2785 + 424
    frame #16: 0x000000011deb2a5c libsharedcache.dylib`___lldb_unnamed_symbol2782 + 2312
    frame #17: 0x000000011dec5e14 libsharedcache.dylib`___lldb_unnamed_symbol2801 + 33316
    frame #18: 0x000000011deeafbc libsharedcache.dylib`___lldb_unnamed_symbol2952 + 4844
    frame #19: 0x000000011def8814 libsharedcache.dylib`BNDSCViewLoadImageWithInstallName + 168
    frame #20: 0x0000000310098070 libsharedcacheui.dylib`___lldb_unnamed_symbol3814 + 48
    frame #21: 0x00000003100aeb64 libsharedcacheui.dylib`___lldb_unnamed_symbol4472 + 36
    frame #22: 0x00000001156af22c libbinaryninjacore.1.dylib`___lldb_unnamed_symbol29525 + 2160
    frame #23: 0x00000001156ae6e4 libbinaryninjacore.1.dylib`___lldb_unnamed_symbol29520 + 12
    frame #24: 0x000000018b54b2e4 libsystem_pthread.dylib`_pthread_start + 136
Dominant language
C++
Stars
1.3k
Forks
298
Avg merge
5d 5h
Merged PRs (30d)
19

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Vector35/binaryninja-api

All issues in Vector35/binaryninja-api

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.