Reading the developer docu about Code Signing, it says in section Digital Signatures and Signed Code:

To create a digital signature, the signing software computes a special type of checksum called a hash (or digest) based on a piece of data or code and encrypts that hash with the signer’s private key. This encrypted hash is called a signature.

To verify that signature, the verifying software computes a hash of the data or code. It then uses the signer’s public key to decrypt the signature, thus obtaining the original hash as computed by the signer. If the two hashes match, the data has not been modified since it was signed by someone in possession of the signer’s private key.

Signed code contains several digital signatures:

  • If the code is universal, the object code for each slice (architecture) is signed separately. This signature is stored within the binary file itself.
  • Various components of the application bundle (such as the Info.plist file, if there is one) are also signed. These signatures are stored in a file called _CodeSignature/CodeResources within the bundle.

After some fiddling, I know the following:

  • Inside the binary, I got the CodeDirectory (0xfade0c02) containing all SHA-1 hashes or checksums of the Bundle, e.g. Info.plist etc.
  • Inside the bundle, I got the _CodeSignature directory with the CodeResources file, which - as the cited paragraph above mentions - should contain all signatures. However, the CodeResources only contains base64 encoded SHA-1 hashes of several files.
  • Inside the binary, I've got some certificates, which I can extract using codesign -d --extract-certificates <binary> - generating codesign0, codesign1 etc. These certificates actually are CMS Signatures (0xfade0b01) that do contain certificate signatures. Looking up CMS I get Cryptographic Message Syntax, which is used to sign data.

Now the paragraph tells me that some hash has to be stored as a signature (encrypted hash) in the binary or in the CodeResources file.

I suspect that codesign uses one of the certificates/CMS Signatures to extract the public key, then decrypts a signature (encrypted hash) and compares the output to the original hash of a given file, e.g. Info.plist.

So my question is: Where is this signature (encrypted hash)? Is it the signature inside a certificate/CMS Signature? Or is it somewhere else?

  • "This signature is stored within the binary file itself." Is this not enough? Feb 15, 2016 at 21:49
  • 1
    @AndrewLarsson No, because if I can't find the encrypted hash, then there is no integrity for the signed data. The terminology is weird anyway - in one instance, the signature means the whole binary appendix with seal, certificates, requirements etc. In another, a signature means the encrypted hash. I am looking for the thing that proofs integrity and thus the latter.
    – polym
    Feb 15, 2016 at 23:40

1 Answer 1


Here is the basic test I made.

I have OS X 10.10 installed on a external disk under volume name "Steelhead3". I entered the following commands.

cd "/Volumes/Steelhead3/Applications/Utilities"
sudo codesign -fs - "Boot Camp Assistant.app"

I then made a copy of the folder "Boot Camp Assistant.app". Next, I edited the "/Volumes/Steelhead3/Applications/Utilities/Boot Camp Assistant.app/Contents/Info.plist" and made a small change regarding the model Macs that can make the Windows USB installer.

At this point I reran the following commands.

cd "/Volumes/Steelhead3/Applications/Utilities"
sudo codesign -fs - "Boot Camp Assistant.app"

From here I booted to Windows and used the Windiff.exe application to compare the files. I expected to see the change made to the "Info.plist" files, which I did. Also, the "/Volumes/Steelhead3/Applications/Utilities/Boot Camp Assistant.app/Contents/MacOs/Boot Camp Assistant" files appeared to have changed. Since this is a binary file, I first converted the before and after versions to hex characters, then Windiff.exe was used to find the differences. Below is the only differences.

enter image description here

It appears the only difference is a 20 byte change in the the executable binary file. I assume this is where the hash is stored. All other files were unchanged.

  • Thanks for caring :) - Though this doesn't answer the question with certainty, I will give you the 100 points before the clock runs out. Can you give me the two executable binaries before and after the change by any chance?
    – polym
    Feb 21, 2016 at 22:10
  • @polym: Are you asking me to email the binaries to you? Feb 21, 2016 at 22:30
  • If that is possible - sure :). I've temporarily added an email address to my profile description.
    – polym
    Feb 21, 2016 at 22:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .