You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
> > 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_cachedocs 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 NOTEhere
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.
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.
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 😉 Inipsw
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 supportlldb
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 hereThe
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 hereIncase 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 clonego-macho
to a folder next to it and uncomment this line in thego.mod
to test out fixes etc.Originally posted by @blacktop in #37 (comment)
The text was updated successfully, but these errors were encountered: