Update marsigning-check.sh to cope with signed OS X MAR files
Now that the fix for #19410 (moved) landed our marsigning-check.sh script can't check the correctness of our MAR file signatures easily anymore as we use the SHA256 sums of the unsigned MAR files currently. We should adapt the script.
Activity
Trac:
Description: Now that the fix for #19410 (moved) landed outmarsigning-check.shscript can't check the correctness of our MAR file signatures easily anymore as we use the SHA256 sums of the unsigned MAR files currently. We should adapt the script.to
Now that the fix for #19410 (moved) landed our
marsigning-check.shscript can't check the correctness of our MAR file signatures easily anymore as we use the SHA256 sums of the unsigned MAR files currently. We should adapt the script.-
Here comes an update on where I am right now. Input is highly appreciated:
To strip the code signature off a macOS binary the following things must be done:
- Adjust the number of commands in the header (-
LC_CODE_SIGNATURE) - Adjust the size of the commands in the header (- 16 as this is the size of
LC_CODE_SIGNATURE) - Remove the
LC_CODE_SIGNATUREload command - Adapt
__LINKEDITsegment and respective load command
Doing 1)-3) is not overly complicated but adapting the
__LINKEDITsegment properly turns out to be tricky. During code signing the signature is appended to the__LINKEDITsegment. When stripping the signature some approaches just overwrite the signature with 0-bytes. That's not working for us as we want to restore the original binary to be able to compare the SHA256 sums. But, unfortunately, removing the signature from the__LINKEDITsegment is not enough to achieve this. That's because the segemt is padded to be aligned with0x10if needed before the signature gets added. E.g. here is the relevant part of a library's__LINKEDITsegment without the code signature:000034a0: 352f2f3a 35343136 00003234 00000000 ://5614542...... 000034b0: 00000000 ....While it looks like this after code signing:
000034a0: 352f2f3a 35343136 00003234 00000000 ://5614542...... 000034b0: 00000000 00000000 00000000 00000000 ................So, the question is: How do we find out how many padding bytes got added during the code signing (and need now get removed)? A naive approach looking at the above hexdump output would be: "Leave 16 0-bytes and remove the remaining ones as padding bytes". But that does not work as there are binaries where the
__LINKEDITsegment ends with less than 16 0-Bytes.Three ways forward come to mind:
a) Align the files to be code-signed to
0x10(+ adapt the size of the symbol table accordingly which is usually the last section in the__LINKEDITsegment) before starting the signing process. We are doing something similar with our .exe installers (see: #15539 (closed)) already which is working pretty well. Additionally, as we need to code-sign the binaries anyway one could argue it's perfectly fine to do the padding during the build.b) Find out if there is the amount of 0-bytes at the end of the
__LINKEDITsegment follows a pattern we could use to reliably strip the padding after removing the signature.c) Record the size (or laste X bytes or) of all OS X binaries we ship during the build and make that available. The script removing the signatures could then consult that information when stripping the signature. This might not work for incremental MAR files as expected. I have not checked that yet.
Thoughts? Better alternatives? I find a) scary, have no much hope for b) and dislike c) so far.
General material about code signing on macOS:
https://developer.apple.com/library/content/technotes/tn2206/_index.html
(This document has the following fun Q&A :) ):
I wrote some data to the Mach-O file before signing. Is that allowed? No. Do not tamper with Mach-O files, outside of using macOS build tools and Xcode workflows.Material about the Mach-O file format:
https://lowlevelbits.org/parsing-mach-o-files/ https://github.com/aidansteele/osx-abi-macho-file-format-reference
- Adjust the number of commands in the header (-
-
Replying to mcs:
Kathy and I cannot think of a better approach than a) or c). I like the elegance of a) but I wonder why Apple warns developers not to "tamper" with Mach-O files.
I think that's the usual "There be dragons!1!!" scaremongering. :) So, it might be a) then? Exciting!
-
Trac:
Parent: N/A to #18925 (moved) mentioned in issue #32895 (moved)
mentioned in issue tpo/applications/tor-browser-build#32895 (closed)
