转载

写给 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 ）的过程。下图展示了一个被反汇编的文件。 反编译 （通过 反编译程序 来实现）是指将该汇编指令转化成伪代码的过程。下图分别为同一个文件的反汇编结果与反编译结果。

写给 iOS 开发者的 Hopper + lldb 简介

在本文发表时， Hopper 的售价只有90美元，这简直就是白送。对那些了解这个工具的威力的人来说，这个工具完全可以卖到几百美元。因此，如果你觉得这个价格贵，再好好考虑一下吧！他们也提供功能受限的免费试用版本，不过用来了解本文内容应该够用了。

开篇

在下载并安装 Hopper 之后，打开并按顺序点击 “ File -> Read Executable to Disassemble... ”

写给 iOS 开发者的 Hopper + lldb 简介

点击 Read Exectuble to Disassemble 来开始反汇编。

在这里，你需要点击用于试验的二进制文件并点击“ Open ”。在本文中，我们用的是以下路径的 UIKit 二进制文件：

你可能需要更新一些目录名称，不过以上路径已经提示了大致的方向。这是模拟器使用的 x86 二进制文件，也是本文要关注的文件。ARM 二进制文件储存在设备上，并且在运行时加载。点击打开之后，你将会看到下图所示画面。UIKit 是个很肥的二进制文件，也就是说它包含了多个二进制文件。在示范的 UIKit 中，包含 x86 32位和64位。我们将要反汇编32位的文件。确保选中该文件并点击“ Next ”。

写给 iOS 开发者的 Hopper + lldb 简介

注意 x86（32位）和 x86（64位）两种文件的存在。

在接下来的页面中点击“ OK ”，你就会来到 Hopper 的主界面。Hopper 会开始分析 Mach-O 二进制文件，在这个过程中，你会看到界面右下角的“ Working... ”状态提示。因为 UIKit 是个大文件，可能需要一段时间才能完成分析。如果是小文件，分析很快就能完成。现在，如果你觉得这个界面太费解，不要担心，我们只需要关注整个界面中的三个按钮。

首先是左侧操作面板中的“ Labels ”和“ Strings ”。“ Labels ”会向你展示二进制文件中包含的所有类和方法（你还会看到其他文件，不过本教程中只需要关注方法签名）。

写给 iOS 开发者的 Hopper + lldb 简介

下拉查看所有的方法！

现在点击左侧操作面板中的“ String ”，你会看到 app 中所有的字符串。这就是为什么你绝对不能对 app 中的重要字符串进行硬编码。

写给 iOS 开发者的 Hopper + lldb 简介

检查你自己的 app，确保没有对任何你不想让别人看到的东西硬编码！

做好准备

回到“ Labels ”界面，注意搜索框。在这里你可以搜索任何类和方法的名称。输入“ UIPopoverPresentationController dimmingView ”，查看搜索结果。点击“ -[UIPopoverPresentationController dimmingViewWasTapped:] ”签名，注意主界面就会跳转到“ -[UIPopoverPresentationController dimmingViewWasTapped:] ”的反汇编界面。

写给 iOS 开发者的 Hopper + lldb 简介

搜索方法名称和类。

如果你不了解汇编指令，这个界面就没有太大帮助，请查看界面右上角，注意那个带有代码的按钮。这个按钮可以开启反编译过程，并产生伪代码。 点下去吧 ！

写给 iOS 开发者的 Hopper + lldb 简介

没那么难用，对吧？？

在调试第三方 SDK 或者查看自己的 app 时，这个工具效果非常好。

一般笔者在查找程序错误时会采用以下步骤:

在代码中找出自认为导致问题的那个文件，然后打开 Hopper
搜索那个类和方法名称，然后进行反编译
通过反编译，我可以很容易就能收集方法签名，并在 lldb 中设置它们的断点（参见 lldb 部分）。

以上就是全部操作，完全没有一点删减。如果你不想再看，可以到此为止，不过笔者在工作流程中添加了 lldb 操作来对伪代码进行更进一步的清理！

lldb

首先，下载 @Steipete 最近发布在 Radar 中的示范代码。打开项目之后，笔者一般喜欢把调试构架设成“ *$(ARCHS_STANDARD_32_BIT) * ”，因为这样会让编译过程更加友好（前提是已经从给定的二进制文件中反编译了32位文件）。

在私有方法中设置断点

好了，一般来说，Hopper 产生的伪代码就已经能满足你的需求了，不过有时候它会比较难懂，需要进行一些清理工作。这就到了 Obj-C runtime 和 lldb 大显身手的时候了。

首先，在 模拟器 中打开示范代码，通过调试暂停程序执行。暂停后，代码会转存到 lldb中，在这里，你可以给选定的任何方法签名设置断点。输入“ b -[UIPopoverPresentationController dimmingViewWasTapped:] ”，给“ -[UIPopoverPresentationController dimmingViewWasTapped:] ”设置断点，然后按回车键。调试控制台界面与下图类似：

写给 iOS 开发者的 Hopper + lldb 简介

b 是设置断点的简称。

现在继续程序执行，一旦启动“ -[UIPopoverPresentationController dimmingViewWasTapped:] ”，就会启动你所设置的断点。遵循示例项目中的操作指令（双击黄色区域）。

如果进展顺利，你就会看到断点启动，然后看到方法签名与对应的汇编指令。为了好玩，你可以比较一下 Xcode 的反编汇结果和 Hopper 产生的结果。它们应该基本一致。如果存在不同，可能是因为它们使用的汇编语法不同，一个是 Intel，一个是 AT&T 。如果你遇到其他情况，请看文末的“其他”部分。

就是感觉挺累的，这段时间，总之，想请假，觉得坐在这里，也没很大的意义。到了这一步，你可能会因为不了解汇编而有些担心，但是笔者要告诉你，你真的不需要懂。只要有一点儿直觉，加上反复尝试，你就可以完成任务了。换句话说，我们现在所要做的就是让反编译过程稍微简单一些（替换寄存器等等）。这样产生的伪代码会好懂一些，不过如果你遇到伪代码难懂的情况，可以采用同样的理念对伪代码进行清理。

好了，现在该左右对照反汇编和反编译了。笔者常用的做法是寻找反编译的 关键点 ，比如说调用 if 语句或者方法的时候。这些关键点对应的编译指令很容易猜到，只需要逐行浏览编译。如果你的关键点是一个 if 语句，就去找测试或 cmp （compare）指令。

在本文中，笔者选的是反编译中的第一个 if 语句，并在 Xcode 的反编译结果中搜寻测试或 cmp（compare）指令。如下图所示，笔者找到了一个测试指令。

写给 iOS 开发者的 Hopper + lldb 简介

可能需要尝试几次，要有耐心！

现在在那个内存地址（你的地址可能不同）用“ 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] ”，然后按回车键。

写给 iOS 开发者的 Hopper + lldb 简介

Very nice!

太棒了！

啦啦啦，现在我们知道 esi 是什么了，并且可以利用这个值来提升反编译效果。

笔者发现反编译说“ esi = self ”，你们可能已经推断出esi = UIPopoverPresentationController，但是这个推断不一定总是成立。而且，如果还不明显，你可以尝试“ po [0x78657dd0 anyMethodThatThisClassImplements] ”。如果你对某个对象的内部很感兴趣，这个操作效果超好。

到了这一步，再说下去就会变成选个新要点的重复说教了，所以笔者打算见好就收了！如有任何问题或反馈，请在推特上联系笔者 @bartcone 。