欢迎贡献

待处理

这个页面已经过时了。我们需要更新它。

angr 是一个庞大的项目，保持更新非常困难。在这里，我们列出了一些我们非常希望社区贡献的重大待办事项，希望能够引导社区参与。它们（将）具有广泛的复杂度，应该能满足各个技能水平的人！

我们在 GitHub 仓库中标记了一些适合社区参与的问题为“Help wanted”。要查看这些问题的完整列表，请使用这个 GitHub 搜索!

文档

angr 的许多部分都缺乏文档或没有文档。我们在这个领域迫切需要社区的帮助。

API

我们的文档一直滞后。我们在 github 上创建了几个相关的 issue，以了解还缺少什么：

  1. angr

  2. claripy

  3. cle

  4. pyvex

GitBook

这本书还缺少一些核心内容。具体来说，以下方面可以改进：

  1. 完成书中的 TODO 待办事项。

  2. 重新组织示例页面，使其结构更加合理。目前，大部分示例都非常冗余。可以考虑创建一个简单的表格，列出大部分示例，以使页面不那么压抑。

angr 课程

开发一种类似“课程”的东西，以帮助人们开始使用 angr ，将非常有益。在这方面已经迈出了一些步伐 here ，但还需要更多的扩展。

理想情况下，这门课程应该有一个逐渐增加难度的实践部分，要求人们使用越来越多的 angr 功能。

复现现有的相关研究工作

不幸的是，并不是所有的研究都基于angr ;-)。在这一点得到解决之前，我们需要定期在angr的基础上实现相关工作，以使其在框架的范围内可重用。本节列出了一些适合在 angr 中重新实现的相关工作。

用于动态符号执行的冗余状态检测

Bugrara 等人描述了一种方法来识别和修剪冗余状态，将符号执行的速度提高了多达 50 倍，覆盖率提高了 4%。这将对提高 angr 的探索部分非常有用。论文在这里： http://nsl.cs.columbia.edu/projects/minestrone/papers/atc13-bugrara.pdf

软件系统的多路径实时分析

与其为每个系统调用开发符号摘要，我们可以使用 S2E 提出的一种技术，将必要的数据具体化并将其分派给操作系统本身。这将使 angr 适用于比它目前能够分析的 更多 二进制文件集。

尽管这一技术主要对系统调用有用，但一旦实现，它也可以轻松应用于任何代码位置（例如库函数）。通过仔细选择哪些库函数使用这种方法，可以大大提高 angr 的可扩展性。（译者注：这部分好像已经实现了？叫做 angr_symbion ），就是混合符号执行和具体执行的技术）

开发

我们有几个项目需要主要进行开发工作。

angr-management

angr GUI angr-management 需要您的改进！以一种可用的图形方式更多地展示 angr 的功能将非常有用！

IDA 插件

angr 的许多功能可以通过IDA进行展示。例如，angr 的数据依赖图可以通过 IDA 中的注释进行展示，或者可以使用符号执行解析混淆的值。

其他架构

支持更多的架构将使 angr 变得更加有用。 使用 angr 支持新的架构需要：

  1. 将架构信息添加到 archinfo

  2. 添加 IR 转换。这可以是对 PyVEX 的扩展，生成 IRSB ，或者是另一种 IR。

  3. 如果您的 IR 不是 VEX ，请添加一个 SimEngine 来支持它。

  4. 添加或修改一个 angr.SimCC 来支持 SimProcedures（包括系统调用）。

  5. 添加或修改一个 angr.SimOS 来支持初始化活动。

  6. 创建一个 CLE 后端来加载二进制文件，或者如果二进制文件格式是 ELF ，则扩展 CLE ELF 后端以识别新的架构。

新架构的想法：

  • PIC、AVR 和其他嵌入式架构

  • SPARC（有一些初步的 SPARC 支持 here ）

新 IR 的想法：

  • LLVM IR（通过这个，我们可以将 angr 从仅仅是一个二进制分析框架扩展为一个程序分析框架，并在其他方面扩展其功能！）

  • SOOT（没有理由 angr 不能分析 Java 代码，尽管这样做需要对我们的内存模型进行一些扩展）

环境支持

我们在 angr 中使用“函数摘要”的概念来模拟操作系统的环境（即其系统调用的效果）和库函数。扩展这一概念将极大地增加 angr 的实用性。这些函数摘要可以在 这里 找到。

其中一个特定的子集是系统调用。与库函数 SimProcedures 相比（如果没有这些函数，angr 总是可以执行实际的函数），我们对于缺少的系统调用几乎没有解决方案。每个实现的系统调用都扩展了 angr 可以处理的二进制文件集。

设计问题

关于将其他功能集成到 angr 中存在一些未解决的设计挑战。

类型注释和类型信息的使用

angr 对类型的支持还处于初级阶段，它可以从头文件中解析出类型。然而，这些类型没有很好地暴露出来，无法做任何有用的事情。改进这种支持将使得可能对某些内存区域进行某些类型信息的注释，并与其进行智能交互。例如，考虑与链表交互的情况：print state.mem[state.regs.rax].llist.next.next.value。

（编辑者注：实际上，您已经可以做到这一点）

研究挑战

在 angr 的发展历程中，它一直在研究程序分析的新领域。在这里，我们列出了几个可以解决的独立研究项目。

语义函数识别/差异化

当前的函数差异化技术（TODO：一些示例）存在一些缺点。对于 CGC，我们创建了一个基于语义的二进制识别引擎（ https://github.com/angr/identifier ），它可以根据测试用例识别函数。有两个改进的方向，每个方向都是一个独立的研究项目：

  1. 目前，该组件使用的测试用例是人工生成的。然而，可以使用符号执行来自动生成可用于识别其他二进制文件中给定函数实例的测试用例。

  2. 通过创建达到“足够高”的代码覆盖率的测试用例，我们可以通过将这组测试用例应用于同一函数的另一个实现并分析代码覆盖率的变化来检测功能的变化。这可以作为语义函数差异的依据。

将 AFL 的路径选择标准应用于符号执行

AFL 在模糊测试中通过跟踪每个路径的控制流转换，出色地识别了“独特”的路径。同样的标准可以应用于符号探索，考虑到其简单性，效果可能相当好。

总体研究方向

在程序分析领域，有一些未被充分探索的方向。我们在这里列出了几个研究的总体方向，但读者应当注意，这些方向很可能描述的是完整博士论文的潜在课题。

进程交互

几乎所有二进制分析领域的工作都集中在单一二进制文件上，但在现实世界中，通常并不如此。例如，传递给 CGI 程序的输入类型依赖于 Web 服务器的预处理。目前，angr 没有办法支持多个并发进程的分析，且在该领域存在许多未解问题（例如，如何建模并发行为）。

进程内并发

与进程之间的交互建模类似，对于同一进程中并发线程的交互了解还很少。目前，angr 无法对此进行推理，从理论角度来看，如何处理这个问题还不清楚。

这个问题的一个子集是分析信号处理程序（或硬件中断）。每个信号处理程序可以被建模为一个可以在触发信号时的任何时间执行的线程。了解何时分析这些处理程序是一个开放的问题。一个可以推理中断效果的系统是 FIE。

路径爆炸

许多方法（例如 Veritesting ）试图缓解符号执行中的路径爆炸问题。然而，尽管有这些努力，路径爆炸仍然是阻碍符号执行成为主流的主要问题。

angr 提供了一个出色的基础来实现控制路径爆炸的新技术。大多数方法可以很容易地实现为 ExplorationTechnique ，并快速评估（例如，在 CGC 数据集 上）。