（半翻译）篡改mac应用后，如何resign签名，重新获得mac系统的信任？

网上看到一篇帖子，觉得挺有意思，这里简要写一下它的目的、以及操作要点。

有时候会有需要，篡改别人的应用，达到自定义某些功能的目的。篡改应用后，有可能会被mac系统认为是不受信任的程序，会受到某些限制，例如访问每次keychain都需要输入密码，或者每次启动应用都会需要授权。

为了避开一些限制，一个方法就是，resign签名。
很多应用都有签名，而应用识别是否被篡改、来源是否可信，也是通过签名识别。当然，resign签名后，实质上来说它已经被认为是一个全新的应用了。

这里用到一个命令行工具，叫做codesign。

首先，如何查看一个应用原有的签名呢？
codesign -v /应用路径

例如，我查看Xcode的签名

codesign -v /Applications/Xcode.app/Applications/Xcode.app: resource envelope is obsolete (custom omit rules)

想要看签名的详细信息，可以codesign -dvvv /应用路径

codesign -dvvv /Applications/Xcode.appExecutable=/Applications/Xcode.app/Contents/MacOS/XcodeIdentifier=com.apple.dt.XcodeFormat=bundle with Mach-O thin (x86_64)CodeDirectory v=20200 size=242 flags=0x200(kill) hashes=3+5     location=embeddedHash type=sha1 size=20CDHash=a986ca9cae6d20daa530c2eb3ad9e29b4571ef7eSignature size=4169Authority=Apple Mac OS Application SigningAuthority=Apple Worldwide Developer Relations Certification AuthorityAuthority=Apple Root CAInfo.plist entries=33TeamIdentifier=59GAB85EFGSealed Resources version=2 rules=7 files=114Internal requirements count=2 size=212

---

要想resign一个应用，得有一个受系统信任的证书。由于这里是自己使用，因此可以直接在电脑上申请证书。

可以在

Keychain钥匙串->Certificate Assistant证书助手->Create a Certificate创建一个证书

，然后依次填写一些信息，即可创建一个自己的证书

创建好的证书会默认安装在Keychain中，可以设置证书为Always trust。

在keychain中选中证书，右键选择“Get Info”Info页面有一个Trust选项，下面有一个三角，点击展开三角在code signing项，选择Always trust关闭Info页面，系统会弹出密码框，输入密码确认修改。OK了

---

已经准备好了自己的证书，下一步就给应用修改签名

codesign -f -s  证书名  /应用路径

如果顺利的话，就修改签名成功了。

---

原文摘抄
地址

Introduction

As people know (or are learning), Leopard marks the start of code signing, which is a security measure designed to help keep programs from being modified on disk or in memory without our knowledge. It will also allow one to verify that a program came from who it says it came from. (i.e. that copy of Photoshop on your hard drive really came from Adobe, or that copy of Office really came from Microsoft, assuming the developer has gotten a code signing certificate from an issuer that verifies their identity). It is also possible for smaller developers (i.e. freeware and shareware) to “self-sign” their code which allows for full benefits of code signing as far as the system is concerned, but there would be no way to independently verify who the program came from. (Independently verified code signing certificates ain’t cheap– 299−699, depending on who you get them from).

During the transition period, Leopard is very lenient towards unsigned code, but it is less lenient towards signed code with broken or invalid signatures. As it stands, code needs to be signed to work properly with the new firewall and with the Parental Controls feature. If a program is not signed, the system will sign it with an “ad-hoc” signature when one configures the firewall or Parental Controls to allow or deny access to that program. As time goes one, more and more system facilities will begin to require code to be signed (presumably this will happen with point-releases or security updates of the operating system). A program with a broken or invalid signature (i.e. one that has been modified) will not have automatic access to the keychain, for example, and one will be prompted for keychain access each time the program runs.

All of the applications that come with Leopard have been signed by Apple. This means that if the signature is valid, the application has not been modified, and you can verify that the program actually came from Apple. What does this mean for tinkerers, the people who like to modify programs to change icons or edit menus, plist files? It means that making any modifications will invalidate the signature, and the programs will not behave properly under certain circumstances. For example, if Mail’s signature is invalidated, you will be prompted for your password every time it wants to access your keychain. There will be no way to tell it to always allow access. Later on, as Leopard gets less lenient about signed code, the system may prompt you each time you execute a program with an invalid signature. (Imagine having to answer a dialog box like, “This application has an invalid signature. Do you wish to run this application anyway?” each and every time you run a program, with no way to turn it off).

So, if you like to tinker with your applications, how do you avoid the scenarios described above? You either don’t modify the apps, or you re-sign the modified app with a new signature. The modified application won’t identify itself as coming from Apple any more, but it regains full status as a signed application with a valid signature. This assumes, of course, that the program doesn’t check to see if the signature has changed. To my knowledge, Apple hasn’t done this with any of their apps, but some third party developers have done this.

When an application is signed, the system uses the certificate to apply a cryptographic signature to the binary executable file (usually in the MacOS folder inside the application’s bundle). Each type of code in a universal binary (PPC 32-bit, PPC 64-bit, Intel 32-bit, Intel 64-bit) is signed separately. Each of the resources in the Resources folder is checksummed and the Resources folder is “sealed,” such that any changes to the files inside will be detected. Sub-bundles (i.e. “helper applications,” plug-ins, etc). contained within an application’s bundle are not signed with the application, but must be signed separately. This is important to know when modifying things like iTunes and Mail, for example.

The following posts will describe how to verify an application’s signature, how to obtain a code signing certificate, and how to replace Apple’s signature with your own if you make your own modifications to Apple’s applications. Note that it is not necessary to have the Developer Tools (XCode) installed to do any of this, but it is recommended that they be there (you’ll probably already have them installed if you’re a tinkerer).

Verifying an Application’s Signature

Leopard includes a command line tool, “codesign” that allows you to verify signatures, sign applications that are unsigned, or re-sign applications. From the command line, type “man codesign” for complete instructions.

Verifying an application’s signature is simple. From the command line, type:

codesign -v /path/to/application

The easiest way to do this is to type the “codesign -v ” (without the quotes), press space, and then drag the application file to the Terminal window, which will automatically enter the path to the application for you.

If the signature is valid, the program will exit without printing anything. If the code has been modified (or if a .plist file has been changed), it will say:

code or signature modified.

If a sealed resource has been changed, it will say:

a sealed resource is missing or invalid.

You can examine the signature information by doing the following:

codesign -dvvvv /path/to/application

The system will display the following (for example, Safari)

Executable=/Applications/Safari.app/Contents/MacOS/Safari
Identifier=com.apple.Safari
Format=bundle with Mach-O universal (i386 ppc7400)
CodeDirectory v=20001 size=7521 flags=0x0(none) hashes=370+3 location=embedded
Signature size=4064
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Info.plist entries=23
Sealed Resources rules=9 files=283
Internal requirements count=0 size=12

Obtaining a Code Signing Certificate

In order to sign applications, you need to have a code signing certificate in your keychain. You can purchase one from one of the certificate authorities, such as Verisign, Thawte, or RSA, but they’re fairly expensive that way.

If you’re doing it just to modify applications for your own use (or you’re a freeware or shareware developer who doesn’t want the independent verification), you can generate your own certificate to use. This is done using the Keychain Access application, in the Utilities folder. Here’s how:

1. Open Keychain Access.
2. Go to the Keychain Access menu, and under Certificate Assistant, choose Create a Certificate
3. Name your Certificate. (I recommend using something other than your first and last names)
4. For Type, choose Self Signed Root.
5. Make sure Let me override defaults is checked and click Continue.
6. Under Serial Number, use a random number. Just make sure there is no other certificate on your system with the same name and serial number
7. Give yourself a sufficiently long validity period. For a little over 5 years, use 2000 days. For almost 11 years, choose 4000 days.
8. Under Certificate Type, choose Code Signing, and click Continue.
9. Enter your personal information on the next screen. Have fun with Organization and Organizational Unit. After all, this is for your own personal use. Don’t use “Apple.” I myself used something like “Orange Computer” for Organization and “Hacking Department” for Organizational Unit. Click Continue when all has been filled out.
10. For Key Pair Information, accept the defaults and click Continue.
11. For Key Usage Extension, accept the defaults and click Continue.
12. For Extended Key Usage Extension, accept the defaults and click Continue.
13. For Basic Constraints Extension, accept the defaults and click Continue.
14. For Subject Alternate Name Extension, accept the defaults and click Continue.
15. Use your “login” keychain to store the certificate and click Continue.
16. Now you have to set your certificate to be “trusted.”
17. Go to your keychain, and right click (control click) on the new certificate you made and choose Get Info.
18. Open the triangle next to Trust.
19. Go down to Code Signing, and choose Always Trust.
20. Close the box. The system will ask for your admin password. Enter it and click OK.

You’re done, and you have a certificate you can use for signing your own code, or re-signing someone else’s code that you’ve modified or tinkered with.

Re-Signing a Modified Apple Application

Before you re-sign an application that you’ve modified, make sure you’re done with the modifications, because otherwise you’ll have to sign it again. Once you’ve re-signed the application, it will look to the system like a different application than the one Apple provided. For this reason, make sure you do this on a copy of the Apple-supplied application. Besides, you’ve got to make sure that an update from Apple doesn’t screw up your modifications, or vice versa.

Re-signing the application is quite simple.

1. Open Terminal.
2. Type “codesign -f -s (name of certificate) /path/to/application

(name of certificate) is the name you gave your certificate in the creating a certificate section. Remember that you’ll have to escape any spaces or other nonstandard characters that appear. For example, if your certificate were called “Harry Potter’s Certificate,” you would use “Harry\ Potter\’s\ Certificate.” As an alternative, you can use a portion (substring) of the certificate’s name as long as that portion does not appear anywhere else in your keychain. So you could type “Potter” instead of the full string with escaped characters.

Once again, you can type “codesign -f -s (name of certificate) ” and drag the application to be resigned from the Finder to the Terminal window to enter the path name if you don’t want to type it out yourself.

When you’re done, you can use “codesign -dvvvv /path/to/application” to verify that the signature has changed.