iOS Developer面试专题（重难点）ipa重签名

iOS打包签名，你真的懂吗

2021-06-07  本文已影响0人  lele8446

导语：iOS签名类型有Development、AD-Hoc、In-House、App Store，而打包过程中又涉及到各种证书、Provision Profile、entitlements、CertificateSigningRequest、p12、AppID......各种概念一大堆，本文将从打包签名的原理说起，并梳理完全签名的整体流程，最后讲解重签名的实现以及签名机制中有哪些是需要注意防护的要点。

为了保证App的分发平台是可控的，以及保证所有安装到iOS设备上的App都是经过苹果官方允许的，苹果建立了iOS签名打包机制。要了解iOS签名机制的实现，我们首先从签名机制的原理说起。

1. 签名原理

1.1 不对称加密

网络数据的传输可以使用对称加密以及不对称加密的方式进行安全防护，对称加密是指数据发送者（A）和接收者（B）双方进行加解密的密钥是一致的，但这样会增加密钥自身分发的不安全性：比如要如何保证密钥在传递过程中不被泄露。

而不对称加密则由A、B持有一对公私钥进行加解密，公私钥钥匙对是成对出现的。对于一个私钥，有且只有一个与其对应的公钥，私钥保密、公钥公开，但是不能通过公钥推导出私钥，使用私钥加密的文件可用公钥解密，反过来公钥加密的文件也只能用私钥进行解密。加密过程如下：

  1. 发送方（A）首先生成一对公私钥钥匙对，私钥自己保管，公钥则任意分发出去（每台iOS设备终端其实已经包含Apple的公钥）。

  2. 发送数据时，发送方使用私钥对原数据加密成密文传输（加密打包ipa）；

  3. 接收方（B）收到密文后，使用之前已经获取到的公钥进行解密得到数据内容（iOS设备验证安装ipa）。

不对称加密

1.2 数据签名

这里主要解决了两个问题，一个是加密数据大小的问题，另一个是如何验证公钥的有效性。

1.2.1 信息摘要

前面已经讲到，iOS打包安装的过程中会对ipa包进行加解密验证。然而ipa安装包大小动辄就有十几M，大的有好几G，那如果对这么大的数据量进行加解密，肯定效率是非常低的。而信息摘要则是解决了加密数据过大的问题，其原理是对信息内容通过一个很难被逆向推导的公式计算得到一段哈希数值，它具有以下特点：

使用信息摘要技术在数据加密传输时，发送方先对文件内容使用哈希算法进行信息摘要计算，再对摘要内容进行加密，之后将文件内容以及摘要内容（已加密）发送出去。

接收方收到数据后，先解密得到摘要内容，再依据相同的哈希算法对文件内容进行信息摘要计算，最后匹配接收到的哈希值与计算得到的哈希值是否一致，如果一致那就说明传输过程是安全的。

这样也就避免了对整体原数据加解密的计算过程，从而提高了验证效率。

1.2.2 签名证书

不对称加密中的公钥是公开的，谁都可以得到，这样也就存在了不安全性。比如主动攻击者C冒充数据发送者A，将自己伪装后的公钥分发给数据接收者B，从而达到监听A、B之间通信的目的，又或者是对A、B之间的通信数据进行注入攻击。

签名证书

那为了保证获取公钥的安全性，这里引入CA认证（Certificate Authority）。CA是证明公钥合法性的权威机构（Apple就属于CA认证机构），它为每个使用公开密钥的用户发放一个数字证书，数字证书的作用是证明证书中列出的用户合法拥有证书中列出的公开密钥。用户使用 CA 的公钥对数字证书上的签名进行验证，如果验证通过，也就认为证书内包含的公钥是有效的。

CA签名

CA认证确保了用户公钥使用过程中的安全性，iOS打包需要向苹果开发者中心上传.certSigningRequest文件，然后配置得到各种.cer证书，这些流程中便包括了开发者向Apple CA认证中心注册公钥的过程。

2. iOS签名

2.1 概念要点

2.2 AppStore签名

发布App至AppStore之前需要经过苹果后台审核，审核通过苹果后台会用Apple私钥对App数据进行加密签名生成ipa包；用户从AppStore下载App后，使用设备内置的Apple公钥解密验证，验证通过安装成功。由于AppStore分发的过程中上传审核、下载安装的整个过程都处在苹果的生态链内，所以只需要一次验证就能保证安全性。

AppStore

2.3 其他签名

从AppStore下载安装App只需要一次数字签名就足以保证安全性，但除了这种途径苹果还有其他的安装方式：

那这些安装App的过程中苹果又是怎样保证流程安全性的呢？答案就是双重签名机制，苹果使用前面讲到的Mac本地钥匙对以及Apple后台钥匙对进行多次数字签名，从而保证整体流程的可控。

  1. Mac 钥匙串访问 在本地生成一对公私钥钥匙对，下面默认为公钥L、私钥L（L：Local）。

  2. Apple已有一对公私钥钥匙对，私钥A在Apple后台，公钥A内置到每一台iOS设备终端（A：Apple）。

  3. 上传公钥L至Apple后台，使用私钥A对公钥L进行数字签名生成签名证书.cer，同时使用私钥A对额外信息（使用什么证书打包、AppID、打包的App包含了哪些功能、可以在哪些设备上安装）进行签名生成描述文件Provisioning Profile，之后将.cer和Provisioning Profile下载安装到Mac机器上。

  4. 编译打包app，选择签名证书.cer，打包指令会自动找到该证书对应的私钥L（能匹配是因为钥匙对是成对出现的，前提是本地必须已经存在L私钥，也就是p12的安装），然后使用私钥L对app进行签名。

    • 这些签名数据包含两部分：Mach-O可执行文件会把签名直接写入这个文件中，其他资源文件则会保存在_CodeSignature目录下。你可以将打包生成的.ipa文件另存为.zip，解压后对Payload文件夹中的.app文件右键、显示包内容，就可以看到签名数据。

    • 另外签名过程中对于App内包含的动态库以及插件（Plugins、Watch、Frameworks文件夹），每一个都会单独进行一次签名，并生成各自的Mach-O可执行文件和_CodeSignature。

    • 签名数据指代码内容、App包含的所有资源文件，只要其中有任何改动，都必须重新签名才有效。

  5. 打包的过程中会将描述文件Provisioning Profile命名为embedded.mobileprovision放入到打包app中。

  6. 安装/启动，iOS设备使用内置的公钥A验证embedded.mobileprovision是否有效（设备是否在允许安装列表内），同时再次验证里面包含的.cer证书签名是否有效（证书过期与否）并取出公钥L。

  7. embedded.mobileprovision验证通过，就使用公钥L解密验证app签名信息：AppID是否对应、权限开关是否跟app里的entitlements一致等等。

  8. 所有验证通过，安装/启动完成。

签名流程

以上流程便是开发调试、AD-Hoc、In-House等方式打包安装App的过程，区别只在于第⑤步中设备IDs的匹配规则不一致。开发调试只安装当前联调的设备；AD-Hoc允许安装到已在开发者账号下注册过的设备，且每年最多允许100台；In-House无设备数量限制，常用于企业内部App的分发。

3. ipa包重签名

ipa包重签名主要针对的是非App Store的安装包，App Store分发最终是上传ipa文件到苹果后台审核，通过后使用Apple私钥加密，然后才能发布安装，不存在重签入侵的可能。而开发调试、AD-Hoc、In-House等分发途径生成的ipa包不存在苹果后台验证的步骤，这也就意味着你可以对任意的.app、 .ipa文件进行重签名。

回顾前面讲到的签名流程，真正对ipa包进行签名的关键步骤（④⑤）是在Mac本地进行的，签名过程中需要满足三个条件：App即软件代码编译生成的产物、p12证书以及Provisioning Profile配置文件。其中App的内容是动态变动的，Apple不会去验证它，实际上也无需验证，因为在开发调试过程中，所开发的App肯定是不停的迭代变化的，如果需要上线App Store那Apple只需在审核阶段对App内容进行把关验证即可，而其他分发渠道它则管不了。p12以及Provisioning Profile则是下载后主动安装的，大部分情况下都是由管理员创建下载好之后，导出分发给团队成员。

3.1 签名指令

iOS签名调用的是codesign指令，你也可以直接使用相关指令进行签名，下面是codesign的常用指令：

# MAC终端输入： codesign --help
codesign --help
Usage: codesign -s identity [-fv*] [-o flags] [-r reqs] [-i ident] path ... # sign
       codesign -v [-v*] [-R=<req string>|-R <req file path>] path|[+]pid ... # verify
       codesign -d [options] path ... # display contents
       codesign -h pid ... # display hosting paths

查看Xcode的编译日志，也可以看到签名的详细信息

Xcode签名 
# 签名指令
codesign -f -s "iPhone Distribution: XXX（证书名称）" --entitlements entitlements.plist（Profile配置文件） XXX.app（签名app）

3.2 重签名

3.3 注入代码重签

3.4 关于重签名的思考

iOS重签名实现，可以发现用于签名的私钥资源（包括.cer证书和Provisioning Profile配置）和实际签名的app包是没有强关联关系的，这也就带来了两方面的问题。

  1. .cer证书和Provisioning Profile配置被用于其他App的分发签名，特别如果是In-House企业类型的证书，那是可以进行无限制分发的，而一旦苹果检测到这种违规签名的行为，轻则撤销证书，重则注销企业开发者账号！这也就是为什么一定要严格把控 p12、Provisioning Profile 文件外发的原因。
  2. 自有App被注入代码后重签名，比如应用多开、添加插件、恶意抓包等等，对于这一类的防护除了对Bundle ID进行检查，以及对App动态库增加白名单检索外好像也没有更好的办法。当然这已经涉及到逆向防护的方向了，本人对此还未深入了解，有兴趣的同学可以一起参与探讨。

全文完！

最后再附上重签名脚本地址： CJCodeSign

作者简介：lele8446，iOS开发深耕者，爱好分享、深⼊探讨有温度的内容，GitHub地址。

上一篇下一篇

猜你喜欢

热点阅读