SIGSEGV: Xcode apple silicon: ipsw dyld split -b 23C54 -c dyld_shared_cache_arm64e

[MarkyMarcus]

What happened?

% ipsw dyld split -b 23C54 -c dyld_shared_cache_arm64e                    
   • Splitting to /Users/user/Library/Developer/Xcode/iOS DeviceSupport/26.2 (23C54) arm64e
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x8 pc=0x105aa6ed0]

goroutine 1 [running]:
github.com/blacktop/ipsw/pkg/dyld.Split({0x16b14f9a4, 0x18}, {0x1400f026eb0, 0x49}, {0x0?, 0x0?}, 0x1)
	github.com/blacktop/ipsw/pkg/dyld/split.go:135 +0x1f0
github.com/blacktop/ipsw/cmd/ipsw/cmd/dyld.init.func50(0x140005f5000?, {0x140005614c0, 0x1, 0x106489671?})
	github.com/blacktop/ipsw/cmd/ipsw/cmd/dyld/dyld_split.go:128 +0x524
github.com/spf13/cobra.(*Command).execute(0x1085d9900, {0x14000561480, 0x4, 0x4})
	github.com/spf13/[email protected]/command.go:1015 +0x7d4
github.com/spf13/cobra.(*Command).ExecuteC(0x1085cbba0)
	github.com/spf13/[email protected]/command.go:1148 +0x350
github.com/spf13/cobra.(*Command).Execute(...)
	github.com/spf13/[email protected]/command.go:1071
github.com/blacktop/ipsw/cmd/ipsw/cmd.Execute()
	github.com/blacktop/ipsw/cmd/ipsw/cmd/root.go:76 +0x24
main.main()
	github.com/blacktop/ipsw/cmd/ipsw/main.go:27 +0x1c

Error with non FAT dsc_extractor. Works fine on universal xcode.

% file /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/usr/lib/dsc_extractor.bundle
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/usr/lib/dsc_extractor.bundle: Mach-O 64-bit bundle arm64e

How can we reproduce this?

Run command with apple silicon xcode.

ipsw version

627, 643

Search

• [x] I did search for other open and closed issues before opening this

Code of Conduct

• [x] I agree to follow this project's Code of Conduct

Additional context

No response

[blacktop]

@supervacuus ?

[supervacuus]

Hi @blacktop 👋

Do you think this is related to my recent change? Because I had a quick look at the code, and I didn't remove any relevant nil or err checks. However, given that I couldn't relate the source line of the leaf frame to the current master (or any of the recent changes), I had a quick look at ipsw version 3.1.627 (as mentioned in the issue) and line 135 in the Split() implementation points to the following code:

https://github.com/blacktop/ipsw/blob/cb138b0bc449e927515485e2afdd6c671375a980/pkg/dyld/split.go#L130-L138

Which also exists in the latest version on line 153.

Given that this triggers only with non-FAT dsc_extractor bundles, the issue is likely that when err is not nil, fat is always nil:

https://github.com/blacktop/go-macho/blob/1542d7b9be81edd7329d023401395aebafd519b1/fat.go#L145-L157

since the first error handling check explicitly excludes ErrNotFat, we must check fat not to be nil whenever we access it in the code below. Of course, this is only the baseline check, since we can fall back on a default version you set. It might be better to fall back on macho.Open() once we know that this wasn't a fat bundle.

[supervacuus]

Created two PRs: one that just minimally checks the fat handle before dereferencing it for version access. One that falls back on slim Mach-O loading.

[blacktop]

Hi @blacktop 👋

Do you think this is related to my recent change? Because I had a quick look at the code, and I didn't remove any relevant nil or err checks. However, given that I couldn't relate the source line of the leaf frame to the current master (or any of the recent changes), I had a quick look at ipsw version 3.1.627 (as mentioned in the issue) and line 135 in the Split() implementation points to the following code:

ipsw/pkg/dyld/split.go

Lines 130 to 138 in cb138b0

fat, err := macho.OpenFat(dscExtractor.Libname) if err != nil && err != macho.ErrNotFat { return fmt.Errorf("failed to open %s: %v", dscExtractor.Libname, err) } extVer := "1040.2.2.0.0" if fat.Arches[0].SourceVersion() != nil { extVer = fat.Arches[0].SourceVersion().Version.String() } fat.Close() Which also exists in the latest version on line 153.

Given that this triggers only with non-FAT dsc_extractor bundles, the issue is likely that when err is not nil, fat is always nil:

https://github.com/blacktop/go-macho/blob/1542d7b9be81edd7329d023401395aebafd519b1/fat.go#L145-L157

since the first error handling check explicitly excludes ErrNotFat, we must check fat not to be nil whenever we access it in the code below. Of course, this is only the baseline check, since we can fall back on a default version you set. It might be better to fall back on macho.Open() once we know that this wasn't a fat bundle.

@supervacuus my apologies, it was very late. I should have done my due diligence first before pinging you. I just saw it was related to the ipsw dyld split and jumped to conclusions. 😞

Thank you SO much for taking the time to dig into this ❤️ I'll take a look at your PRs now.

[blacktop]

merged #981 which should fix this issue 👍