代码签名

在iOS系统出来之前,主流的操作系统(Mac或者Windows)软件随便从哪里下载都能安装,运行,系统安全存在隐患,盗版软件,病毒入侵,静默安装等等问题,苹果希望iOS的系统上不会出现这样的问题,就要保证每一个安装到iOS系统上的APP都是经过苹果官方允许的,那么苹果是如何做到的呢?

苹果服务器生成一对RSA的公钥A和私钥A,私钥A服务器保存,公钥A分给每一台iOS设备,服务器对每个APP使用私钥A签名,iOS设备在安装APP的时候,使用内置的公钥A对APP进行验证,只有通过验证了的APP才允许安装,这样就可以保证安装的APP都是经过苹果允许的了;

或许苹果在没有开放App Store给广大开发者的时候,这样简单的代码签名就够了;但是后来随着苹果对App Store的开放,个人开发者,公司开发者随时都需要连接真机调试开发APP;还有企业开发者需要在企业内部分发APP,而不需要上传App Store,需要做到开放这些方式安装APP,同时还要保证这些安装行为是可控的,那么上面所讲简单的代码签名就无法实现了

我们分析一下苹果对于APP安装的需求:

安装包不需要上传到App Store,可以直接安装到手机上
苹果为了保证系统的安全性,有必要对安装的APP有绝对的控制权
经过苹果的允许才可以安装
不能被滥用导致非开发APP也能被安装

为了实现这些需求,iOS代码签名的复杂度也就增加了,苹果实现的方案是双重签名

双重代码签名

除了上传到App Store的APP可以下载安装之外,开发人员也可以直接使用Mac系统将开发中的APP安装到iPhone手机上,但是这个安装行为也是需要苹果允许的;

做过iOS开发的同学应该知道,当需要将Xcode开发的APP安装到真机上的时候,Xcode会在Signing & Capabilities下给出红色的错误,提示开发者Signing for "xxx" requires a development team. 意思签名你开发的APP需要一个开发团队,这个开发团队就是由证书(Signing Certificate)和描述配置文件(Provisioning Profile)组成的;关于描述配置文件,我们放在后面再说;那这个证书(Signing Certificate)是怎么来的呢?

当我们使用Mac上的Xcode安装APP的时候,Xcode会在我们的Mac电脑上生成一对RSA的公钥M和私钥M(M=Mac);然后将公钥M通过CSR(Certificate Signing Request)文件向苹果服务器请求签名;
之前说了苹果服务器和iOS系统之间是有一对公钥A和私钥A的(A=Apple)
苹果服务器收到CSR文件之后,会使用自己的私钥A对公钥M的hash进行签名,这样公钥M和经过苹果服务器私钥A签名过的hash组成一份文件返回给Mac系统了,这份文件就叫做证书;我们打开Mac系统上的钥匙串访问就能看到许多的证书,点击签名的箭头还能看到对应的私钥M;
在开发过程中,编译完一个APP后,用本地的私钥M(或者别人给你的p12)对这个APP进行签名,同时把上一步得到的证书一起打包进APP里,安装到手机上
在安装APP时,iOS系统获取APP包里的证书,通过iOS系统内置的公钥A,去验证这个证书签名是否正确
验证通过之后,就说明证书里的公钥M是没有经过篡改的,再使用这个公钥M去验证APP的签名,如果通过了验证就说明APP也是没有被篡改过,可以安装的

有了上面的过程，已经可以保证开发者的认证，和程序的安全性了。但是，要知道iOS的程序，主要渠道是要通过APP Store才能分发到用户设备的，如果只有上述的过程，那岂不是只要申请了一个证书，就可以安装到所有iOS设备了？描述文件的作用就来了

描述文件(mobileprovision文件)

描述文件（Provisioning profile）一般包括三样东西：证书、App ID、设备。当我们在真机运行或者打包一个项目的时候，证书用来证明我们程序的安全性和合法性。

苹果为了解决应用滥用的问题,所以苹果又加了两个限制:

第一限制在苹果后台注册过的设备才可以安装.
第二限制签名只能针对某一个具体的APP.

并且苹果还想控制App里面的iCloud/PUSH/后台运行/调试器附加这些权限,所以苹果把这些权限开关统一称为Entitlements(授权文件).并将这个文件放在了一个叫做Provisioning Profile(描述文件)文件中.

描述文件的存放路径:~/Library/MobileDevice/Provisioning Profiles

描述文件是在AppleDeveloper网站创建的(在Xcode中填上AppleID它会代办创建),Xcode运行时会打包进入APP内.所以我们使用CSR申请证书时,我们还要申请一个东西!! 就是描述文件!

在开发时,编译完一个 APP 后,用本地的私钥M对这个APP进行签名,同时把从苹果服务器得到的 Provisioning Profile文件打包进APP里,文件名统一改为embedded.mobileprovision,把 APP 安装到手机上.最后iOS系统进行验证。

终端查看描述文件内容:security cms -Di embedded.mobileprovision
可以看到就是一个plist文件,里面有很多键值对,其中key为entitlements,这个键值对在后面使用codesign重签应用的时候会用到

最终的流程如下图所示:

可以看到iPhone手机在安装APP的时候,先使用iOS系统内置的公钥A去验证APP内部的公钥M(公钥M被苹果服务器的私钥A签名了),验证通过之后的公钥M再去验证当前的APP(当前APP被私钥M签名了),验证通过之后才可以进行安装行为;

应用重签

了解了iOS应用的签名原理之后,我们是不是可以做一个大胆猜想,对于任何不是我们开发的APP,我们能不能使用我们的描述文件和证书来重新签名,别人的APP经过我们重签后就会被Xcode认为是我们当前正在开发的APP,从而可以附加调试了;实际上,我们确实可以对任何来源的APP进行重签和附加调试,但是前提是这个APP必须是砸壳过的APP,pp助手iOS版下架后,现在网上砸壳过的APP不好找了,就只有自己动手砸壳了,这个我们以后会讲,如果有需要的可以私我

使用codesign重签

codesign 是Xcode自带的签名工具,我们可以先使用它来帮我完成重签名,后面也可以直接使用Xcode进行重签;

下面先介绍一下相关一些命令:
codesign -vv -d xxx.app 查看xxx.app的一些签名信息
security find-identity -v -p codesigning 查看当前电脑上的证书
otool -l xxx | grep cryptid 查看MachO文件xxx并筛选结果包含cryptid的信息,可以根据cryptid的值确定当前APP是否加密,1代表加密,0代表未加密
otool -l xxx > ~/Desktop/123.txt 查看MachO文件xxx,并将结果以123.txt保存在桌面

我们以微信为例子来进行重签名,在拿到已经砸壳过的微信ipa包之后,用归档实用工具解压
我们只需要Payload里面的.app包

右键.app包显示包内容后,开始下面的步骤

删除插件(PlugIns文件)和带有插件的.app包(比如Watch文件)

对Frameworks里面的库进行重签名

给APP二进制文件加执行权限

没有权限的二进制文件是白色的

提升权限之后变成黑色的

往真机添加描述文件(新建一个工程,在真机上运行一次)

再将新建Demo的描述文件,复制到WeChat.app内

替换BundleID

把WeChat.app里面的info.plist的BundleID改为新建的Demo的BundleID

通过授权文件（Entilements）重签.app包

授权文件在描述文件里面,输入security cms -Di embedded.mobileprovision可以查看描述文件具体信息

找到里面key为Entilements的这一部分,把红圈起来的部分复制并新建一个新的plist文件保存下来

再把这个plist文件,放到和WeChat.app同目录下,准备重签

打开终端,输入以下命令进行重签:codesign -fs "你的证书" --no-strict --entitlements=ent.plist WeChat.app

可以使用codesign -vv -d WeChat.app命令查看我们是否成功重签了,变成你的证书和BundleID就代表成功了

到此,这个WeChat就被我们重签成功了!!!此时,我们可以使用Xcode将这个WeChat安装到我们的手机上

如果你的手机上本来有一个官方正版微信,你现在会发现手机上出现了两个微信;接下来你可以打开刚刚新建的WeChatDemo项目,选择Debug->Attach to Process->WeChat,如果有两个WeChat可以把正版的WeChat从后台划掉,或者选择后面数字较大的那个WeChat,你会发现微信就这样被我们的WeChatDemo项目连接起来了…可以对微信像调试我们自己APP一样viewDebug了

使用Xcode重签

通过使用codesign手动重签过程后,发现其实上述过程并不难,只是过程特别的复杂和繁琐,Xcode可以帮我们简化一些复杂繁琐的过程,那么现在我们直接使用Xcode来重签;

新建与重签APP同名的工程,并在真机上运行一次

这里需要注意一下,因为老版本微信(这里使用的WeChat版本是7.0.7)是没有SceneDelegate的,所以新工程也要把SceneDelegate干掉,跟没有这个东西之前一样;(删掉SceneDelegate的.h和.m文件;AppDelegate添加window属性并初始化,删除UISceneSession lifecycle相关代码;info.plist文件中删掉Application Scene Manifest字段)