Skip to content

RTTI / vtables not discovered in images loaded from dyld shared cache #6603

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
bdash opened this issue Apr 9, 2025 · 2 comments
Open

RTTI / vtables not discovered in images loaded from dyld shared cache #6603

bdash opened this issue Apr 9, 2025 · 2 comments
Labels
Component: RTTI Core: Workflow Issue involves the workflow system Effort: Low Issue should take < 1 week File Format: SharedCache Issue with the dyld_shared_cache plugin Impact: Medium Issue is impactful with a bad, or no, workaround

Comments

@bdash
Copy link
Contributor

bdash commented Apr 9, 2025

Version and Platform (required):

  • Binary Ninja Version: 5.0.7189-dev (79570147)
  • OS: macOS 15.4
  • CPU Architecture: arm64

Bug Description:
RTTI and vtables are discovered and annotated in regular Mach-O binaries, but this does not appear to work in images loaded from the shared cache.

Steps To Reproduce:

  1. Open a macOS 15.x shared cache and load /System/Library/Frameworks/Metal.framework/Versions/A/Metal
  2. Search for typeinfo or vtable in the symbols pane and click around.

Expected Behavior:
Glorious structs!

@emesare
Copy link
Member

emesare commented Apr 9, 2025

To do this we need a way to queue a module level activity. Currently this is managed through AddAnalysisOption, we do this for linearsweep, but that is currently special-cased in the core (same goes for pointer sweep and the signature matcher).

I can otherwise just modify the rtti and vft activities to run always? I am not sure, will have to double check.

@WeiN76LQh
Copy link

A workaround would probably be to hold auto analysis initially, load all the desired images and then let analysis run.

To do this we need a way to queue a module level activity. Currently this is managed through AddAnalysisOption, we do this for linearsweep, but that is currently special-cased in the core (same goes for pointer sweep and the signature matcher).

I can otherwise just modify the rtti and vft activities to run always? I am not sure, will have to double check.

My experience with module activities are that they can be triggered alot so if the activity is doing anything remotely expensive it might not be the best solution.

@emesare emesare added Effort: Low Issue should take < 1 week Impact: Medium Issue is impactful with a bad, or no, workaround File Format: SharedCache Issue with the dyld_shared_cache plugin Component: RTTI Core: Workflow Issue involves the workflow system labels Apr 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: RTTI Core: Workflow Issue involves the workflow system Effort: Low Issue should take < 1 week File Format: SharedCache Issue with the dyld_shared_cache plugin Impact: Medium Issue is impactful with a bad, or no, workaround
Projects
None yet
Development

No branches or pull requests

3 participants