应用签名后崩溃求助：Code Signature Invalid错误排查

问题背景 #

未签名的应用包可正常运行，使用codesign签名后启动即崩溃，崩溃报告显示EXC_CRASH (SIGKILL (Code Signature Invalid))，终止原因Namespace CODESIGNING, Code 2。旧版本用相同签名流程无问题，新版本引入新框架且源码大量改动，但未签名时运行正常。

崩溃报告关键信息 #

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process:               bla [1386]
Path:                  /Users/USER/Desktop/*/bla.app/Contents/MacOS/bla
Identifier:            firma.bla
Version:               1.2.572 (1.2.572)
Code Type:             X86-64 (Native)
Parent Process:        launchd [1]
User ID:               504

Date/Time:             2023-11-13 14:51:17.7531 +0100
OS Version:            macOS 12.5 (21G72)
Report Version:        12
Anonymous UUID:        1B6A...

Sleep/Wake UUID:       1588...

Time Awake Since Boot: 4500 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGKILL (Code Signature Invalid))
Exception Codes:       0x0000000000000001, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace CODESIGNING, Code 2 

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
...

已执行操作 #

• 未签名应用可正常运行；
• 签名命令：

  % codesign --no-strict --force --timestamp --options=runtime --entitlements "bla.entitlements" --sign "Developer ID Application: ..." "bla.app/Contents/MacOS/bla"
  % codesign ... "bla.app"
  

• 签名验证结果正常：

  % codesign --verify --verbose bla.app
  bla.app: valid on disk
  bla.app: satisfies its Designated Requirement
  

• 启动即崩溃：

  % ./bla.app/Contents/MacOS/bla
  zsh: killed     ./bla.app/Contents/MacOS/bla
  

排查方向 #

1. 检查新引入框架的签名状态 #

新版本新增的框架可能未被正确签名，或本身存在签名问题：

• 逐个校验Contents/Frameworks下的所有框架：

  codesign --verify --verbose=4 bla.app/Contents/Frameworks/xxx.framework
  

• 若框架未签名或签名无效，需先单独签名每个框架，再签名整个应用包。

2. 验证嵌入权限与配置文件的一致性 #

虽然对比了entitlements文件，但实际签名嵌入的权限可能存在差异：

• 提取已签名应用的权限并对比：

  codesign --display --entitlements - bla.app > signed_entitlements.plist
  diff signed_entitlements.plist bla.entitlements
  

• 检查新版本是否需要新增权限（如隐私权限、沙箱权限），而旧配置未覆盖。

3. 排查Hardened Runtime限制 #

使用--options=runtime启用了Hardened Runtime，新版本代码可能触发了Runtime限制：

• 查看系统日志中的详细签名错误：

  log show --predicate 'process == "bla"' --info --debug --last 10m
  

• 临时去掉--options=runtime重新签名测试，确认是否为Hardened Runtime导致。若恢复正常，再逐步排查代码中是否存在动态注入、内存修改等被阻止的操作。

4. 检查应用包内所有可执行文件的签名完整性 #

签名后文件被篡改，或包内存在未签名的可执行文件：

• 使用spctl进行更严格的完整性校验：

  spctl --assess --verbose --type execute bla.app
  

• 遍历包内所有可执行文件并验证签名：

  find bla.app -type f -perm +111 -exec codesign --verify --verbose {} \;
  

5. 核对新旧版本的签名流程细节 #

新版本应用结构可能有变化，导致签名顺序或覆盖范围出错：

• 对比新旧版本的应用包结构，检查是否新增Contents/PlugIns、Contents/XPCServices等目录，这些目录下的可执行文件需单独签名。
• 确认签名顺序：先签名所有嵌套可执行文件（框架、插件、辅助工具），最后签名整个应用包，避免嵌套文件的签名被覆盖。

6. 测试不同的签名参数组合 #

• 去掉--no-strict参数重新签名，严格模式可能暴露隐藏的签名问题；
• 暂时移除--timestamp参数测试，排除时间戳服务器异常的影响。

临时验证方法 #

若怀疑是Hardened Runtime导致，可先关闭它签名测试：

codesign --force --entitlements "bla.entitlements" --sign "Developer ID Application: ..." "bla.app/Contents/MacOS/bla"
codesign --force --sign "Developer ID Application: ..." "bla.app"

若此时应用正常运行，再逐步开启Hardened Runtime并排查具体限制项。

内容的提问来源于stack exchange，提问作者Sinatr