你的问题在这里有很好的答案。然而，我想给你我的意见。总的来说，根本原因分析最好半手动完成。原因之一是像动态污点分析这样的技术，使用 SMT 求解器等......是解决小问题或特定问题的好工具，但对于普通研究人员来说几乎无法用于整个项目 + 真实目标，因为需要时间和功率. 此外，值得考虑使用此类技术开发工具所需的时间，这些技术可能适用于真实目标，例如 Acrobat Reader。

为了让您的任务不那么烦人，我可以向您推荐的第一件事是编写最小化工具。根据您创建变异样本的方式，您甚至可以使用我自己为Nightmare编写的一些工具，例如这种通用的崩溃最小化工具，适用于某些二进制文件和纯文本文件（它可能适用于 Acrobat Reader有一些修改）。最小化 PDF 后，您可能还需要执行以下操作：

1. 使用MyNav、BinNavi或类似的工具可以进行差异化调试。
2. 使用空白 PDF 记录第一次执行。确保尽可能多地记录 GUI 事件。
3. 如果您从模板 PDF 文件创建了变异文件，则还要记录该原始 PDF 文件的执行。它将删除用于该特定模板的所有功能和基本块。
4. 在前面的步骤之后，您记录了空白 PDF 文件的痕迹、GUI 事件等……记录崩溃的 PDF 示例的执行情况。当您使用差分调试时，只有最后一个基本块和/或函数会出现在最后一个跟踪中。

希望您只需要分析几个基本块或函数，并且您可能能够看到哪些条件跳转被执行或未执行，并确定它为什么会崩溃。

顺便说一句，如果您使用的是 Unix，您还可以使用原始模板和崩溃样本来比较 valgrind 执行的日志。

我的 2 美分...

首先，您应该编写脚本来降低变异（模糊）文件和原始文件之间的差异，以便了解导致程序崩溃的主要字节/字节。这将是一个字节一个字节的比较、更改、检查，以确保您的应用程序崩溃所需的差异最小。（您可能会以这种方式发现新的崩溃。相信我！）

第二部分是将您的代码与调试器混合在一起，调试器可以检查降低的文件是否仍然可以崩溃。

如果你为这项工作选择 Python，它可以在几个小时内完成。

PS 检查 WinAppDbg、PyDbg、PyDbgEng 等。

你能做的最好的事情就是学习如何阅读汇编。从崩溃开始，查看正在使用的内存类型、寄存器中的值以及之前的指令。学习如何使用windbg。污点分析和 smt 解决适用于纯二进制数据，它对解释器或抽象状态机来说很糟糕。换句话说，当数据和代码之间的关系是 1 对 1 时，就像在媒体播放器等中一样。如果你想成为一名漏洞研究人员，那么学习如何有效地进行逆向工程是你可以做出的最好的长期投资。它将缩短崩溃和根本原因分析之间的时间，并将提高您发现的错误的质量。

原始文件和模糊文件之间的大小差异很大，很可能不是由愚蠢的二进制字节翻转产生的。此外，PDF 格式包含大量非二进制数据。您必须研究 Reader 的工作原理，并且还要非常熟悉 PDF 规范。这是手动操作。

在https://www.corelan.be/index.php/category/security/exploit-writing-tutorials/查看教程

编辑 - 使用 PIN 可以轻松实现代码覆盖率和许多其他内容，包括使用 XED2 进行污点跟踪。查看 Dytan 和 Privacy Scope，它们都是开源的。如果应用程序很复杂，那么您很可能必须为其定制工具。您不想针对解压缩运行您的代码。还有静态污点跟踪，一个很好的例子是http://phrack.org/issues/67/10.html，它从崩溃中倒退。规则很简单，所以制作这种工具很容易并不复杂。与系统 API 和第三方库接口时会遇到困难，这是自定义的来源。您也可以使用更高级的功能，查看影子内存和我最喜欢的论文之一http://dynamorio.org/pubs/zhao-million-watchpoints-CC08.pdf