iOS重组IPA(打包再签名)窥打包签名流程

释放双眼,带上耳机,听听看~!

一、IPA 的简单认识

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

image.png

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

image.png

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

image.png

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

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

二、简单的打包

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

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

上面的 CydiaSubtratehgdev.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

你在 arm-64 设备上下载的,那么在设备上世纪下载安装的就是 arm-64 的可执行文件,这应该也是 App Store 做的一个优化。

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

image.png

是一个胖二进制文件。

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

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

人已赞赏
iOS文章

iOS之C函数Hook & MSHookFunction & MSFindSymbol & MSGetImageByName

2020-5-12 0:33:07

iOS文章

Testflight 的使用

2020-5-12 1:48:04

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索