search

indygreg / apple-platform-rs

Rust crates supporting Apple platform development
565 stars 38 forks source link

Can't sign `lib_burst_generated.bundle` within macOS app #95

Closed markshep-wbg closed 10 months ago

markshep-wbg commented 10 months ago

I'm working on a macOS app made with Unity. When making a build Unity generates a macOS app that's been adhoc signed and I want to sign that with a Apple-issued certificate, ultimately a "Developer ID Application" distribution certificate ready for notarization, but for now I'm just using an "Apple Development" certificate.

When signing the app with rcodesign it appears to work, but running codesign --verify --verbose=2 whatever.app on the app shows that the signature on the file Contents/Plugins/lib_burst_generated.bundle within the app is invalid. This file gets generated by Unity using its Burst compiler.

I've attached a minimal reproduction case with a cut-down app containing only an executable, Info.plist and lib_burst_generated.bundle along with a shell script that does the signing, signature diffing and verification. To make this work for you the shell script will need the IDENTITY variable setting to an identity that has a corresponding certificate & private key in your keychain and that also needs to have been exported to a .p12 file alongside the script with the basename of the file being the identity.

I'm using the official 0.23.0 release on macOS.

Here's the reproduction case: test.tar.gz

And here's the output I get on my machine when running the script:

Signing with codesign
---------------------

TrivialProject.app/Contents/Plugins/lib_burst_generated.bundle: replacing existing signature
TrivialProject.app/Contents/Plugins/lib_burst_generated.bundle: signed Mach-O universal (x86_64 arm64) [lib_burst_generated]
TrivialProject.app: replacing existing signature
TrivialProject.app: signed app bundle with Mach-O universal (x86_64 arm64) [com.DefaultCompany.TrivialProject]

Signing with rcodesign
----------------------

registering signing key
automatically registered Apple CA certificate: Apple Worldwide Developer Relations Certification Authority
automatically registered Apple CA certificate: Apple Root CA
using time-stamp protocol server http://timestamp.apple.com/ts01
automatically setting team ID from signing certificate: TJXK3JV9VB
signing TrivialProject.app in place
signing bundle at TrivialProject.app
signing bundle at TrivialProject.app into TrivialProject.app
signing Mach-O file Contents/PlugIns/lib_burst_generated.bundle
creating cryptographic signature with certificate Apple Development: Mark Sheppard (CJ8VWSTTKT)
creating cryptographic signature with certificate Apple Development: Mark Sheppard (CJ8VWSTTKT)
signing main executable Contents/MacOS/TrivialProject
creating cryptographic signature with certificate Apple Development: Mark Sheppard (CJ8VWSTTKT)
creating cryptographic signature with certificate Apple Development: Mark Sheppard (CJ8VWSTTKT)

Diffing signatures
------------------

-rw-r--r-- 1 mark.sheppard staff 46715 Nov  6 18:35 diff

Checking codesign
-----------------

--prepared:/Users/mark.sheppard/test/codesign/TrivialProject.app/Contents/PlugIns/lib_burst_generated.bundle
--validated:/Users/mark.sheppard/test/codesign/TrivialProject.app/Contents/PlugIns/lib_burst_generated.bundle
codesign/TrivialProject.app: valid on disk
codesign/TrivialProject.app: satisfies its Designated Requirement

Checking rcodesign
------------------

rcodesign/TrivialProject.app: nested code is modified or invalid
file modified: /Users/mark.sheppard/test/rcodesign/TrivialProject.app/Contents/PlugIns/lib_burst_generated.bundle
indygreg commented 10 months ago

Thank you for the bug report and going the extra mile to code up a shell script to reproduce the failures! This should hopefully be pretty easy to track down.

On first glance, there are several subtle differences in the signatures. But the one that stands out as a likely cause of the problem is this:

     - '    <key>PlugIns/lib_burst_generated.bundle</key>'
     - '    <dict>'
     - '      <key>cdhash</key>'
     - '      <data>'
-    - '      1W5f4lvSjOk4fusuqNA/5Q8aHFs='
+    - '      zVctgYO3aNANxB/j0C73bLuSfL4='
     - '      </data>'
     - '      <key>requirement</key>'
-    - '      <string>cdhash H"7c4057e8f2675c118297176b510749bbe2752d28" or cdhash H"d56e5fe25bd28ce9387eeb2ea8d03fe50f1a1c5b" or cdhash H"ceb50aaf5360712c177aa6fe36d071dbc1677b80" or cdhash H"ec47d4d25dd0911863ba12512f4d8c75c5090f09"</string>'
+    - '      <string>(cdhash H"cd572d8183b768d00dc41fe3d02ef76cbb927cbe") or (cdhash H"c12d14379b8f8d21c5e3f339ca8ee64dcf9628e4")</string>'
     - '    </dict>'

(It also appears rcodesign is adding entitlements where Apple's tooling isn't - that warrants investigation as well.)

indygreg commented 10 months ago

I modified the sign script to perform adhoc signing (changed IDENTITY to - and removed p12 arguments) and interestingly codesign says the adhoc bundle verifies! The rabbit holes grows deeper.

indygreg commented 10 months ago

There's a fix on the main branch to emit the missing cdhash values. I'm still verifying if additional work is needed.

indygreg commented 10 months ago

Your automated reproduction case keeps delivering new bugs. I love it.

I'm using a self-signed code signing certificate and noticed the derived designated requirements are different:

-        - 'designated(3): 0: (identifier "com.DefaultCompany.TrivialProject") and (anchor -1 H"e1c7216e46533c923b7cfc94e86c7043790b96e9");'
+        - 'designated(3): 0: (identifier "com.DefaultCompany.TrivialProject") and ((anchor apple generic) and ((certificate leaf[subject.CN] = "Apple Development: RSA Apple Development (test)") and (certificate 1[field.1.2.840.113635.100.6.2.1] /* exists */)));'

That anchor apple generic is wrong (the cert isn't signed by an Apple CA).

Out of curiosity, were you using a self-signed certificate?

Other variances:

And in Contents/PlugIns/lib_burst_generated.bundle:

I'll try to work through all of these this week to get things working. Clearly there's a handful of small bugs here.

indygreg commented 10 months ago

OK. Broke out each found issue into separate issues:

markshep-wbg commented 10 months ago

Out of curiosity, were you using a self-signed certificate?

No - it was an "Apple Development" certificate that I generated at https://developer.apple.com/account/resources/certificates/list.

indygreg commented 10 months ago

OK. A lot of the drift was due to codesign not preserving metadata by default. Once I corrected for that, we're down to #98 as the lone obvious reason why validation is failing. Hopefully fixing that will fix things.

indygreg commented 10 months ago

After chasing down every other lead, the issue appears to have to do with something I wasn't expecting: incorrect handling of the code signature in the __LINKEDIT segment. I'm still trying to track things down. But it kinda looks like we're softly corrupting the Mach-O binary somehow. Strangely, codesign says the individual Mach-O is signed correctly but validation in a bundle fails.

indygreg commented 10 months ago

Ok, I have some progress.

The original bundle / binaries you gave me have code signatures. If you strip the code signatures with codesign --remove-signature before signing, the rcodesign version validates. At least on the main branch.

I'm still trying to figure out why this is happening. IMO rcodesign's Mach-O is more pure than Apple's because we write 0s to EOF whereas Apple's can preserve the leftover signature data (if the signature is shorter than it was before).

But clearly there is a bug in our code somewhere because Apple is failing to validate the file. But I still haven't found the source of why the binary when in a bundle - and only when it is in a bundle - fails validation with Apple tooling. It is very perplexing to me.

indygreg commented 10 months ago

I was grasping at straws and tested signing a single arch Mach-O binary instead of a fat/universal binary and that works. So the bug has something to do with fat/universal Mach-O files. Good times.

indygreg commented 10 months ago

I think the problem has to do with the Mach file headers / __LINKEDIT segment / segment load commands not agreeing on the total file size. I think this is confusing Apple's (and likely other) Mach-O parsers. I'll look into this more tomorrow and hopefully get a fix in.

markshep-wbg commented 10 months ago

Thanks for the quick turnaround on this - 0.24.0 has got me past that problem. I'll open another issue for the next problem!