一、IPA 的简单认识

首先有一个这样的 ipa 包文件：

image.png

直接修改文件后缀为：IPADev.zip, 然后解压，是这样的：

image.png

从这个解压的文件结构来看，说明一个 ipa 包，实际上就是一个压缩文件包。解压之后是一个 Payload 的文件夹，这个文件夹中带有一个 .app 文件夹，再次进入这个文件夹，具体内容如下：

image.png

这是一个，简单的 app 文件夹，实际项目中这里面的文件会很多。

以上就是对一个 ipa 包的结构做的一个简要介绍，但是以上是一个通过 Xcode 的 Aechive 打的一个 Ad Hoc 包。不同的包的结构会有所不同，比如从 App Store 下载下来的会多一层包装，但是大体的结构还是一样的。

二、简单的打包

新创建一个项目 IPADev，然后开始打包，这里的打包并非使用 Xcode 的 Archive 打包，而是另类的手动打包。先看下面项目的配置：

0.png

配置好之后，直接 command+b, 然后发现 Products 文件夹下面的 .app 文件变黑了，直接 Show in Finder 进入这样的界面：

image.png

通过上一小节的介绍，我们可以通过这个 IPADev.app 手动构建一个 ipa 包么？答案是可以的，将 IPADev.app 放入一个空的 Payload 文件夹中，然后压缩成 zip 文件，将 zip 改成 ipa 即可。最后是这样的：

image.png

现在 Payload.ipa 就是一个正规的 ipa 包了。当然这个包与平时看到的文件名有点不一样，手动改成 IPADev.app 即可，改不改都一样。

那么问题来了，这么生成的 ipa 包能安装到真机上么？试一下就知道答案了。当然了，只能安装到一个已在 .app 文件中 embedded.mobileprovision 配置文件中包括注册的设备上，与一个 Ad Hoc 包的性质是一样的。当然了，可以在任意的越狱手机上安装的。

但是如果手动将 IPADev.app 中与签名相关的文件删除再压缩的话，只能在越狱真机上安装，在非越狱真机上直接报错。在安装的过程中，明显感觉越狱真机上的安装速度比较快。说明...

三、对现有包重签名

常规开发中是没有这样操作的，往往是为了将别人的 ipa 占为己有，添加自己开发的代码（动态库），这一操作被叫做 动态库注入。动态库注入的方式有很多，简单的介绍一下相对常规的一种通过 Theos 技术生成 dylib 库的注入方式。

显然，通过 Theos 生成的 dylib 库只能在越狱手机上使用。要想在非越狱设备上运行，只能通过动态库注入，然后重签名打包，这样才能在非越狱设备上运行。

3.1 资源准备

1. 即将重签名的 .app 文件。
2. 即将添加的 dylib 库。
3. 签名配置文件（embedded.mobileprovision）。
4. dylib 关联的动态库 CydiaSubstrate。
5. 动态库注入工具 insert_dylib。

如下图所示：

image.png

3.2 动态库注入

将 hgdev.dylib 放入 HGSecurityDev.app 中，通过然后执行如下命令：

./insert_dylib @executable_path/hgdev.dylib HGSecurityDev.app/HGSecurityDev --weak --all-yes HGSecurityDev.app/HGSecurityDev

命令格式为：./insert_dylib ++动态库文件++ ++Mach-O文件++ ++--weak --all-yes++ ++最终生成的 MachO 文件++

通过 otool 查看一下动态库的关联情况：

otool -L HGSecurityDev.app/HGSecurityDev

image.png

说明成功注入。

在这里，还需要注意一个问题，这个动态库（hgdev.dylib）实在越狱设备上生成的，会默认关联一个越狱设备上特有的动态库（CydiaSubstrate），通过如下命令查看：

otool -L HGSecurityDev.app/hgdev.dylib

image.png

最后希望在非越狱的真机上也能运行，所以需要手动的添加并重新关联。将 CydiaSubstrate 也放入 HGSecurityDev.app 中，然后执行如下命令：

install_name_tool -change /Library/Frameworks/CydiaSubstrate.framework/CydiaSubstrate @loader_path/CydiaSubstrate HGSecurityDev.app/hgdev.dylib

再次查看动态库信息如下：

image.png

到现在为止，关于动态库的注入操作，都结束了。接下来就是数字签名。

3.3 给相应的文件签名

一般情况，只要是 .app 文件有所改动，这些文件将需要重新签名。

1. app 文件。
2. 动态库文件。
3. app 关联的扩展项目。

3.3.1 签名前的准备

对 app 文件签名，必须要有一个签名配置文件（embedded.mobileprovision），如果破解的是一个 Ad Hoc 的包，那么在 .app 文件中会有一个，如果是没有的，可以自己准备一个自己的。
先来看一下 Xcode 是如何签名的：

image.png

接下来，我们使用的就是这个指令。上图中的 .xcent 文件，就是 签名配置文件（embedded.mobileprovision）转化后的配置文件（后面介绍如何转）。

对于动态库的签名，只要有证书编号即可，查看证书编号的命令：

security find-identity -v -p codesigning

image.png

给动态库签名的指令很简单，格式为：codesign -fs 证书编号 Mach-O 文件 。分别给两个动态库签名，命令如下：

codesign -fs 283729D4DDC7F173281DA85F105982C4B1E3C15E HGSecurityDev.app/CydiaSubstrate

codesign -fs 283729D4DDC7F173281DA85F105982C4B1E3C15E HGSecurityDev.app/hgdev.dylib

如图所示：

image.png

给 .app 文件签名。
先从 embedded.mobileprovision 文件中提取出 entitlements.plist 权限文件
，命令如下：

security cms -D -i embedded.mobileprovision > temp.plist

/usr/libexec/PlistBuddy -x -c 'Print :Entitlements' temp.plist > entitlements.plist

分成两步，最终生成一个权限文件 entitlements.plist。

正式签名的命令如下：

codesign -fs 283729D4DDC7F173281DA85F105982C4B1E3C15E --entitlements entitlements.plist HGSecurityDev.app

最终我们看到的 .app 文件是这样的：

image.png

上面的 CydiaSubtrate 与 hgdev.dylib 是新添加的动态库。至此，重签名的操作已经全部完成，下一步，直接变成 ipa 文件。

到这里，有一个关键性的问题：

为什么需要重签名操作？

因为注入动态库之后，对当前的 Mach-O 文件有所修改，破坏了之前的签名，想要保证在非越狱的设备上也能安装，那么就需要重新签名。

3.4 压缩成 ipa 文件

将 HGSecurityDev.app 放入一个空的 Payload 文件夹中，压缩改名为 HGSecurityDev.ipa 即可。

生成的包可以直接安装到越狱设备中，也可以安装在非越狱的设备中（前提是要在签名文件中注册与 Ad Hoc 包的性质一样）。

四、注意事项

上面是以我自己创建的一个简单项目为例子，但是通常我们所要重签名的包都是来自 App Store。步骤都是一致的，但是有几点需要注意：

1. 必须是未加壳的 Mach-O 文件重签名打包后才能安装于非越狱的设备。
2. 重签名生成的 ipa 包一般是不能上线App Store 的，只能自己使用或者企业账号下使用。
3. 这是一个简单的例子，在实际的项目中可能还会有其它的 framework, 这样在 .app 文件夹中就会有所有的 framework，那么在重签名的时候需要先给这个 framework 中的 MachO 文件重签名。当我们进入某一个 framework 会发现都有一个 _CodeSignature 文件夹（下一小节会介绍），所以也需要将这些提前重签名。

五、关于签名文件

对于一个 ipa 文件来说，打开 .app 文件夹就会有一个这样的文件夹：

image.png

据我观察一个 Mach-O 文件会有一个这样的文件夹，这个签名文件中的内容是当前 Mach-O 文件所在目录中的所有文件进行签名。比如当前的项目还有其它的 framework 文件，那么在这个 framework 中也会有这样的文件夹。

image.png

其实我们比较关心的是 可执行文件的签名文件夹中签名内容。

在这里要注意一个问题：我们都知道苹果的这一套数字签名是唯一的。但是对于一个已经上架的 App Store 来，安装到不同的设备上，却不是唯一的。

我们都知道，只要是上线之后的包，肯定是固定不变的。但是一旦安装到不同的设备，就不一样了。同样是从 App Store 上下载，但是我们不同的设备下载下来的可能会不一样。比如：

image.png

还有另一种情况，关于 iOS 的应用，我们还可以其它的渠道直接下载 ipa 文件， 比如 itools，如果通过这样的方式下载安装的话，会发现我们安装的包是这样的：

image.png

是一个胖二进制文件。

那么上面说的问题就很好理解了，不同的情况安装到设备上的可执行文件不一样，那这个签名文件也会不一样就不足为奇了。

所以说通过签名文件来判断当前的应用是否被多开，也是一件麻烦的事情。