Bug Description:
There seems to be performance issues with Binary Ninja when it comes to analyzing the DSC. The initial loading of /usr/lib/system/libsystem_c.dylib isn't too terrible, but further loading of images seems to get progressively slower. Depending on the image being loaded analysis phase 1 can have 40,000+ items to get through and thats with loading a 2nd image (the first one being libsystem_c.dylib). Further loading of images seems to increase the amount by 10s of thousands more each time, again depending on the image. I'm not sure if this just keeps going up and up, because there's a number of crashes making it harder to load more than 3 or 4 images. This may not actually be a problem and just be the reality of analyzing DSC but it certainly exacerbates the issue.
Something I've noticed is that analysis seems to only ever be using a single CPU core. Binary Ninja CPU utilisation during this time ranges from 100%-200%, where 100% is the equivalent to an entire CPU core being used. Often it is closer to 100%. So its likely analysis is single threaded which I guess is probably where a lot of performance is lost. With the increasing number of items to do in phase 1 each time a new image is loaded, the time to load an image quickly becomes problematic. It maybe infeasible to load something like 100 images from DSC, which should be more than possible.
When I do analysis of a standalone library extracted from DSC using ipsw it completes extremely quickly with analysis mode on control flow and still very fast when its on full. For instance a standalone copy of /usr/lib/system/libsystem_c.dylibtakes 3 seconds to do control flow analysis on with an Apple M2 Ultra, and 15 seconds with analysis mode on full. By comparison the initial loading analysis of /usr/lib/system/libsystem_c.dylib when analyzing DSC in Binary Ninja, takes 2 minutes with analysis mode on control flow and 4 on full. Which makes sense if you're doing single core vs multi core analysis (for context the Apple M2 Ultra has 16 performance cores and 8 efficiency cores). That may not seem too bad but many of the core libraries take 10s of minutes to analyze on control flow mode when loaded as an image from DSC.
Expected Behavior:
I would expect that loading an image in DSC should be similar to analyzing that same library as an individual binary once it has been extracted from DSC using ipsw. I recognise that performance won't be quite the same due to the tight interlinking of data in DSC, but currently it feels far from where it should be at.
Binary:
Extract the DSC from any iOS 18+ IPSW. Not sure if its an iOS 18 related issues, its just the ones I've been testing on.
I'm also finding DSC analysis is blocking the UI alot. Opening a new tab and loading another binary whilst analysis is ongoing causes Binary Ninja to freeze for extended periods.
Version and Platform (required):
Bug Description: There seems to be performance issues with Binary Ninja when it comes to analyzing the DSC. The initial loading of
/usr/lib/system/libsystem_c.dylib
isn't too terrible, but further loading of images seems to get progressively slower. Depending on the image being loaded analysis phase 1 can have 40,000+ items to get through and thats with loading a 2nd image (the first one beinglibsystem_c.dylib
). Further loading of images seems to increase the amount by 10s of thousands more each time, again depending on the image. I'm not sure if this just keeps going up and up, because there's a number of crashes making it harder to load more than 3 or 4 images. This may not actually be a problem and just be the reality of analyzing DSC but it certainly exacerbates the issue.Something I've noticed is that analysis seems to only ever be using a single CPU core. Binary Ninja CPU utilisation during this time ranges from 100%-200%, where 100% is the equivalent to an entire CPU core being used. Often it is closer to 100%. So its likely analysis is single threaded which I guess is probably where a lot of performance is lost. With the increasing number of items to do in phase 1 each time a new image is loaded, the time to load an image quickly becomes problematic. It maybe infeasible to load something like 100 images from DSC, which should be more than possible.
When I do analysis of a standalone library extracted from DSC using ipsw it completes extremely quickly with analysis mode on
control flow
and still very fast when its onfull
. For instance a standalone copy of/usr/lib/system/libsystem_c.dylib
takes 3 seconds to docontrol flow
analysis on with an Apple M2 Ultra, and 15 seconds with analysis mode onfull
. By comparison the initial loading analysis of/usr/lib/system/libsystem_c.dylib
when analyzing DSC in Binary Ninja, takes 2 minutes with analysis mode oncontrol flow
and 4 onfull
. Which makes sense if you're doing single core vs multi core analysis (for context the Apple M2 Ultra has 16 performance cores and 8 efficiency cores). That may not seem too bad but many of the core libraries take 10s of minutes to analyze oncontrol flow
mode when loaded as an image from DSC.Expected Behavior: I would expect that loading an image in DSC should be similar to analyzing that same library as an individual binary once it has been extracted from DSC using ipsw. I recognise that performance won't be quite the same due to the tight interlinking of data in DSC, but currently it feels far from where it should be at.
Binary: Extract the DSC from any iOS 18+ IPSW. Not sure if its an iOS 18 related issues, its just the ones I've been testing on.