本文来自于腾讯bugly开发者社区，非经作者同意，请勿转载，原文地址：http://dev.qq.com/topic/5791da152168f2690e72daa4
“8小时内拼工作，8小时外拼成长”这是大家共同的理想。除了每天忙于工作外，我们都希望能更多地区吸收领域内的新知识与新技能，从而走向人生巅峰。
Dev Club 是一个交流移动开发技术，结交朋友，扩展人脉的社群，成员都是经过审核的移动开发工程师。每周都会举行嘉宾分享，话题讨论等活动。
上一期我们邀请了腾讯 WXG iOS 开发工程师“姚海波”分享了《微信读书 iOS性能优化》。
本期，我们邀请了腾讯 CDG iOS 开发工程师“何兆林”为大家分享《iOS黑客技术大揭秘》。
如何加入 Dev Club？
移动端开发经验 >= 2 年，微信扫描下方群管理微信二维码，备注姓名-公司(或产品) 申请加入。
分享内容简介：
在黑客的世界里，没有坚不可破的防护系统，也没有无往不胜、所向披靡的入侵利器，有时候看似简单的问题，破解起来也许花上好几天、好几个月，有时候看似很 low 的工具往往能解决大问题；我们以实现微信自动抢红包为引子，逐步展开 iOS 黑客入侵常用的几种武器，并简单的讲解一些常用的反入侵策略，以及如何破解反入侵策略，虽然抢红包的破解代码网上有很多，但是我们要讲的是这些代码是用什么工具分析出的，为什么要这样写？
内容大体框架:
- 让目标程序破茧而出 －－ dumpdecrypted
- 运行时分析 －－ cycript
- 追踪神器 －－ logify
- 反汇编工具 －－ hopper
- 断点调试工具 －－ lldb+debugserver
-
注入工具 －－ insert_dylib + install_name_tool
分享人介绍： 何兆林 通讯充值与彩票业务部 iOS开发工程师。
负责过的产品：QQ彩票、QQ电影票 iOS客户端，目前主要负责 QQ彩票 iOS客户端的开发。
下面是本期分享内容整理
大家晚上好，我是来自 CDG的 jolinhe，目前在做qq彩票项目，负责 iOS侧的插件化和整体架构。
越狱和入侵是我的业余爱好，正好08和09年的时候，在网龙积累了一些越狱开发经验，所以今天跟大家分享一下 iOS入侵方面的工具和手段。
为了避免纸上谈兵：
- 第一部分我们就拿微信来开刀，讲解一下如何运用这些工具来找到和实现自动抢红包功能的；
-
第二部分我们再总结一下常用的入侵原理和反入侵方法。
开始之前，我们需要把环境搞起，硬件方面，需要：
- 一台越狱手机
-
一台装了开发环境的 Mac电脑
软件方面内容提纲已经列出来了，需要注意的是它们有一些是手机端的，一些是 PC端的，用到的时候我会细讲。
群里不乏老司机，这里我假设大家对于 ssh、theos、class_dump、hook这些工具和技术都已经有所涉猎了，如果有不清楚的，欢迎私下交流。
一、微信实现自动抢红包功能
言归正传，要实现自动化抢红包，首先我们需要理清思路：
- 第一步：需要拦截微信的消息流，在哪里拦截？
- 第二步：在这些信息流中分辨出哪些消息是红包？
-
第三步：在合适的地方插入自己的“抢”红包代码。
1、让目标程序破茧而出——dumpdecrypted
因为直接从 AppStore下载下来的二进制文件都是加了壳的，所以为了让它的内核破茧而出，我们需要砸壳操作。
所以第一个工具就是 dumpdecrypted，这个工具是手机端的，可以通过 cydia安装，安装后文件路径是：
/usr/lib/dumpdecrypted.dylib
在实际使用时，可以通过 pp助手把这个文件 copy到目标程序的 documents目录，然后ssh进手机终端，cd到 documents目录，执行：
DYLD_INSERT_LIBRARIES=dumpdecrypted.dylib WeChatPath
执行完后会再 documents目录生成一个砸完壳后的二进制文件
2、运行时分析——cycript
砸完壳之后，我们再 dump出头文件，但是微信的类太多了，头文件有几百个，如此多的头文件，让人眼花缭乱，所以要找到突破口，我们得缩小范围，我喜欢用的思路是从 ui入手，先找到微信对话界面的 controller，然后再追踪 controller中对应的消息处理函数。
这样第二个工具 cycript 隆重出场了，它也是个手机端的工具，用于查看 app运行时数据，大伙儿可以通过 cydia安装，安装完之后，ssh到越狱手机的终端。
先找到微信的进程id：ps aux | grep WeChat
再执行：cycript -p 微信的pid完成了注入，进入到 cycript提供的终端。
这时候进入在手机上进入微信的聊天窗口，例如：
然后在 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反汇编到接近源码的水平，所以，还原过程基本不需要掌握多少汇编知识，具体的还原过程可以看下我之前发的文章：http://blog.csdn.net/heiby/article/details/51792151
最后一步，编写 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出来，详细的原理这篇文章写的很清楚：http://bbs.iosre.com/t/dumpdecrypted/465
那他是怎么注入的呢？就是利用了 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加载额外的第三方库，具体的原理可参考 http://bbs.iosre.com/t/tweak-app-app-tweak/438但是破解这一招也非常简单，上面的链接也说了，用 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 <substrate.h>
#import <mach-o/dyld.h>
#import <dlfcn.h> 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是一款专为移动开发者打造的质量监控工具，帮助开发者快速，便捷的定位线上应用崩溃的情况以及解决方案。智能合并功能帮助开发同学把每天上报的数千条 Crash 根据根因合并分类，每日日报会列出影响用户数最多的崩溃，精准定位功能帮助开发同学定位到出问题的代码行，实时上报可以在发布后快速的了解应用的质量情况，适配最新的 iOS, Android 官方操作系统，鹅厂的工程师都在使用，快来加入我们吧！