Skip to content

Functions are being created for jump tables in code sections #7992

Description

@WeiN76LQh

Version and Platform (required):

  • Binary Ninja Version: 5.3.9208-dev Ultimate (8b909a0c)
  • Edition: Ultimate
  • OS: macOS
  • OS Version: 26.3
  • CPU Architecture: M1

Bug Description:
It seems Binary Ninja is overwriting jump tables in code sections with functions even though it has correctly identified them as jump tables. The symbol of the function is a data symbol as well.

Steps To Reproduce:

  1. Open a recent copy of the DYLD Shared Cache with default load settings so libsystem_c.dylib is loaded automatically.
  2. Wait for initial analysis to complete.
  3. Go to any of the unnamed functions (beginning with sub_).
  4. Observe that they all seem to be for jump tables are not actual functions.

Expected Behavior:
Jump tables in code sections shouldn't be overwritten with functions.

Screenshots/Video Recording:

Navigating to the symbol for one of the unnamed functions thats actually a jump table:

Image

Navigate to the reference to the jump table:

Image

It appears the jump table is working correctly as a switch case.

Binary:
DYLD Shared Cache for an iPhone 17 Pro Max running iOS 26.0

Additional Information:
I confirmed the behaviour is exactly the same when running Binary Ninja with plugins disabled.

Activity

  1. plafosse commented on Mar 9, 2026

    @plafosse
    Member

    This is actually kind of the opposite of what you're saying. The function is first identified and then the jump table goes and overwrites the function. It's happening because that address is listed in the functionStarts table.

    	if (header.linkeditPresent && m_vm->IsAddressMapped(header.linkeditSegment.vmaddr))
    	{
    		if (m_applyFunctions && header.functionStartsPresent)
    		{
    			auto targetPlatform = m_view->GetDefaultPlatform();
    			auto functions = header.ReadFunctionTable(*m_vm);
    			for (const auto& func : functions)
    				m_view->AddFunctionForAnalysis(targetPlatform, func, false); // <=== this code is adding that address.
    		}
    

    I'm not sure what can be done about this other than perhaps resorting to heuristic code/data disambiguation.

  2. added theissue type on Mar 9, 2026
  3. added
    Impact: LowIssue is a papercut or has a good, supported workaround
    on Mar 9, 2026
  4. WeiN76LQh commented on Mar 9, 2026

    @WeiN76LQh
    Author

    Huh, thats kind of odd/unfortunate, makes fixing it not hugely worth the effort. I think you're right that some kind of heuristic would be required but that could open up the potential for other bugs. The only alternative I can think of is if there are some kind of flags/metadata in Mach-Os/DSC that indicate a function start is for a jump table.

  5. plafosse commented on Mar 9, 2026

    @plafosse
    Member

    PR #8002 "fixes" the issue by adding a dumb heuristic that should pretty much have no false positives but could have tons of false negatives (no worse than where we're at right now). I does work on all the messed up jump tables in the DSC though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Impact: LowIssue is a papercut or has a good, supported workaround

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions