iOS 15.5 libMobileGestalt.dylib disassembly issues

[PoomSmart]

Describe the bug

Dead addresses for strings section:

Lots of strings (obfuscated MobileGestalt keys) are not referenced (compared to the x86_64 semi-equivalent of the binary):

Some instructions failed to be disassembled correctly (1910891C0 for example):

To Reproduce

1. iOS 15.5
2. dyld_shared_cache_arm64 of iPod9,1 (https://www.theiphonewiki.com/wiki/Firmware/iPod_touch/15.x)
3. Terminal command to reproduce.

Additional context Add any other context about the problem here.

[arandomdev]

Okay, as for the dead address, 0x1F4136FB8, that is an isa that points to ___CFConstantStringClassReference, this shouldn't effect anything, but I can look into pulling the class in much like how I would pull in a super classes.

As for the other two issues, I'm kind of at a lost, and can only blame libMobileGestalt.dylib. Before any processing, I found that the CFStrings are already like that. I do see some obfuscated strings, so maybe its just logging or unofuscated information that's mixed in?

And for that spot in the __text, it's originally just all zeros...?

[PoomSmart]

@arandomdev Alright, for some strings not being referenced, take XnXl4MhKZx3zRKvA7ZwIYQ as an example.

On x86_64, it is referenced in conjunction with sub_AD8C.

Inside sub_AD8C, it calls an internal function that I named as GetDeviceClass:

Which leads us to another internal function that I named GetDeviceClassInternal.

This same GetDeviceClassInternal exists in ARM version of libMobileGestalt.dylib but there's no such reference to it.

[PoomSmart]

For the spot in __text that you assumed to be zero, I will try to figure out what they are in x86_64 version of them.

[PoomSmart]

Here, I compare GetDeviceClass function between iOS 15.5 ARM and iOS 14.6 ARM

iOS 15.5 ARM (take a look at unk_1EBEBDA78):

iOS 14.6 ARM (take a look at stru_1DB800420)

iOS 14.6 one gets more complete information and doesn't lose __NSConcreteGlobalBlock.

[arandomdev]

Regarding XnXl4MhKZx3zRKvA7ZwIYQ, I was able to find it in the ARM version as well. I did this by first searching for the string, and then searching for the pointer to the string, which bought me to 0x1ebecf288.

For the block layout, it seems to be the same issue with the isa. In 14.6, it probably has the dyld_info_command with binding info, which allows your decompiler to override the old address (0x1f4130b58), with a generated stub address for __NSConcreteGlobalBlock and continue from there. Ideally I we could generating new binding info for newer images that don't have it, but that's been scoped for DyldExtractorC. Alternatively, we can try to pull in the isa, but that might be challenging because the block layouts are spread out in the __const section, and we wouldn't know if they're there or where are they.

[arandomdev]

Closing due to inactivity, let me know if you would like to reopen this.