iOS应用签名原理&应用重签名并附加调试

代码签名

在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安装的需求:

1.安装包不需要上传到App Store,可以直接安装到手机上
2.苹果为了保证系统的安全性,有必要对安装的APP有绝对的控制权
3.经过苹果的允许才可以安装
4.不能被滥用导致非开发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)是怎么来的呢?

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

描述文件(mobileprovision文件)

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

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

1.第一限制在苹果后台注册过的设备才可以安装.
2.第二限制签名只能针对某一个具体的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重签应用的时候会用到

最终的流程如下图所示:

应用重签

了解了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包之后,用归档实用工具解压

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

对Frameworks里面的库进行重签名

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

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

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

替换BundleID

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

通过授权文件(Entilements)重签.app包

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

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

如果你的手机上本来有一个官方正版微信,你现在会发现手机上出现了两个微信;接下来你可以打开刚刚新建的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字段)

删除插件文件夹(PlugIns)和Watch文件夹

重签Framework文件夹

将MachO文件权限提权

替换APP包

把新建工程的APP包替换成刚刚重签过的APP包

最后在新工程的下command + R或者点击运行按钮,就会发现别人的项目被我们的Xcode跑起来了

对比下来发现使用Xcode来重签并附加调试别人的APP还是要简单方便一点

使用shell脚本重签

经过上述两种手动重签的之后,我们知道了重签的原理了,那么我们可以将上面的手动签名的步骤写成脚本,让Xcode来执行我们的脚本进行自动重签,脚本我已经准备好了,下面是使用脚本重签的步骤:

新建工程并在真机在运行一次

这一步还是跟之前一样,为了把描述文件安装到真机上,但是使用脚本来重签的话就不需要新建一个跟待重签APP同名的工程了

将待重签ipa包放到新工程目录下的APP目录下

因为脚本需要知道重签的ipa在哪,就规定了一个路径,就是工程根目录下新建一个APP目录,并把ipa包放在里面

将脚本放到新工程根目录下并配置好

脚本放到工程根目录下后,我们可以按下图所示的配置好脚本,其中${SRCROOT}是Xcode环境变量,代表了项目的根目录,而appSign.sh就是我们的脚本文件

接下来command + R运行就可以运行并调试他人APP了,有可能报一些权限问题安装不了啥的,那就Command + shift + k清一下缓存再command + R运行,用上脚本之后可真是太舒服了,那为什么还要讲之那些手动重签的步骤呢…当然是学习脚本背后的原理啊

使用iOS App Signer重签

了啥的,那就Command + shift + k清一下缓存再command + R运行,用上脚本之后可真是太舒服了,那为什么还要讲之那些手动重签的步骤呢…当然是学习脚本背后的原理啊

使用iOS App Signer重签

github地址:github.com/DanTheMan82…这是一个Mac上的APP,可以用来给企业开发者账号重签别人开发的APP来分发的,不过底层的原理也是类似的,只是用途不一样

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值