Symbols not shown in symbols tab when loading from .bndb on macos

[Yannis-Hofmann]

**Version and Platform: **

• Binary Ninja Version: 5.3.8617-dev personal
• Edition: Non-Commercial
• OS: macOS
• OS Version: 26.1
• CPU Architecture: M4

Bug Description:
When loading an arm64 framework or binary into Binary Ninja, the symbols are loaded/demangled as expected. But when saving this file as a .bndb file and reopening it, all symbols in the symbol tab are only shown as "sub_..." instead of their name. They are, however, still present in the IL viewer.

Steps To Reproduce:

1. Load and analyze a macOS binary
2. Save it as a .bndb file
3. Restart binary ninja
4. Open the saved .bndb file
5. The symbol tab does not display any symbol names anymore and instead shows "sub_..." names

Expected Behavior:

I would expect Binary Ninja to load the symbol tab correctly again and display the names that are shown in the code, also in the symbols tab.

Binary:

This happened with multiple macOS Framework binaries.

[bdash]

I have not been able to reproduce this with 5.3.8617-dev when testing by opening a variety of Mach-O binaries, saving them to a database, then closing and reopening them several times each.

1. Is there a specific binary that you're able to reproduce this with when using the steps you shared? If there is, would you be able to share it with us (via https://portal.binary.ninja/upload if you would like it to remain private).
2. Were the databases you're seeing this with created with 5.3.8617-dev or some earlier version? If an earlier version, do you have a rough idea of which version (even if it's as vague as "dev from a couple of months ago")?
3. Are you able to share any of the existing databases that you see this with?

[Yannis-Hofmann]

Thanks for the quick response. This is the reference ID: warm spark soars orderly
I am able to reproduce it with this binary when using the newest version (5.3.8617-dev) both to create and then load the .bndb.

[Yannis-Hofmann]

Hey @bdash, did you happen to have time yet to test whether you can reproduce this issue with the binary I submitted?

[bdash]

Thank you for sharing the binary. I was able to reproduce it today. There are two issues at play here, with the second being a bug that is triggered as a result of the first.

1. The binary in question is extracted from a dyld shared cache using a tool like dyld-shared-cache-extractor or ipsw dyld extract. These create binaries that contain chained fixups within their data segments, but without the necessary Mach-O load commands / linkedit data to apply those chained fixups. A consequence of this is the Objective-C metadata processing trying and failing to read pointers to metadata, which you'll see as a large number of errors in the log pane.

   The solution for this is to prefer to load the dyld shared cache directly in Binary Ninja and then load the images of interest via the shared cache triage view. The shared cache itself contains the necessary headers / linkedit data for Binary Ninja to apply the chained fixups. It will generally result in much better analysis than loading extracted dylibs.

2. An unintended side-effect of the failure to parse Objective-C metadata is that the view is left in a state where it thinks it has started a bulk modification of the symbol table, but it can never complete as an exception was thrown. If this happens during the process of loading a database, the symbols loaded from the database end up as part of this bulk modification and are never committed to the view.

   The solution here is to improve the API used for bulk symbol modification to make it impossible to "leak" a bulk modification like this.

[Yannis-Hofmann]

Thank you very much. That was indeed the problem. After loading the binary through Binary Ninja's shared cache tool, I did not have any problems anymore.