使用 Objdump 的结果构建控制流图答案

【问题标题】：Building a Control-flow Graph using results from Objdump使用 Objdump 的结果构建控制流图
【发布时间】：2010-11-25 04:50:10
【问题描述】：

我正在尝试构建通过调用 objdump -d 返回的装配结果的控制流图。目前我想出的最好的方法是将结果的每一行放入一个链表中，并将每一行的内存地址、操作码和操作数分开。我依靠 objdump 结果的常规性质将它们分开（内存地址是代表每一行的字符串中的字符 2 到字符 7）。

完成此操作后，我将启动实际的 CFG 指令。 CFG 中的每个节点都拥有一个起始和结束内存地址、一个指向前一个基本块的指针以及指向任何子基本块的指针。然后，我将检查 objdump 结果并将操作码与 x86_64 中所有控制流操作码的数组进行比较。如果操作码是控制流，我将地址记录为基本块的结尾，并根据操作码添加两个子指针（条件操作码）或一个（调用或返回）。

我正在用 C 语言实现它，它似乎可以工作，但感觉非常脆弱。有没有人有任何建议，或者我没有考虑到的任何事情？

感谢您抽出宝贵时间阅读本文！

编辑：

我们的想法是使用它来比较 DynamoRIO 生成的系统调用的堆栈跟踪与目标二进制文件的预期 CFG，我希望像这样构建它会促进这一点。我没有重新使用可用的东西，因为 A) 我并没有真正考虑过它和 B) 我需要将图形转换为可用的数据结构，以便我可以进行路径比较。我将看一下您所排的页面上的一些实用程序，感谢您为我指明了正确的方向。感谢您的cmets，我真的很感激！

【问题讨论】：

听起来像是一个合理的整体方法。当您看到间接调用时，您可能需要考虑该怎么做。另外，您说返回指令将有一个后继者——对于一个具有多个调用者的函数，这究竟是什么？调用和返回通常不包含在 CFG（例如 LLVM IR）中。 “正确”的答案取决于您在构建 CFG 后打算如何处理它。
有趣的方法。有几种工具（参见en.wikipedia.org/wiki/Call_graph）可用于从源代码创建 CFG。您是否有特定原因要采用这种方法而不是重复使用可用的东西？
你是如何解析函数指针的？我也在编写类似的程序，但仍然想知道如何解析函数指针？
基本上，我不是。现在，我将函数指针视为“黑盒”基本块，并在函数指针调用之后的下一个地址开始下一个基本块，函数指针调用将返回到该地址。不太理想，但我还没想出办法找到寄存器地址。

标签： c assembly x86-64 objdump control-flow-graph

【解决方案1】：

您应该使用专为程序分析而设计的 IL。有几个。

DynInst 项目 (dyninst.org) 有一个升降器，可以将 ELF 二进制文件转换为功能/程序的 CFG（或者它在我上次查看时出现过）。 DynInst 是用 C++ 编写的。

BinNavi 使用来自 IDA（交互式反汇编程序）的输出来构建 IDA 识别的控制流图之外的 IL。我还推荐 IDA 的副本，它可以让您直观地检查 CFG。一旦你在 BinNavi 中有一个程序，你就可以得到一个函数/CFG 的 IL 表示。

函数指针只是静态识别控制流图的麻烦的开始。跳转表（在某些情况下为 switch case 语句生成的类型，在其他情况下是手动生成的）也会带来麻烦。我所知道的每一个代码分析框架都以一种非常依赖启发式的方法来处理这些问题。然后你有异常和异常处理，还有自修改代码。

祝你好运！您已经从 DynamoRIO 跟踪中获得了大量信息，我建议您尽可能多地利用该跟踪中的信息...

【讨论】：

【解决方案2】：

我找到了你的问题，因为我有兴趣寻找同样的东西。我什么也没找到，为此写了一个简单的python脚本，然后把它扔到了github上： https://github.com/zestrada/playground/blob/master/objdump_cfg/objdump_to_cfg.py

请注意，我有一些启发式方法来处理永远不会返回的函数、32 位 x86 上的 gcc 堆栈保护器等......你可能想要也可能不想要这些东西。

我处理间接调用的方式与您的处理方式类似（基本上在图中有一个节点作为从间接返回时的源）。

希望这对任何希望在类似限制条件下进行类似分析的人有所帮助。

【讨论】：