The ios-aarch64 platform is added on top of the original mac-aarch64

[VisualEhrmanntraut]

Version and Platform (required):

• Binary Ninja Version: 4.1.5637-dev
• OS: macOS
• OS Version: 15.0 Beta (24A5279h)
• CPU Architecture: M1

Bug Description:
I updated Binary Ninja and opened an iOS kernelcache bndb to resume work... waited and waited for the analysis... and... then noticed... huh???

Steps To Reproduce:
Open an iOS bndb from a version before the iOS platform was added.

Expected Behavior:
It should migrate the old platform to the new one and remove the old one.

Screenshots/Video Recording:

Binary:
Can't, I don't think Apple would like that!

Additional Information:
The reanalysis has been on-going for 6+ hours now. This was not the case before. It might be analysing both platforms.

[emesare]

Can you print out the architecture and platform for both functions?

>>> current_function.arch
...
>>> current_function.platform
...

I suspect that the duplication is occurring due to some extra platform or architecture, possibly the new iOS platform.

[river-li]

Look at the left bottom corner, after 6 hours of reanalysis it's still Phase 1. I think this may relate to #5141

[VisualEhrmanntraut]

I left it overnight and it finished. Seems like it was trying to analyse some weird function:

[Function warn] Skipping analysis for function at 0xfffffff007dfd5b8 : Exceeds 'analysis.limits.maxFunctionAnalysisTime'

(which is duplicated again)

@emesare yes, it's indeed because of the new iOS platform.

>>> current_function.platform
<platform: ios-aarch64>
>>> current_function.platform
<platform: mac-aarch64>

[CouleeApps]

Proposed solution for this: in 4.1, update database version and upon loading any database created in a prior version, don't apply the new ios platform to auto-discovered functions.

[VisualEhrmanntraut]

Sounds more like a workaround than a solution, as that would make the old analysis databases not take advantage of the newly introduced platform.

[plafosse]

That is unfortunately correct, its a workaround. Apologies. Our existing database structure wasn't actually designed to cope with a new more specific platform being introduced and working with older databases. This issue was only discovered when you opened the issue. Going forward we will have better options, but as of now the information just doesn't exist in the database to be able to make the correct decision.

[VisualEhrmanntraut]

Don't worry, I understand. I am also a software developer, I know how this stuff is. It should be easy to detect when the migration needs to happen though: if the ios-aarch64 platform is to be added, but the mac-aarch64 platform exists, migrate the important info from the old platform, put it in the newly added platform, remove the platform. Or something like that. Maybe that idea helps you guys get a bit unstuck. For now I would think it's best to just not add the new platform if the old one's here until a proper solution can be implemented.

[plafosse]

Fixed in 4.1.5729

[VisualEhrmanntraut]

@plafosse The issue got reintroduced somehow.

[emesare]

@plafosse The issue got reintroduced somehow.

I can reproduce this by running "save-as" on the database then reopening. Is that what you did?

What does the following output for you?

>>> bv.file.database.globals[b"original_version"]
'6'

[VisualEhrmanntraut]

I can reproduce this by running "save-as" on the database then reopening. Is that what you did?

@emesare Yes, I am scared to save over the original bndb until this is fixed properly.

[emesare]

Fixed in 4.1.5741-dev