动态库的注入

一、认识库

是一种共享程序代码的方式,在计算机科学中,(英语:library)是用于开发软件的子程序集合。库和可执行文件的区别是,库不是独立程序,他们是向其他程序提供服务的代码。
库链接(英语:linking)是指把一个或多个库包括到程序中,有两种链接形式:静态链接和动态链接;相应的,前者链接的库叫做静态库,后者的叫做动态库。

  • 静态库

静态链接是由链接器在链接时将库的内容加入到可执行程序中的做法。链接器是一个独立程序,将一个或多个库或目标文件(先前由编译器或汇编器生成)链接到一块生成可执行程序。静态链接的最大缺点是生成的可执行文件太大,需要更多的系统资源,在装入内存时也会消耗更多的时间。

特点如下:

  1. 静态库的存在形式有.a和.framework

  2. 静态库由一个或多个object文件组成,可以将静态库拆分成多个object文件

  • 动态库

动态链接,在可执行文件装载时或运行时,由操作系统的装载程序加载库。在iOS系统里面这个装载程序就是dyld。

特点如下:

  1. 动态库的存在形式有.dylib、.framework及链接符号.tbd

  2. 动态库的格式和普通二进制文件没有区别

  3. 动态库的好处是可以只保留一份文件和内存空间,可以被多个进程使用,比如系统的动态库dyld_shared_cache_arm64dyld_shared_cache_armv7s

  4. 可以减小可执行文件的体积,不需要链接到目标文件

二、动态库注入

逆向修改三方应用,让三方应用执行我们的代码,这就是代码注入,动态库注入是一种方式。其中动态库注入分为framework注入dylib注入
学习动态库注入之前,先简单了解一下Mach-O文件

Mach-O为Mach Object文件格式的缩写,它是一种用于可执行文件,目标代码,动态库,内核转储的文件格式。
每个Mach-O文件包括一个Mach-O头,然后是一系列的载入命令,再是一个或多个块,每个块包括0到255个段。

现在我们要关注的是Mach-O的Load Command段,该段主要告诉操作系统(实质就是dyld)如何加载文件中的数据以及动态链接系统的动态库,利用MachOView工具查看已解密的微信可执行文件中的Load Command段:

动态库的注入_第1张图片
关注LC_LOAD_DYLIB

看到Load Command段下的LC_LOAD_DYLIB段,该段表示应用程序依赖的动态库,包括动态库名称、当前版本号、兼容版本号等。此时我们会思考到是否可以通过一些骚操作给这个可执行文件增加一段,加载我们自己编写的动态库?接下来我们尝试一下这个骚操作

1. framework注入

上次学习到利用Shell脚本应用重签名三方应用进行调试,这次我们可以使用它来动态注入framework让三方应用执行我们写的代码。

  • 在已经重签名三方应用的工程下创建动态库framework
    动态库的注入_第2张图片
    创建注入的动态库

在framework里简单地创建一个类,并且在+load方法(类加载的时候执行,先于main)里写一些简单代码作为测试,如下:


动态库的注入_第3张图片
编写注入代码

Command + B编译工程,查看生成的app目录


动态库的注入_第4张图片
编译出的framework
动态库的注入_第5张图片
替换.app包下的Frameworks文件夹

注意:
这里虽然编译的时候会将我们创建的动态库framework打包进.app文件夹内,但是,运行的时候并不会加载我们的framework(读者可以自行尝试),原因很简单,因为这样并不会修改增加Mach-O可执行文件的LC_LOAD_DYLIB段,整个过程只是编译->运行重签名脚本,替换了我们当前工程的.app包,每次运行都仍然是原来第三方ipa应用里的原可执行文件。因此我们需要对原可执行文件下手。

方法一:
使用yololib工具将我们编译好的动态库framework注入原ipa包内的可执行文件,具体如下:

yololib 你的可执行文件 Frameworks/xxx.framework/xxx

动态库的注入_第6张图片
真正注入加载framework的骚操作

再次用MachOView查看可执行文件,可以看到已经增加了LC_LOAD_DYLIB字段

动态库的注入_第7张图片
增加了字段

此时再重新打包成ipa包,放到重签名下的TargetApp文件夹进行重签,运行工程就可以看到加载了我们注入的动态库以及运行了相关代码,打包过程不再赘述,运行结果如下:


动态库的注入_第8张图片
注入成功

方法二:
思考一下我们每次重签完三方应用后,编写完需要注入的动态库之后再用工具注入的话,如果我们下一次修改了动态库,又再次需要手动注入一次,显得很麻烦没必要,既然重签名也可以通过脚本,举一反三,我们将动态库framework注入的操作也放到脚本,每次运行工程的时候自动注入,我们只需要集中精力编写我们的动态库即可,修改重签名脚本,在脚本末尾添加代码,如下:

INJECT_FRAMEWORK_PATH="Frameworks/KenHookFramework.framework/KenHookFramework" (这里命令参数写死,需要替换成自己写的framework)

yololib "$TARGET_APP_PATH/$APP_BINARY" "$INJECT_FRAMEWORK_PATH"

动态库的注入_第9张图片
1.jpg

再次运行工程,脚本就帮我们做了替换包内容,重签名,framework注入的操作

动态库的注入_第10张图片
通过脚本注入,再次运行工程结果

2.dylib注入

  • 同样地使用Shell脚本应用重签名新建一个空工程
  • 新建一个Target
    动态库的注入_第11张图片
    新建工程
动态库的注入_第12张图片
选择Library
动态库的注入_第13张图片
默认选择动态库

创建dylib之后有两个注意点:
1.创建的Library是属于macOS下的,将Build Settings下的Base SDK更改为iOS,如下:

2.创建的Library签名默认使用Mac Developer,将其改成iOS Developer,目的是让它能在iOS平台上使用

  • 目标工程引用、依赖dylib
    工程Target切换到dylib,编译,show in Finder可以发现编译出的dylib与.app文件夹在同级目录,Xcode没有将dylib编译进我们的目标工程,因此我们需要添加依赖,如下:
    动态库的注入_第14张图片
    Copy Files
动态库的注入_第15张图片
选择dylib

再次编译目标工程,在xxx.app/Frameworks/目录下就会看到对应的dylib,运行目标工程并不会执行我们动态库的代码,原因与framework注入注意点同理,这里我们不使用手动注入原ipa包可执行文件,而是使用重签名脚本替我们完成,修改脚本,如下:

INJECT_FRAMEWORK_PATH="Frameworks/libKenHookDylib.dylib"

yololib "$TARGET_APP_PATH/$APP_BINARY" "$INJECT_FRAMEWORK_PATH"

动态库的注入_第16张图片
脚本添加注入代码
  • 运行工程,检验是否注入

    动态库的注入_第17张图片
    注入成功

  • 查看Mach-O文件
    用MachOView查看新编译出来的可执行文件,可以看到已经添加了对应字段

    动态库的注入_第18张图片

三、总结

  • 认识静态库与动态库

  • 认识应用的Mach-O可执行文件

  • 通过增加Load Command的LC_LOAD_DYLIB字段,指定动态库的路径实现注入

你可能感兴趣的:(动态库的注入)