3. iOS签名机制
聊到iOS签名，很多人第一反应就是“证书、描述文件那一套”。没错，但问题是——为什么要有这些机制？说白了，苹果用这套体系解决一个核心问题：确保跑在设备上的代码，是经过授权的、没被篡改的。我刚开始做iOS逆向的时候，觉得签名就是个形式，直到自己写了个越狱插件尝试验证签名逻辑...嗯，当年踩的坑不少。
这一节，咱们把这些概念彻底捋清楚。
App ID：你的应用的身份证
App ID 就是一个应用的唯一标识。格式长这样：
com.example.myapp
它分为两部分：
- Team ID（前缀）：苹果分配给你的开发者账号的唯一ID，比如
ABCDE12345 - Bundle ID（后缀）：你自己定义的应用包名，一般用反向域名
完整的App ID就是 ABCDE12345.com.example.myapp。
重要：App ID 还分两种——Explicit App ID（明确ID）和 Wildcard App ID（通配符ID）。通配符用 * 结尾，比如 com.example.*，但要注意，通配符ID不能用于推送通知、iCloud等需要明确App ID的功能。
Team ID：你的开发者身份烙印
Team ID 是苹果分配给你开发者账号的唯一十位字符串。每个账号只有一个。我做过一个项目，客户把Team ID和Bundle ID搞混了，结果Provisioning Profile怎么都生成不对。记住：Team ID是绑在账号上的，不是绑在App上的。
怎么查？登录Apple Developer后台，“Membership”页就能看到。
小技巧：Xcode里也能看到 Team ID。打开 Keychain Access，在登录证书里找到你的开发证书，双击看“组织单位”字段——那就是 Team ID。
Entitlements：你的App有什么特权
Entitlements 是一份权限清单。它告诉系统：我的App能打开什么、能访问什么、能做什么。比如：
- iCloud 容器访问
- 推送通知
- App Groups 共享数据
- 钥匙串访问
- 健康数据
这份清单是一个 .entitlements 文件，内容像这样：
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>keychain-access-groups</key>
<array>
<string>$(AppIdentifierPrefix)com.example.myapp</string>
</array>
<key>com.apple.developer.icloud-container-identifiers</key>
<array>
<string>iCloud.com.example.myapp</string>
</array>
</dict>
</plist>
我见过不少新手在 Xcode Capabilities 面板里勾了一堆功能，结果签名时报错。为什么？因为 Entitlements 必须和 Provisioning Profile 里授权的权限一致。不一致就报错，没商量。
警告：别手动改 Entitlements 文件！除非你清楚每个 key 的含义。我曾经为了开一个私有API，强行加了个 entitlement，结果审核被拒。苹果对权限控制非常敏感，尤其是 com.apple.security.* 相关字段。
Provisioning Profile：签名的“通行证”
Provisioning Profile 是苹果给开发者签发的“授权文件”。它把以下几个东西绑定在一起：
- App ID
- 开发者证书（公钥）
- 设备UDID列表（开发模式）
- Entitlements 权限清单
说人话：这个文件告诉设备——“这个App，用这个证书签名，跑在这几台设备上，用这些权限，是合法的”。
Provisioning Profile 分两种：
| 类型 | 用途 | 设备限制 | 有效期 |
|---|---|---|---|
| Development | 开发调试 | 指定UDID的设备 | 1年 |
| Distribution | 发布到App Store或测试 | 无（App Store）或指定设备（Ad Hoc） | 1年 |
我在做企业签名分发的时候，最头疼的就是 Provisioning Profile 过期。一旦过期，所有已安装的App都会闪退。嗯，你没看错，是闪退。苹果对签名的时效性要求很严格。
App Store签名流程：从你构建到用户手机
整个流程可以拆成几步：
- 你在Xcode里构建App：生成可执行文件、资源包等。
- 签名：用你的开发/分发证书对App进行代码签名。这一步会生成一个签名，嵌入到
_CodeSignature目录下。 - 打包：生成 .ipa 文件。
- 上传到App Store Connect：用 Xcode 或 Transporter 上传。
- 苹果服务器重新签名：这里是一个关键点——你上传的App，苹果会用自己的分发证书重新签名。你原来的签名被替换掉了。
- 签名验证：苹果验证签名、Entitlements、App ID是否一致。
- 分发到用户设备：用户从 App Store 下载时，系统验证苹果的签名，没问题才安装。
这里有个容易忽略的点：你上传到App Store的App，苹果会做一次“签名剥离”。你的证书、描述文件信息会被移除，换上苹果的。所以，你在App Store下载的App，签名验证者是苹果，不是你。
思考题：越狱设备为什么能绕过签名？因为越狱后，系统层的签名验证钩子被替换了。设备不再检查签名，任何未签名或重签名的App都能跑。但要注意，这打破了苹果的安全模型，所有运行中的应用都不可信。
下面这张图展示了整个签名流程中核心组件的关系：
经验之谈：我在做企业级签名平台时，发现一个常见错误——Multiple Provisioning Profiles。一个App只能用一个Profile，但很多人会在Xcode里配置多个，导致签名时Apple会选择最匹配的那个，不一定是你期望的。我的做法是：每次构建前，先清除旧的Profile，只保留一个。
常见签名问题与排查
我整理了几个你一定会碰到的问题：
- “No matching provisioning profile found” —— Xcode找不到匹配的Profile。检查App ID和证书是否一致。
- “Failed to code sign” —— 签名失败。大概率是Entitlements里写了Profile没授权的权限。
- “App installation failed” —— 安装失败。设备UDID不在Profile里（开发模式）。
- “This app is damaged” —— 越狱设备安装未签名App常见提示。
警告：别在越狱设备上用企业证书签名做测试。企业证书被滥用会导致证书吊销。我之前处理过一个客户案例，他们的企业证书因为被用于上千台非授权设备，直接被苹果封了，所有已安装的App全部失效。修复成本极高。
最后说一句：签名这玩意儿，看着复杂，但理解了“绑定关系”之后就不难了。App ID定身份，证书定签名者，Provisioning Profile定授权范围，Entitlements定权限。四个东西绑在一起，才算一个合法的签名。