[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #20254 [Applications/Quality Assurance and Testing]: Update marsigning-check.sh to cope with signed OS X MAR files
#20254: Update marsigning-check.sh to cope with signed OS X MAR files
-------------------------------------------------+-------------------------
Reporter: gk | Owner: tbb-
| team
Type: enhancement | Status: new
Priority: Medium | Milestone:
Component: Applications/Quality Assurance and | Version:
Testing |
Severity: Normal | Resolution:
Keywords: tbb-gitian, TorBrowserTeam201701 | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by gk):
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:
1) Adjust the number of commands in the header (- `LC_CODE_SIGNATURE`)
2) Adjust the size of the commands in the header (- 16 as this is the size
of `LC_CODE_SIGNATURE`)
3) Remove the `LC_CODE_SIGNATURE` load command
4) Adapt `__LINKEDIT` segment and respective load command
Doing 1)-3) is not overly complicated but adapting the `__LINKEDIT`
segment properly turns out to be tricky. During code signing the signature
is appended to the `__LINKEDIT` segment. 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
`__LINKEDIT` segment is not enough to achieve this. That's because the
segemt is padded to be aligned with `0x10` if needed before the signature
gets added. E.g. here is the relevant part of a library's` __LINKEDIT`
segment 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 `__LINKEDIT` segment 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
`__LINKEDIT` segment) before starting the signing process.
We are doing something similar with our .exe installers (see: #15539)
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
`__LINKEDIT` segment 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
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20254#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs