【腾讯 Bugly 干货分享】iOS 黑客技术大揭秘

3,033 阅读14分钟

Dev Club 是一个交流移动开发技术,结交朋友,扩展人脉的社群,成员都是经过审核的移动开发工程师。每周都会举行嘉宾分享,话题讨论等活动。

本期,我们邀请了腾讯 CDG iOS 开发工程师“何兆林”为大家分享《iOS黑客技术大揭秘》

如何加入 Dev Club?

移动端开发经验 >= 2 年,微信扫描下方群管理微信二维码,备注姓名-公司(或产品) 申请加入。

查看图片
然后在 cycript的终端输入:

UIApp.keyWindow.recursiveDescription().toString()

结果如下:

查看图片

打印的是当前的ui树,随便找一个节点(树的中间,为什么要在中间,大家可以思考下),copy它的内存地址,例如 0x14da3f000

执行:[#0x14da3f000 nextResponder]

会输出当前节点的下一级事件响应链,然后对输出节点再次调用 nextResponder,直到找到它的视图控制器 xxxcontroller

查看图片

看到了吧,微信的聊天页对应的类名是 BaseMsgContentViewController

3、追踪神器 -- logify

目前为止我们已经锁定了大致的突破口,下面还需继续追踪,找到这个类里面的消息处理函数,这里的思路就是通过向群里发送一个消息,然后观察 controller中哪些方法被调用了。

第三个工具 Logify就是干这个事情的,它是 theos的一个组件,和 theos一起安装在 pc端的,在 pc的终端输入:

logify.pl /path/to/BaseMsgContentViewController.h > /out/path/to/Tweak.xm

打开生成的 tweak.xm文件,可以看到它其实就是 hook了这个类所有的方法,在方法中注入了 nslog,打印方法的入参和返回值,最后把这个文件用 theos打包并安装到手机中,再次向群里发消息,手机连上 xcode观察手机控制台输出。

输出内容很多,需要仔细过滤一下,例如我们发的消息是一个文本“test”,在控制台搜索它,你会在它附近找到下面这个函数调用:

addMessageNode:layout:addMoreMsg

从函数名字来看,这个应该就是用来处理消息数据的,从表面来看我们已经找到消息的拦截点了,但是大家想一下,如果我们hook这个方法,在里面自动抢红包,会有什么致命的缺陷?

老司机们已经看出来了吧,这个方法是 BaseMsgContentViewController类里面的,而这个类进入聊天页面才会被创建。

hook这里会有两个缺陷:

  • 第一,必须进特定的群的聊天页面才能生效;

  • 第二,两个群同时有红包来,没法并发的抢。

为了追求更加上流的功能,我们需要再向上追溯消息的源头,最好 hook那种微信启动后就存在的对象,怎么追溯呢?

我的思路是通过在这个方法中设置断点,通过调用栈,来找到上层的调用者。

4、反汇编工具——hopper & 断点调试工具——lldb + debugserver

第五个工具 lldb + debugserver顾名思义,debugserver是手机端的(只要你的手机有连过 xcode进行 debug,这个玩意就自动有了),用于监听 pc端 lldb的连接,来实现远程调试。

这个工具要和第四个 hooper(反汇编工具)结合起来用。

首先 ssh进手机的终端,输入:

debugserver *:19999 -a WeChat

监听 lldb的连接

然后打开pc的终端,启动 lldb并连接:

lldb
process connect connect://deviceIP:19999

如果连接成功,我们就正式进入 debug状态了。

那么问题来了,要精确的设置断点,必须知道这个函数的内存地址,这个内存地址怎么搞出来呢?

有个公式:

内存地址=进程内存基地址+函数在二进制中的偏移量

上面我们已经连上了 lldb调试环境,获取基地址在 lldb中输入下面的命令:

image list -o -f

这时会输出很多行数据,找到文件名为 WeChat的模块地址,这里第一行就是了:

查看图片

偏移量需要借助 hooper,pc端的反汇编利器,用 hooper打开微信的二进制文件,等几分钟,反汇编完成后,在搜索框输入刚找到的函数名: addMessageNode,定位到相应的汇编代码,第一列就是偏移量了:

查看图片

两个参数都找到后,在lldb中输入:

br s -a ‘基地址+偏移量’

然后用 “br l” 确认一下断点是否设置成功

进入聊天界面,再次向群发送一个消息,会发现 ui卡住了,观察 lldb控制台,会提示进程被断住了,在 lldb中继续输入 bt指令,重点观察模块名是 WeChat的栈,但是由于没有符号表,我们只能看到栈的内存地址:

查看图片

想要把内存地址还原成函数名,需要两步:

  • 第一要把内存地址转换成二进制文件偏移量

  • 第二步再使用 hooper根据偏移量找到函数名

也就是上面公式的逆向过程:

函数在二进制中的偏移量=内存地址 - 进程内存基地址

这里我们栈地址是0x0000000101ad02f4,基地址是0x00000000000e8000,做下减法,得到结果0x1019E82F4,然后在 hooper中搜索这个地址就能得到方法名:

查看图片

以此类推,最后得到栈顶的调用是这个:

[CMessageMgr MainThreadNotifyToExt:]

CMessageMgr这个类,从名字来看,就是消息管理器,而且是单例的,我们终于找到了真正需要 hook的类,但是这个方法是用来异步发送通知的,不像是消息的源头,所以我们用上面说的 logify组件继续追踪一下这个类

过程不再重复讲,最后的目标终于浮出水面:

(void)AsyncOnAddMsg:(id)message MsgWrap:(CMessageWrap* )msgWrap

第一步消息的拦截点终于找到了,接下来是第二步:

第二步:我们需要知道哪些消息是红包,这个就比较简单,向群里发一个普通消息和红包消息,通过 logify组件观察 message参数的内容,发现它里面有一个 type字段,如果是红包,值是49,其他语音和文本各不相同,所以,这里轻松搞定。

第三步:需要实现抢红包代码,这一步稍微复杂一点,先讲一下思路,首先进入微信开红包的界面:

查看图片

根上面讲过的一样,通过 cycript+logify我们可以轻松拿到开红包的入口函数,下一步,我们需要自己从 AsyncOnAddMsg的参数中构造抢红包函数的入参。

找注入点我就不再重复讲,直接上结果:

[WCRedEnvelopesReceiveHomeView OnOpenRedEnvelopes]

这显然是一个事件处理函数,它里面肯定会调用真正的拆红包逻辑

所以我们打开 hooper,找到这个方法然后观察方法体,发现它在最后调用了一个 selector:

WCRedEnvelopesReceiveHomeViewOpenRedEnvelopes

这应该是真正的拆红包逻辑,但是这个 selector没有参数,所以我猜想这个方法的作用应该是自己封装拆红包所需的数据,并调用底层服务来拆红包。

在hooper中搜索这个方法,观察一下,果然是这样的:

函数开始部分的汇编代码都是在构造dictionary,只有在最后调用了一个可以函数:

查看图片

这里说明一下,由于微信这一块的代码全都是 oc的,而 hooper可以直接将 oc反汇编到接近源码的水平,所以,还原过程基本不需要掌握多少汇编知识,具体的还原过程可以看下我之前发的文章:blog.csdn.net/heiby/artic…

最后一步,编写 tweak,替换 AsyncOnAddMsg函数并把自己的成果注入进去就 ok了。

6、注入工具——insert_dylib + install_name_tool

对于越狱机器来说,到这里已经大功告成了,但是想要在非越狱机器上跑,还需要几个步骤:

在非越狱机上面,一切都要靠自己,首先手动把你的库注入到目标二进制中,这一步使用 insert_dylib就可以了,它运行在 pc端,在命令行 cd到微信的二进制目录,执行命令:

insert_dylib @executable_path/xxx.dylib WeChat

因为我们的 hook代码是基于 cydiaSubstrate的,用l -L xxx.dylib来检查一下你的 tweak,这个依赖库在正版机上是没有的,我们需要把它从越狱机充 cp出来和你的 tweak一起拖进目标 app目录,并通过install_name_tool命令修改你的 tweak中对他的引用路径。

最后,用 codesign命令对微信 bundle里面所有的 dylib进行签名:

codesign -f -s "iPhone Developer:xxx" xxx.dylib

打包成ipa:

xcrun -sdk iphoneos PackageApplication -v WeChat.app -o ~/WeChat.ipa

再使用 iResign对 ipa进行签名,就可以安装到非越狱的机器上了。

注意一下,如果你不想使用 iResign,在执行 xcrun之前,还需要对微信的二进制文件进行签名:

codesign -f -s "iPhone Developer:xxx” —entitlements Entitlements.plist WeChat.app

经常有人问 Entitlements.plist文件怎么写?照着这个来就行了,把 teamed和 bundle id改成你自己的:

查看图片


签名完成后可以通过ldid命令查看签入的内容:

ldid -e /path/to/WeChat

到这里入侵圆满结束!

二、常用入侵原理和反入侵方法总结

下面我们总结一下用到的几个工具:

  • dumpdecrypted

  • insert_dylib

  • cycript

第一个工具是砸壳用的,代码是开源的,而且相当简单,它并没有破解 appstore的加密算法,而是把自己注入到已经通过系统加载器解密的 mach-o文件,再把解密后的内存数据 dump出来,详细的原理这篇文章写的很清楚:bbs.iosre.com/t/dumpdecry…

那他是怎么注入的呢?就是利用了 iOS系统中 DYLD_INSERT_LIBRARIES这个环境变量,如果设置了 DYLD_INSERT_LIBRARIES 环境变量,那么在程序运行时,动态链接器会先加载该环境变量所指定的动态库;也就是说,这个动态库的加载优先于任何其它的库,包括 libc。

由于这个环境变量指定的动态库加载的时机实在是太早了,所以对于 app来说,除了代码混淆外,无良策;

但是我们可以在代码中通过判断环境变量来检测是不是被注入:

charchar *env = getenv("DYLD_INSERT_LIBRARIES");

如果方法返回非空,我们可以做一些上报之类的。

后面两个工具都是用来注入的

insert_dylib通过向 mach-o文件的 loadcommand段插入 LC_LOAD_DYLIB数据来加载第三方库。

对于 insert_dylib,我们可以通过在 Xcode的Build Settings中找到“Other Linker Flags”在其中加上-Wl,-sectcreate,__RESTRICT,__restrict,/dev/null指令来绕过 dylib加载额外的第三方库,具体的原理可参考 bbs.iosre.com/t/tweak-app…

但是破解这一招也非常简单,上面的链接也说了,用 0xED打开二进制文件,把__RESTRICT全局替换成其它名字即可。

cycript个人感觉是比较神奇的,它在进程运行时动态注入。

没有细看它的源码,网上资料称,它通过 taskfor_pid函数获取目标进程句柄,然后通过在进程内创建新线程并执行自己的代码。

对于 cycript这种 bt的行为,利用系统的 root权限在进程中创建线程并执行自己的代码,目前还没想到好的对策,如果有老司机有方法,希望能指导一下~

最后再说说 lldb反调试,网上大多都提到 ptrace系列函数,原理我就不多说,这里主要讲如何绕过它,有两种方法,先说第一种,直接通过汇编代码修改 ptrace的第一个参数,这样我们需要先知道在哪里调用了 ptrace。

用backboard服务启动启动目标程序:

debugserver -x backboard *:19999 /path/to/binary 

在pc端用lldb连接:

process connect connect://deviceIP:19999

然后在lldb中下符号断点

b ptrace,

在lldb中输入c命令之后看ptrace第一行代码的位置,继续输入命令:

p/x $lr 

找到函数返回地址,然后用:

image list -o -f

找到目标程序的基地址,这样就能用上面说的公式计算出偏移量,最后在 hooper中找到调用 ptrace的汇编代码

找到汇编代码的位置后,把 ptrace的第一个参数 1F,替换成 0A即可,下面是我的调试过程:

手机端:

查看图片

pc端:

查看图片

第二种简单又暴力,注入tweak,让 ptrace直接返回0即可,具体的代码非常简单,直接发出来:

//Tweak.xm
#import 
#import 
#import 

static int (*oldptrace)(int request, pid_t pid, caddr_t addr, int data);
static int newptrace(int request, pid_t pid, caddr_t addr, int data){
    printf("newptrace:%d\n\n",request);
    return 0;
}
%ctor {
    printf("Tweak for SkipPtrace  Start!\n\n");
    MSHookFunction((void *)MSFindSymbol(NULL,"_ptrace"), (void *)newptrace, (void **)&oldptrace);
}

总结

入侵的路有很多条,关键是要在开始阶段定好目标,并理清思路,不然很容易走进各种死胡同,还要学会面对失败,不要一条路走不通就放弃,最后呢,我们要善于借助各种工具,能用工具,干嘛还要去费力气。

今天分享就到这里,下面大家有问题可以提问哦!

问答环节

Q1:其实我挺好奇,这个能被破解,应该也会有被封堵的问题吧?

我们这里只是伪造了自己的参数,并调用微信原有的逻辑自动拆红包,所以技术上出了微信更新版本,是封不了的,但是如果你抢的太暴力,账号有可能被封,这里我们可以通过随机的延迟等操作来避免

Q2:我在分析 UI时候多用了一个 reveal的工具。

reveal的可视化做的比较强大,用来分析 ui很不错,有需要可以用

Q3:想问问那些安全类软件是如何防止 tweak,对微信支付宝的进程保护?

防止tweak上面我也讲到一些,不过都是从目标 app的代码层级来讲的,例如反 gdb和反注入,对于安全类软件来说,在非越狱的系统上,基本起不了作用,在越狱机上面,由于有 root权限,这时就能做很多事情了,例如检查 mach-o文件的 loadcommand、检查 DYLD_INSERT_LIBRARIES这种环境变量等

Q4:各种微信分身版能被微信后台准确的识别出来吗?如果可以识别,有哪些方方法可以去识别?

您指的是一机多装吧,ios系统通过 app的 bundleid来唯一识别一个 app,分身版大多是通过改 bundleid并重新签名和发布,在代码中可以通过监控自己 info.plist里面的 bundle id来识别是否被篡改,但是这也是不可靠的,因为黑客们还是可以通过 hook你的监控函数来绕开

Q5:看到你不少是根据方法名字面上来猜想它的意思,要是有的 app代码写的烂,我们反而不好弄了吧?还有如果红包的核心代码是用 C/C++的代码,这是不是就不能这样反汇编了?

确实会这样,代码写得烂,有点类似于“代码混淆”,会增加入侵的难度,如果核心代码是 c/c++,在汇编层面会增加阅读难度,但是只是难度增加了而已

Q6:对于哪些包括 watch和 extension的 App,在重签名时有哪些需要注意的呢? 重签名安装成功但启动就闪退可能是什么原因?

有 extension的app,在重签名时,需要记住每个 extension都需要用同样的证书单独签名,然后再对外层的 ipa进行签名,重签名后启动闪退,可以通过 xcode连接设备,点击 window->devices查看设备控制台,在控制台,会输出你那一个 dylib校验失败,还有失败的原因

Q7:听你分析逆向这么容易,那 ios防反编译有哪些方案?

ios防止反编译主要还是代码混淆,但是混淆的代价大家是知道的,而且混淆也不能完全阻止入侵,所以会得不偿失,因为这样,现在 ios开发很少用;还有一个方案就是反注入,上面讲过的,但是很容易被绕过

Q8:Android的一个安全加固保护是通过设置 PTRACEME来防止外部程序来 ptrace自己,如果 iOS APP也这样设置了,会不会导致其中一些逆向机制失效呢?

ptrace只是反调试的,不会影响逆向过程



如果您觉得我们的内容还不错,就请扫描二维码打赏作者并转发到朋友圈,和小伙伴一起分享吧~

查看图片


本文系腾讯Bugly独家内容,转载请在文章开头显眼处注明作者和出处“腾讯Bugly(http://bugly.qq.com)”