DSCView::Init accesses potentially inexisting field when parsing platform

[droe]

Version and Platform (required):

• Binary Ninja Version: 4.2.6335-dev Personal (1828c7e4)
• OS: macOS
• OS Version: 14.5 (23F79)
• CPU Architecture: arm64

Bug Description:

DSCView::Init reads uint32_t platform from hardcoded offset 0xd8 of the dsc header. However, struct dyld_cache_header for older shared caches (say, iOS 10) is smaller than 0xd8 and does not include a platform field. When loading such a dyld shared cache, Binary Ninja fails to initialize DSCViewAlpha and logs a misleading error message showing a garbage platform value.

Steps To Reproduce:

1. Download ipsw for some old iOS version, say, iOS 10.3
2. Extract the dyld shared cache from the system volume dmg in the ipsw
3. Open the dyld shared cache in Binary Ninja
4. See that DSCViewAlpha failed to initialize with "unknown platform" and a garbage value read from outside of the header

Expected Behavior:

Ideally, load the shared cache with DSCView fully functional (happy to assist with testing).

At a minimum though, DSCView::Init should not read fields that do not exist in the header, and fail with a more self-explanatory error message such as "dyld shared cache format unsupported" or some such.

There is a trick to figure out the size of the header struct: Based on the assumption that the first mapping will immediately follow the header, we can look at mappingOffset and never read any header fields that extend beyond that offset.

Screenshots/Video Recording:

[Default] Unknown platform: 24576
[Default] BinaryView of type 'DSCViewAlpha' failed to initialize!

Binary:

See repro.

Additional Information:
Please add any other context about the problem here.

[0cyn]

This should be fixed as of the 5.0 release, we now default to iOS on unknown platforms.

[droe]

Still an issue with Binary Ninja 5.0 and an iOS 10 DSC; still seems to read and misinterpret header offsets that are not present in older DSC headers:

[SharedCache.View] Unknown platform: -1449099264
[Default] Failed to initialize view of type 'DSCView'. Generating default load settings.

[fuzyll]

What version of Binary Ninja 5.0 were you using? My understanding is that, for the stable version, we do not support DSCs from iOS 10 or below. We did, however, add preliminary support for it two days ago in e3bbd4f.

So, if this is still a problem for you with an iOS 10 DSC on latest dev, I think we should reopen this. And, if it is, some pointers on what device you're looking at would be great so we can try and replicate the problem on our end and get it fixed for you.

[droe]

I had been using both 5.0 stable as well as a dev build from before e3bbd4f. Love the improvements to DSC loading in latest dev!

The following code still reads an offset that does not exist in the DSC header for iOS 10 and earlier, and prints a garbage platform value in an error message:

	uint32_t platform;
	// NOTE: This entry only exists on ios 11 and later, older versions will just assume iOS.
	GetParentView()->Read(&platform, 0xd8, 4);

Defaulting to iOS works most of the time, but could conceivably select the wrong platform when offset 0xd8 outside of the header happens to contain one of the valid values for platform. A more robust fix would be to only read and interpret offset 0xd8 as platform if the DSC header field mappingOffset contains an offset >= the offset of the platform field. mappingOffset is already used as upper bound for the header size elsewhere in the DSC code.

I've opened PR #6777 with a fix that works for me with iOS 10 DSCs, e.g. 10.3.1 for iPhone SE or iPhone 7.