angr是一个巨大的项目，很难跟上。
在这里，我们列出了一些我们希望社区能够贡献的重大待办事项，希望它能够引导社区参与。它们(将)有广泛的复杂性，并且应该有适合所有技能水平的东西!
我们在我们的github知识库上标记问题，这将有利于社区参与“需要帮助”。要查看这些的详尽列表，使用这个github搜索!
文档
angr很多方面都很少或根本没有文档。在这些部分，我们迫切需要社区的帮助。
API
我们总是在文档方面落后。我们在github上创建了几个跟踪问题，以了解仍然缺少什么:
GitBook
这本书缺少了一些核心领域。具体来说，以下方面可以改进:
- 完成书中一些待办事项。
- 以合理的方式组织示例页面。现在，大多数例子都是多余的。如果能有一个简单的表格来显示其中的大部分内容，那么这个页面就不会那么难以驾驭了。
angr课程
开发一种“课程”来让人们开始angr将是非常有益的。在这里已经有了一些，但更多的扩展将是有益的。
理想情况下，这门课程应该有动手操作的部分，难度会越来越大，这就需要人们越来越多地使用angr的功能。
研究重新实现
不幸的是，并不是每个人的研究都基于angr ;-)。在解决这个问题之前，我们需要定期在angr之上实现相关工作，以使其在框架范围内可重用。本节列出了在angr中重新实现的一些相关工作。
动态符号执行的冗余状态检测(Redundant State Detection for Dynamic Symbolic Execution)
Bugrara等人描述了一种识别和修剪冗余状态的方法，将符号执行的速度提高了50倍，覆盖范围提高了4%。这对angr来说非常棒，作为一个探索技术。论文在这里:http://nsl.cs.columbia.edu/projects/minestrone/p apers/atc13-bugrara.pdf
软件系统内部多路径分析(In-Vivo Multi-Path Analysis of Software Systems)
我们可以使用S2E提出的一种技术来具体化必要的数据，并将它们分派给操作系统本身，而不是为每个系统调用开发符号集。这将使angr适用于比目前所能分析的更大的二进制文件集。
虽然这对于系统调用是最有用的，但一旦实现，它就可以简单地应用到代码的任何位置(例如，库函数)。通过仔细选择像这样处理的库函数，我们可以大大提高angr的可伸缩性。
开发
我们有几个主要需要开发工作的项目。
angr-management
angr-GUI，angr-management需要大量的工作。以下是一个不详尽的清单，列出了目前愤怒管理中所缺失的内容:
- 一个导航工具栏，显示程序内存空间中的内容，就像IDA Pro的导航工具栏一样。
- 基于文本的程序反汇编视图。
- 更好的视图来展示在路径探索过程中程序状态的细节，包括可修改的寄存器视图、内存视图、文件描述符视图等。
- 展示引用信息的GUI。
以一种可用的、图形化的方式展示angr的功能将非常有用!
IDA插件
angr的大部分功能可以通过IDA公开。例如，angr的数据依赖关系图可以通过注释在rda中公开，或者可以使用符号执行来解析模糊的值。
额外架构
更多的架构支持将使angr更加有用。用angr支持一个新的架构需要:
- 向架构信息添加体系结构信息
- 添加IR翻译。这可能是PyVEX的扩展，产生IRSBs，或者完全是另一种IR。
3.如果你的IR不是VEX，添加一个SimEngine来支持它。 - 添加一个调用约定(angry.simcc)来支持SimProcedures(包括系统调用)
- 添加或修改一个angr.SimOS来支持初始化活动。
- 创建CLE后端以加载二进制文件，或者扩展CLE ELF后端以了解新的体系结构(如果二进制格式是ELF的话)。
新架构的想法：
- PIC, AVR，其他嵌入式体系结构
- SPARC(这里有一些libVEX对SPARC的初步支持)
新IR的想法
- LLVM IR(有了它，我们可以将angr从一个二进制分析框架扩展到一个程序分析框架，并以其他方式扩展它的功能!)
- SOOT(没有理由angr不能分析Java代码，尽管这样做需要对我们的内存模型进行一些扩展)
环境支持
我们在angr中使用“function summaries”的概念来建模操作系统的环境(例如，它们的系统调用的影响)和库函数。扩展它将极大地有助于增加angr的实用性。这些函数总结可以在这里找到。
其中一个特定的子集是系统调用。甚至比库函数SimProcedures(没有它，angr总是可以执行实际的函数)更重要的是，对于缺失的系统调用，我们有很少的变通方法。每个实现的系统调用都扩展了angr可以处理的二进制文件集。
设计问题
在将附加功能集成到angr中方面，存在一些突出的设计挑战。
类型注释和类型信息使用
angr对类型的支持尚不成熟，从某种意义上说，它可以从头文件中解析出类型。
然而，这些类型不能很好地暴露于做任何有用的事情。例如，通过改进这种支持，可以用特定的类型信息注释特定的内存区域，并与它们智能地交互。例如，考虑这样与一个链表交互。
print state.mem[state.regs.rax].llist.next.next.value
研究挑战
从历史上看，angr已经在研究程序分析的新领域中取得了进展。
在这里，我们列出了几个可以解决的独立研究项目。
语义功能识别/区分
目前的函数差分技术(TODO:一些例子)存在缺陷。对于CGC，我们创建了一个基于语义的二进制识别引擎(https://github.com/angr/identifier)，它可以根据测试用例识别函数。有两个方面需要改进，每个方面都有自己的研究项目:
- 目前，此组件使用的测试用例是人工生成的。然而，符号执行可以用来自动生成测试用例，这些测试用例可以用来识别其他二进制文件中给定函数的实例。
- 通过创建实现给定函数“足够高”的代码覆盖率的测试用例，我们可以通过将这组测试用例应用到相同函数的另一个实现并分析代码覆盖率的变化来检测功能的变化。这可以用作一个语义函数diff。
将AFL的路径选择标准应用于符号执行
在fuzzing过程中，AFL通过跟踪每条路径的控制流转换，在识别“唯一”路径方面做得很好。同样的度量标准也可以应用于符号探索中，考虑到它的简单性，它可能会做得很好。
首要研究方向
程序分析的一些领域还没有得到很好的探索。我们在这里列出了大致的研究方向，但读者应该记住，这些方向很可能描述了整个博士论文的潜在目标。
相互作用过程
几乎所有二进制分析领域的工作都处理单个二进制，但在现实世界中这通常是不现实的。例如，可以传递给CGI程序的输入类型依赖于web服务器的预处理。目前，在angr中还没有办法支持对多个并发进程的分析，而且在这个领域中还有许多开放的问题(例如，如何对并发操作建模)。
进程内并发
与进程间交互的建模类似，在理解同一进程中并发线程的交互方面所做的工作很少。目前，angr还没有办法对这一点进行推理，从理论的角度也不清楚如何去处理这一点。
这个问题的一个子集是信号处理程序(或硬件中断)的分析。每个信号处理程序都可以建模为一个线程，该线程可以在任何触发信号的时候执行。理解何时分析这些处理程序是有意义的是一个有待解决的问题。一个能够对中断的影响进行推理的系统是FIE。
路径爆炸
许多方法(如verittesting)试图缓解符号执行中的路径爆炸问题。然而，尽管有这些努力，路径爆炸仍然是阻碍象征性执行成为主流的主要问题。
angr为实现控制路径爆炸的新技术提供了良好的基础。大多数方法都可以通过探索技术轻松实现并快速评估(例如：在CGC数据集上)
