Export() creates malformed MachOs with bad Segment/Section boundaries

[blacktop]

          > > I understand that you are solving for a particular use case w/ Signal or something else, but there is an issue w/ the MachOs generated by the export.go `Export` func where it produces MachOs that IDA Pro doesn't like and complains about the Segment/Sections boundaries being wrong?

I'm happy to take a look! I'll have a bit less time (as you infer, my earlier contributions have been for use at Signal and were fixing gaps that blocked me) but I've greatly appreciated all the time you saved me by having this here, so happy to pay that forward a bit. Do you happen to have a useful repro/test case? I don't have IDA Pro, but if you could send me some simple binary you generated with Export and the same one made the official way, I can try to understand the difference.

So the most popular use case is to extract DYLIBs from the dyld_shared_cache to RE purposes (to make them actually linkable/usable would be a stretch goal for sure 😉 In ipsw I have a currently hidden command that does it. ipsw dsc extract It is called here (the second would be extracting KEXTs from the kernelcache, and I guess 3rd would be to make crazy malformed MachOs for security research 😈 )

A source of truth would be what XCode does which can be invoked by calling ipsw dsc split dyld_shared_cache docs this uses the same lib as XCode to pull out DYLIBs (this is to support lldb and does a minimal amount of fixups required) I wrote my Export function by looking at the source for the lib and REing it's binary etc. Found here

The ipsw dsc extract command goes WAY above and beyond what XCode does by rebuilding the MachO and adding the slide/rebase info, adding all the symbol (public/private) to the symtab etc etc described in the NOTE here

Incase you were unaware, the process of creating the shared_cache throws away a lot of information when combining the dylibs togethers to the process of 'extracting' them back out isn't trivial.

So far the best project to do this is https://github.com/arandomdev/DyldExtractor

My solution if also very close, I think only missing the ObjC runtime info fixups, but there is some error in the logic of the go-macho Export function that people have reported to me saying Ghidra/IDA complain about the MachO's header and Segment/Section boundaries??

So I guess the test rig would be using ipsw where you can clone go-macho to a folder next to it and uncomment this line in the go.mod to test out fixes etc.

Originally posted by @blacktop in #37 (comment)

[blacktop]

@jkt-signal I moved this into a NEW issue (as it doesn't really belong in your PR)

[lilili87222]

I found file created by command ipsw dsc extract is larger than those create by xcode and https://github.com/arandomdev/DyldExtractor/tree/master/src/DyldExtractor