codesign: add support for RUNTIME flag and minimum runtime version

[jkt-signal]

This change adds support for the RUNTIME code signature flag, which requires a hardened runtime and allows the binary to require a particular runtime version.

[blacktop]

are you running gofmt? this doesn't look aligned

[blacktop]

everything else looks good

[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?

As I mentioned I understand if you are doing this for work and don't have time, but these have been some VERY clean and well done PRs and was curious if you'd take a look.

It's something I've had on the TODO list for a long time and would really appreciate some help. I know the code is pretty gross and prob needs to be re-written :(

Either way, thanks for all your help w/ these PRs.

Cheers

[jkt-signal]

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.

As I mentioned I understand if you are doing this for work and don't have time, but these have been some VERY clean and well done PRs and was curious if you'd take a look.

glad you liked them 💜

It's something I've had on the TODO list for a long time and would really appreciate some help. I know the code is pretty gross and prob needs to be re-written :(

A fair amount of this could probably use a refactoring pass or two—I'm afraid I didn't improve things much in that respect with the last several contributions, I may do so with the next few.

[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

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.