这篇是重签名系列的第三篇。前面两篇把签名机制、证书体系和工具环境都铺开了，这篇不再重复讲概念，直接进入正题：拿一份IPA包，从解包清理、配置描述文件、替换Entitlements，到重新签名、打包、装回真机，完整跑一遍流程。做完这一遍，你对codesign、ldid、Provisioning Profile这套东西的理解，会和只看文章完全不一样。
动手之前还是要先把边界说清楚：重签名，只适合处理你有权处理的App。自己开发的测试包、拿到了源码并确认可以二次分发的项目、公司授权你测试的包，都属于合理范围；未经授权就拿某个即时通讯App去重签名再装到自用设备上，这已经超出技术讨论的边界了。下面的例子统一叫“目标App”，你实操时换成自己手上的包就行。
1. 重签名到底在解决什么问题
1.1 一次签名校验的完整旅程
iOS 系统从硬件到系统再到每个App，是一条完整的信任链。App 安装到真机时，系统会检查三样东西：代码签名是否完整、描述文件是否包含这台设备的UDID、Entitlements 是否和签名信息一致。启动App时，系统还会重新校验一次可执行文件里的_CodeSignature目录，比对整段 Mach-O 文件的哈希值。只要二进制改过一个字节、Info.plist 改过内容、Framework 动过手脚，签名立刻失效。
用生活里的场景来类比：签名就像快递包裹上的封条。封条一旦贴上，箱子里任何东西动过，封条状态就不对了。重签名，本质上就是拆掉旧封条、贴上新封条，让整个包裹看起来又是“原装”的。
这套机制保证了App从签名到安装再到启动的全程可追溯，但也带来一个现实问题：只要App有任何改动，签名就必须重做。不管你是给测试包换一台设备，还是往App里注入一个动态库做分析，绕不开的都是“重签名”这三个字。
1.2 重签名技术最常用的几个现实场景
- 持续开发场景：开发证书过期、测试设备不在描述文件里、企业证书被回收，都需要用新证书重新签名。
- 测试分发场景：从同事或合作方手里拿到一份IPA，但对方没有把你这台设备的UDID加进描述文件，你就得用自己的开发证书重新签。
- 分析调试场景：要往目标App里注入动态库，或者在真机上调试某个没有源码的包，必须把签名换成自己的证书，并配合
get-task-allow权限。 - 功能验证场景：想验证某个App在特定系统版本上的兼容表现，手里只有旧签名包，也可以靠重签名装到测试机上。
每个场景都有一个共同前提：你对该App有明确的操作授权。没有这个前提，后续所有步骤都失去意义。
2. 动手前的准备：证书、描述文件与工具链
2.1 先把三个“身份信息”彻底弄明白
重签名之所以容易翻车，是因为很多人分不清证书、描述文件、Entitlements 三者各自负责什么。
证书确认的是“你是谁”。它由本机钥匙串和后台开发者账号体系共同持有，是重签名的身份凭证。证书有名字，比如iPhone Developer: Your Name (TEAMID)，这个括号里的TEAMID会出现在最终签名结果的Authority字段里。
描述文件确认的是“你允许装到哪”。一份描述文件里绑定了App ID、证书、设备UDID、以及一组Entitlements。系统校验时，设备不在UDID列表里就无法安装，证书和签名不一致也无法安装，App ID对不上同样无法安装。
Entitlements 确认的是“App能干什么”。它是一份权限清单，比如get-task-allow（是否允许调试）、keychain-access-groups（钥匙串分组）、aps-environment（推送环境）。描述文件里也会内嵌一份Entitlements，重签名时必须保证签名信息里的Entitlements和描述文件能对齐。
动手之前，先用下面命令确认你手头的签名身份：
security find-identity -v -p codesigning运行结果通常是：
1) 1A2B3C4D5E6F... "iPhone Developer: Your Name (TEAMID)" 1 valid identities found只有能看到证书并且状态是valid，后面才谈得下去。
2.2 工具链清单与各自分工
重签名的工具并不复杂，但每一样都有自己的定位：
codesign：所有签名工作的核心，苹果官方提供的命令行签名工具。ldid：用于查看和修改Mach-O的签名信息，尤其是提取Entitlements。它不能替代真机上的正式签名，但做前期分析和权限修改非常方便。plutil和PlistBuddy：查看、修改Info.plist和Entitlements配置。unzip/zip：解包、打包IPA。ideviceinstaller：把重签后的IPA安装到真机。codesign -d：查看现有签名信息，排查签名问题的利器。
这套工具在大多数开发机上都能直接上手，不需要额外搭建复杂环境。
2.3 准备一份合规的IPA包
重签名需要一个“来源明确”的IPA包。最干净的来源是自己的Archive导出包，在Xcode的 Organizer 里选择对应版本，Export 成 Development 或 Ad Hoc IPA，这样包本身就带着你手头的证书和描述文件。后面操作时，可以把原来的签名信息作为参考，对比重签前后的差异。
如果你是从别人手里拿到的测试包，至少要确认这包确实允许你处理。来源不明的包，直接跳过，不值得为省这点时间惹麻烦。
3. 目标App重签名实操：从解包到真机安装
3.1 解包、检查目录结构与旧签名
收到IPA包后，第一步永远是解包，别急着签。
unzip Target.ipa -d Target cd Target/Payload ls -la你会看到类似TargetApp.app的目录，里面才是真正的App内容。标准结构大致是：
TargetApp.app/ ├── TargetApp # 主可执行文件 ├── Info.plist ├── embedded.mobileprovision ├── Frameworks/ # 可能存在的动态库 ├── PlugIns/ # 可能存在的Extension └── _CodeSignature/ # 旧签名目录，后面要清掉在解包之后，先用codesign -d看一眼原包的签名信息：
codesign -dvv TargetApp.app 2>&1 | grep -E 'Identifier|Authority|TeamIdentifier'这个输出会告诉你原包的Bundle ID、证书名称、Team ID。记录下Bundle ID，它是后续匹配描述文件的关键。
接着把旧签名目录删掉，同时把旧的描述文件也清出去：
rm -rf TargetApp.app/_CodeSignature rm -f TargetApp.app/embedded.mobileprovision这一步是必要的。旧签名不删除，新签名叠加在上面，系统校验时会产生“签名信息不一致”的错误。
3.2 修改Info.plist与处理Bundle ID
这一步要看你的描述文件App ID到底匹配不匹配。如果你手里描述文件的App ID是com.example.*这种通配符形式，原包Bundle ID是com.example.chat，那直接保持不变就行。如果描述文件App ID是精确的com.something.else，就得在Info.plist里改CFBundleIdentifier：
plutil -replace CFBundleIdentifier -string "com.something.else" TargetApp.app/Info.plist修改之后，原来App里所有引用这个Bundle ID的地方也要同步检查，尤其是Keychain相关配置。改ID这件事能做，但是牵一发动全身，能不改尽量不改；实在要改，后面验证越详细越好。
3.3 提取并生成Entitlements配置
重签名最容易被忽略的环节是Entitlements。很多人直接拿证书重签，不配置权限，结果装上了、一打开就闪退，或者Debug调试彻底失效。
优先从原包提取Entitlements，保留原包需要的权限信息：
ldid -e TargetApp.app > entitlements.plist plutil -p entitlements.plist常见输出里会有application-identifier、keychain-access-groups、get-task-allow等字段。需要留意的是，从原包提取出来的信息里，Team ID大概率是别人的，必须改成你自己的Team ID，否则描述文件校验不通过。
新开发证书的Team ID通过之前的security find-identity已经能拿到，直接修改：
plutil -replace application-identifier -string "TEAMID.com.example.chat" entitlements.plist如果这个包后面还要调试，保留get-task-allow为true。如果是分发给测试者的Ad Hoc包，这个值反而是false。搞反了，调试会卡在启动，或者分发了调试权限出去，都是问题。
3.4 准备描述文件并检查App ID
描述文件直接决定设备能不能装。拿到新的.mobileprovision文件后，先用security命令解出里面的信息确认一下：
security cms -D -i YourProfile.mobileprovision看两个核心字段：ProvisionedDevices里有没有目标设备UDID；Entitlements里的application-identifier是否和你刚改的Entitlements一致。
把确认无误的描述文件复制进App包：
cp YourProfile.mobileprovision TargetApp.app/embedded.mobileprovision3.5 逐层重签名：先Framework，再主App
重签名有个铁律：从最内层开始，一层一层往外签。顺序反了，外层签名会把内层的内容也包含进哈希计算，导致内层签名和内容错位。
先签主App里的所有动态库：
codesign -f -s "iPhone Developer: Your Name (TEAMID)" \ --entitlements entitlements.plist \ TargetApp.app/Frameworks/*.framework如果有Extension目录，Extension也要单独签一次：
codesign -f -s "iPhone Developer: Your Name (TEAMID)" \ --entitlements entitlements.plist \ TargetApp.app/PlugIns/*.appex最后签主App本体：
codesign -f -s "iPhone Developer: Your Name (TEAMID)" \ --entitlements entitlements.plist \ TargetApp.app签完检查一下：
codesign -v --strict TargetApp.app没有任何输出，通常意味着签名结构是完整可校验的。
3.6 打包并安装到真机
回到Target目录，重新压缩成IPA：
cd Target zip -qr ../Target-resigned.ipa Payload连接真机后，用ideviceinstaller安装：
ideviceinstaller -i ../Target-resigned.ipa首次安装完成后，真机对应设备的“描述文件与设备管理”页面里会出现未信任的开发者证书，去信任一下再打开App。装完不是终点，我建议紧接着验证签名：
codesign -v --strict TargetApp.app再检查一下安装到真机后的签名信息有没有被系统额外改动，这些细节决定App能不能稳定运行。
4. 重签名后的常见问题与排查办法
4.1 安装阶段直接失败
现象：ideviceinstaller报错，提示无法安装，设备上出现黑色图标但进不去。
大概率原因按出现频率排序：
- 设备的UDID不在描述文件里。这几乎是头号原因。解决方法是重新生成包含该UDID的描述文件，再走一遍重签。
- Bundle ID和描述文件App ID不匹配。检查
embedded.mobileprovision里解出来的application-identifier，和Info.plist里的CFBundleIdentifier是否对齐，Team ID是否一致。 - 证书状态异常，比如证书已过期或被吊销。这时候重签结果看起来正常，但系统安装校验就是不通过。
排查这类问题，优先打印描述文件内容，把UDID列表和App ID字段逐个核对，比瞎猜快得多。
4.2 安装成功但一打开就闪退
现象：App图标正常，点击后立刻退出，桌面闪回主屏。
先用设备日志定位崩溃原因。常见的错误有：
Error: Failed to exec real executable或：
Library not loaded: @executable_path/xxx.dylib第一类多半是主二进制本身签名状态不完整，比如Frameworks漏签、签名顺序不对。第二类多半是你注入了动态库，但注入的库没有正确加入主二进制的Load Command，或者库本身的签名没做。
碰到闪退，优先检查“有没有文件在签名之后被动过”。签名是对包内文件哈希的完整记录，任何文件在签名后变化，启动即崩。特别是如果你用了脚本自动改文件，脚本跑完没重新签，这个坑很容易踩。
4.3 注入动态库之后的签名坑
给目标App注入动态库是常见的重签名需求，但动态库注入后问题会成倍增加。注入动作本质上是在主二进制的Load Command里增加一条加载路径，常见用法：
insert_dylib @executable_path/YourPlugin.dylib TargetApp.app/TargetApp --inplace注意这里的路径必须用@executable_path开头，表示相对于主App可执行文件所在目录。如果直接写绝对路径，换个环境就废了。
注入完成后，必须把整个包重新签一遍：先签Framework，再签主App。注入的这个dylib也要单独签：
codesign -f -s "iPhone Developer: Your Name (TEAMID)" TargetApp.app/YourPlugin.dylib很多人在这一步漏掉，导致设备一直报库加载失败。
4.4 重签名真机提示“无法验证App”
现象：安装上了，但系统提示无法验证，或者设备上App图标被禁。
本质是设备对证书信任没有建立。这一步和代码没关系，就是去“描述文件与设备管理”里信任对应的开发者证书。有些包启用了更强的签名校验，那就要检查签名时是否使用了不支持的证书类型，或者描述文件类型太老。
5. 实操中那些容易被忽略的细节
这一节整理一些我反复踩、反复总结的细节经验，每一条都是从真机和日志里熬出来的。
- 千万别用
codesign --deep一把梭。
旧版本里有人为了省事，在重签时直接加--deep选项，指望一次签完所有嵌套内容。实际效果经常是本末倒置：外层签名计算内容时包含内层，但内层的签名状态又取决于外层，形成循环不一致。新版系统已经明确不推荐这个参数。老老实实写循环，对Frameworks逐个签，对PlugIns逐个签，最后签主App，顺序错了系统就给你脸色看。
- 签名后不要做任何改动。
签名完成后，哪怕只是往包里塞一个空文件，整个哈希链都会变。改完必须重新签名。这也是为什么很多自动化脚本会在文件修改之后再整体跑一遍签名流程，而不是先签后改。
ldid和codesign各司其职。
我见过有人直接在真机安装完成后，试图用ldid -Sxxx来让系统信任签名，这行不通。ldid适合在没有完整证书时做离线分析和Entitlements提取，真机安装的最终签名必须用codesign配合有效证书完成。把两个工具混着用在正式步骤里，会给自己埋雷。
- Team ID前缀要统一。
证书的Team ID、描述文件的App ID前缀、Entitlements里的application-identifier前缀，三者必须完全一致。有一个不一致，App也许能装上，但运行中的Keychain内容、get-task-allow权限、甚至推送功能都会翻车。
- Framework和Extension是重灾区。
很多包不止主App一个可执行文件。检查包内所有签名目标时，用一行命令把所有可执行文件都列出来：
find TargetApp.app -name '*.framework' -o -name '*.appex' -o -name '*.dylib'列出来的每一个，都要在当前签名流程里覆盖到。漏一个，日志里报的可能就是晦涩的签名校验失败，排查起来非常费时。
- 保留原包的关键Entitlements。
如果你做的只是“换证书重签”，不要乱删原包里提取出来的权限。特别是keychain-access-groups和aps-environment，删了会让原有的钥匙串数据丢失、推送失效。正确姿势是在原信息基础上扩展，而不是从零开始写一份。
- 注意原App是否加密。
某些App的二进制是有加密段的。这类包直接重签装上，启动时系统解不了密，大概率直接崩溃。这种情况需要先做解密处理，再做重签名。判断方法可以查看Mach-O的LC_ENCRYPTION_INFO段：
otool -l TargetApp.app/TargetApp | grep -A4 LC_ENCRYPTION_INFO如果cryptid为1，说明二进制是加密状态，不能直接靠重签名绕过去。
6. 写在最后的一点经验
我个人实际做重签名时，习惯把整套流程写成一个带参数的shell脚本，每次只要换IPA路径、证书名、描述文件路径，两分钟就能跑完一遍。早期我也是一步一步手动操作，代码签名报错就搜一下，安装失败就重试。踩过几次坑之后发现，绝大多数问题其实都集中在三大块：描述文件没配对、签名顺序不对、签名后动了文件。只要把这三件事管住，重签名的成功率非常高。
另外一个小建议：每次签完包，在真机上多测几步，不要只看图标能打开就结束。一个有问题的签名，很可能在第一次访问Keychain、第一次拉起推送、第一次调用扩展时才暴露。跑通主流程只是开始，把涉及权限的路径也走一遍，才真正算得上“重签名成功”。
