iOS重签名之完全重签名和不完全重签名

3,440 阅读5分钟

最近在工作中遇到了一些ipa重签名相关的内容,就在网上查了一些资料;

本文仅从iOS重签名常用工具和操作角度进行说明,不包括RSA加密原理和使用公私钥验证证书签名的相关知识;

现在主流的重签名有两种:

完全重签名

证书mobileprovisionBundle ID 三者信息对应一致,这种签名方式基本上与直接通过Xcode进行签名的效果是一样的; 优点:有效期和稳定性与使用Xcode进行签名一样; 缺点:维护成本较高,每一个重签名的ipa都必须修改Bundle ID 并且匹配对应的签名证书和mobileprovision描述文件; 适用范围:对签名稳定性有要求;

不完全重签名

只保证证书mobileprovision对应一致,至于这两者与原ipaBundle ID 等信息是否一致则不考虑; 优点:看起来较方便维护; 缺点:只是对原ipa的签名进行了替换,签名文件和Bundle ID并为匹配,很容易发生校验失败导致签名失效,需要重新签名才可以,稳定性不高,慎用! 适用范围:稳定性要求不高;

重签名相关的知识&两种方式重签名的工具和步骤

在介绍如何重签名之前,我们还是要简单了解iOS签名机制以及作用

签名机制的目的

在 iOS 出来之前,在主流操作系统(Mac/Windows/Linux)上开发和运行软件是不需要签名的,软件随便从哪里下载都能运行,导致平台对第三方软件难以控制,盗版流行。苹果希望解决这样的问题,在 iOS 平台对第三方 APP 有绝对的控制权,一定要保证每一个安装到 iOS 上的 APP 都是经过苹果官方允许的,怎样保证呢?就是通过签名机制。

签名机制的实现

说到签名机制的实现,就不得不提各种证书mobileprovisionEntitlementsCertificateSigningRequestp12AppID这些概念性的东西每一个拿出来说都是需要很大篇幅的,我们在这里简单说下他们是如何互相配合来实现对ipa签名的功能。

iOS签名主要用到的有证书mobileprovision这两个文件,其他文件(CertificateSigningRequestAppID)都是为了生成这两种文件而存在,或者是这两种文件在的衍生文件(P12Entitlements),当签名代码时,会将证书文件的签名信息mobileprovision一起写入,同时为了管控APP 的其他权限,Xcode 会生成Entitlements文件,这些文件、资源和代码最终都会以ipa文件的形式导出; 最终的签名本质上就是对ipa的hash值使用公钥进行加密的结果

通过解压ipa文件的结构也可以看出一些问题:

ipa内部文件结构

  1. 资源文件:例如图片、html等。

  2. CodeSignature/CodeResources:这是一个plist文件,可用文本查看,其中的内容就是是程序包中(不包括Frameworks)所有文件的签名。注意这里是所有文件。意味着你的程序一旦签名,就不能更改其中任何的东西,包括资源文件和可执行文件本身。iOS系统会检查这些签名;

  3. 可执行文件:此文件跟资源文件一样需要签名;

  4. mobileprovision:此文件用来校验证书文件Bundle ID,从苹果开发者中心进行生成。

  5. Frameworks:程序引用的非系统自带的Frameworks,每个Frameworks其实就是一个app,其中的结构应该和app差不多,也包含签名信息CodeResources文件

    上述这些文件组合在一起,共同实现了ipa的签名功能。

了解了签名原理,我们再来了解下iOS系统验证签名有效性的过程,只有了解这个过程才能更好的重签名

  • iOS 系统验证签名有效性的过程

iOS 系统验证签名有效性的过程

  1. 解压ipa;
  2. 取出embedded.mobileprovision,通过签名校验是否被篡改过;
  3. 校验所有文件的签名,包括Frameworks;
  4. 验证授权设备是否符合embedded.mobileprovision文件中的信息;
  5. 比对Info.plist里面的BundleId是否符合embedded.mobileprovision文件中的信息;

了解了签名和验证签名的原理,接下来我们就可以对症下药,进行重签名

重签名的实现

既然签名是由证书mobileprovision共同实现,那么重签名的过程其实就是将新的证书mobileprovision替换旧文件的过程,但由于系统在验证app是否合法的时候还会随机验证授权设备列表和 Bundle ID、所以必须修改Bundle ID新的mobileprovision中的信息保持一致,否则将会有验证失败的风险。 完全重签名就是采用完全替换的方式,所以在面对Apple的合法性校验的时候,不会有任何问题; 不完全重签名由于忽视了Bundle ID校验这一环节,签名不稳定,容易校验不过导致签名失败!

重签名的具体操作

完全重签名

完全重签名现在很多工具都可以实现了,常用到的如Fastlane中的resign功能,这边介绍一种更轻量级的GUI工具iReSign,使用非常简单,一张图即可说明。 iReSign使用说明

注意:选择重签名的描述文件和重签名的证书文件时,一定要配套,同时一定要勾选修改ID,并将App ID修改为与重签名的描述文件中的APP ID 一致,切记!

不完全重签名

不完全重签名的方式需要用到一种比较老的工具iOS_resign_scripts 这个工具提供三种重签名的脚本,但是据我个人实践,只有。。第三种方式有效,前两种脚本已经无法实现重签功能了。。。 方法:

  1. 将重签名脚本ios_resign_with_ipa 和 重签名过程中会用到的ipamobileprovision放入同一个目录下;
  2. 在文件夹目录下执行脚本
$sh ios_resign_with_ipa $source_ipa_file $Developer_code_sign $mobileprovision $target_app_related_path

source_ipa_file :待重签名的ipa名称;

target_app_related_path:重签名后生成ipa的名称;

$Developer_code_sign :重签名使用到的证书名称;

$mobileprovision:重签名使用的描述文件名称

Example:

$sh  ios_resign_with_ipa Testerhome.ipa "iPhone Developer: hengjie chen (XXXXXXXX)" embedded.mobileprovision Testerhome-resigned.ipa

以上两种重签名工具有各自的优缺点,需要根据具体情况决定来采用;