写给 iOS 开发者的 Hopper + lldb 简介
最近，关于 @Steipete 在Radar发布的帖子，笔者看到很多人在问「你是怎么理解那个伪代码的」。笔者想写博客已经有一段时间了，现在正好就此发表第一篇博文。笔者在一个叫 Hopper 的工具上花了很多时间（这是笔者的必备工具之一），虽然它很神奇，但是刚接触的时候可能会让人感觉不知所措。本篇博文的目的是帮助那些回避或不熟悉逆向工程的人填补知识空白。
你是否曾经疑惑，别人是怎么获取下图所示的私有 API伪代码的？这实际上很简单，而且是找出 UIkit中那些烦人错误的好方法。使用 Hopper 这样的工具后，只需要点几下鼠标，就能得到伪代码。更酷的还在后头。有了 Obj-C runtime 和 lldb，即使不能提高伪代码的语法正确性，也一定能提高伪代码的可读性！让我们深入探讨一下吧！
Decompilation of a method in UIKit.
在 UIKit 中反编译一个方法。
什么是 Hopper？
摘自 Hopper 主页的定义：“Hopper 是一种适用于 OS X 和 Linux 的逆向工程工具，可以用于反汇编、反编译和调试 32位/64位英特尔处理器的 Mac、Linux、Windows 和 iOS 可执行程序！”用更简洁的话来说，这代表我们可以用一个编译二进制（你的 iOS app，UIKit 二进制等等）生成你之前看到的伪代码！
反汇编 vs 反编译
反汇编和反编译有什么区别？很简单，反汇编（通过反汇编程序来实现）是指将 opcode （二进制原始字节）转化成对应的汇编指令（也叫 mnemonics）的过程。下图展示了一个被反汇编的文件。反编译（通过反编译程序来实现）是指将该汇编指令转化成伪代码的过程。下图分别为同一个文件的反汇编结果与反编译结果。
在本文发表时，Hopper的售价只有90美元，这简直就是白送。对那些了解这个工具的威力的人来说，这个工具完全可以卖到几百美元。因此，如果你觉得这个价格贵，再好好考虑一下吧！他们也提供功能受限的免费试用版本，不过用来了解本文内容应该够用了。
开篇
在下载并安装 Hopper 之后，打开并按顺序点击 “File -> Read Executable to Disassemble...”
注意 x86（32位） 和 x86（64位）两种文件的存在。
在接下来的页面中点击“OK”，你就会来到 Hopper 的主界面。Hopper 会开始分析 Mach-O 二进制文件，在这个过程中，你会看到界面右下角的“Working...”状态提示。因为 UIKit 是个大文件，可能需要一段时间才能完成分析。如果是小文件，分析很快就能完成。现在，如果你觉得这个界面太费解，不要担心，我们只需要关注整个界面中的三个按钮。
首先是左侧操作面板中的“Labels”和“Strings”。“Labels”会向你展示二进制文件中包含的所有类和方法（你还会看到其他文件，不过本教程中只需要关注方法签名）。
下拉查看所有的方法！
现在点击左侧操作面板中的“String”，你会看到 app 中所有的字符串。这就是为什么你绝对不能对 app 中的重要字符串进行硬编码。
检查你自己的 app，确保没有对任何你不想让别人看到的东西硬编码！
做好准备
回到“Labels”界面，注意搜索框。在这里你可以搜索任何类和方法的名称。输入“UIPopoverPresentationController dimmingView”，查看搜索结果。点击“-[UIPopoverPresentationController dimmingViewWasTapped:]”签名，注意主界面就会跳转到“-[UIPopoverPresentationController dimmingViewWasTapped:]”的反汇编界面。
b 是设置断点的简称。
现在继续程序执行，一旦启动“-[UIPopoverPresentationController dimmingViewWasTapped:]”，就会启动你所设置的断点。遵循示例项目中的操作指令（双击黄色区域）。
如果进展顺利，你就会看到断点启动，然后看到方法签名与对应的汇编指令。为了好玩，你可以比较一下 Xcode 的反编汇结果和 Hopper 产生的结果。它们应该基本一致。如果存在不同，可能是因为它们使用的汇编语法不同，一个是 Intel，一个是 AT&T。如果你遇到其他情况，请看文末的“其他”部分。
就是感觉挺累的，这段时间，总之，想请假，觉得坐在这里，也没很大的意义。
到了这一步，你可能会因为不了解汇编而有些担心，但是笔者要告诉你，你真的不需要懂。只要有一点儿直觉，加上反复尝试，你就可以完成任务了。换句话说，我们现在所要做的就是让反编译过程稍微简单一些（替换寄存器等等）。这样产生的伪代码会好懂一些，不过如果你遇到伪代码难懂的情况，可以采用同样的理念对伪代码进行清理。
好了，现在该左右对照反汇编和反编译了。笔者常用的做法是寻找反编译的关键点，比如说调用 if 语句或者方法的时候。这些关键点对应的编译指令很容易猜到，只需要逐行浏览编译。如果你的关键点是一个 if 语句，就去找测试或 cmp（compare）指令。
在本文中，笔者选的是反编译中的第一个 if 语句，并在 Xcode 的反编译结果中搜寻测试或 cmp（compare）指令。如下图所示，笔者找到了一个测试指令。
可能需要尝试几次，要有耐心！
现在在那个内存地址（你的地址可能不同）用“b 0x148b95c”设置一个断点。
继续程序执行，期待你的断点被启动。
下一步就会见证 lldb 和 Obj-C runtime 的神奇之处。我们要清理反编译结果中大部分艰涩难懂的部分。如果你不熟悉反编译过程中的 eax、edi、和 esiare，它们就是 x86 CPU 寄存器，我们可以把它们转存到 lldb 中。如果你看到 r0、r1、r16等等，那些是 ARM 框架。如果这些你全都看不懂，别担心，只要把它们和伪代码匹配就好了。
在 lldb 提示框中输入“register read”，按回车键。
CPU 寄存器。根据你所用的不同框架，显示不同名字。
显示出来的是 CPU 寄存器及其内容值。现在你可以用 lldb 中显示的值替代反编译结果中的寄存器。
不要盲目地更换反编译的 esi、edi 和其他寄存器，因为在执行不同代码时，它们可能代表不同的值。这就回到了明智选择关键点的重要性。笔者的操作步骤如下：
- 在一个关键点设置断点，继续程序执行
- 转储寄存器
- 用 lldb 生成的内容值替换反编译结果中关键点以上的缓存器
举个例子，我们的关键点是 dimmingViewWasTapped 方法中的第一个 if 语句，一旦断点被启动，转储寄存器，替换伪代码中 if 语句以上的缓存器。如果你跟踪伪代码，发现关键点之后的缓存器未重置，那就更新这些内容值。
如果你进行这个操作，就会发现 edi 包含委托选择器，但是 esi 寄存器包含一个 hex 值。这就更加费解了，不过幸好我们可以利用 Obj-C runtime来搞清楚 esi 到底是什么。
复制 esi 的内存地址，输入“po [0x78657dd0 class]”，然后按回车键。
Very nice!
太棒了！
啦啦啦，现在我们知道 esi 是什么了，并且可以利用这个值来提升反编译效果。
笔者发现反编译说“esi = self”，你们可能已经推断出esi = UIPopoverPresentationController，但是这个推断不一定总是成立。而且，如果还不明显，你可以尝试“po [0x78657dd0 anyMethodThatThisClassImplements]”。如果你对某个对象的内部很感兴趣，这个操作效果超好。
到了这一步，再说下去就会变成选个新要点的重复说教了，所以笔者打算见好就收了！如有任何问题或反馈，请在推特上联系笔者 @bartcone。
其他问题
有 Hopper 的替代工具吗？
- 有的，就是 IDA Pro（HexRays 是他们的反编译器），不过除非你想一掷千金，不然 Hopper 就是你最好的选择。他们还提供免费版本，不过只有反汇编器。
我的反编译和反汇编结果的缓存器显示的是 r，不是 e
- 你反编译或者反汇编了 x86 64位文件。
OneAPM Mobile Insight 以真实用户体验为度量标准进行 Crash 分析，监控网络请求及网络错误，提升用户留存。访问 OneAPM 官方网站感受更多应用性能优化体验，想阅读更多技术文章，请访问 OneAPM 官方技术博客。
本文转自 OneAPM 官方博客
