LLDB+Debugserver动态调试--寻找突破口

根据LLDB+Debugserver动态调试--建立手机到mac的连接 最后的步骤进入lldb之后，整个程序立马会断点到整个程序的最入口处：

[email protected]

基本所有的程序刚进入lldb调试时都会断到这个地方，此时只有主程序的二进制加载进来，主程序引用的系统或是第三方的framework和dylib库都还没有加载进来。

如果是对主程序调试，此时便可以通过”image list“查看主程序二进制文件的ASLR(偏移地址)，然后计算需要下断点的地址。
如果是对系统或是第三方的framework和dylib调试，则先”b main“一下，表示断点程序中所有包含main方法的函数，会有非常多的方法被下断点，没关系，输入”c“ 继续运行程序，此时会断点到之前设置的某一个包含main关键字的方法，此时所有的系统或是第三方的framework和dylib都已经加载出来，可以通过”image list“查看偏移了。

如何寻找突破口？

1. 根据UI
   比如此处我调试的一个游戏，被第三者注入了两个dylib库，因此每次打开游戏都会弹框提示验证UDID，否则无法正常使用：

   
   
   IMG_4489.PNG
   
   

   通过Reveal、LookIn等UI分析工具定位，发现此弹框是一个名为TBAlertViewController的控制器，继承自UIViewController，于是通过class-dump、Hopper静态搜索这个”TBAlertViewController“，如果能找到便可以顺腾摸瓜，找到顶级调用的地方。
   但遗憾的是class-dump出来的头文件压根儿没有这个头文件，Hopper之中也无法搜索到这个字符串，只能怀疑是做了混淆或是采用Rect等跨平台脚本产生的。

怎么办？使用lldb各种打断点尝试！
这个弹框是属于新建window的rootViewController，所以

(lldb) br s -r "setRootViewController"

此命令会遍历整个工程,只要含该字符串的方法、函数都会下断点，终于在一次调用中捕获到了”TBAlertViewController“

(lldb) po $x2
(lldb) TBAlertViewController

顺腾摸瓜吧！

2. 根据打印日志

   
   
   [email protected]
   
   

   打开mac的”控制台“程序，观察目标app的各种打印输出，根据打印字符串到hopper中搜索对应的调用点，然后一层一层定位

3. 待更新。。。