你好！欢迎来到 applepie！这是一个专为模糊测试、内省和寻找漏洞而设计的工具！这是一个使用 Windows Hypervisor Platform API（该 API 存在于较新版本的 Windows 中，具体而言，本项目在 Windows 10 17763 上开发和测试）的虚拟机监控器。Bochs 用于提供深度内省和设备模拟。
Windows Hypervisor Platform API (WHVP) 是一组用于访问 Hyper-V 的虚拟机监控器功能的 API。这个 API 使我们能够轻松地在用户空间中实现一个虚拟机，无需任何特殊驱动或权限。
这是一个快速发展中的项目。在新功能发布但尚未记录时，我可能会发推文。
我喜欢为我的项目准备实物：
这是一个用于安全研究中进行模糊测试和内省的工具。通过使用虚拟机监控器，常见的模糊测试技术可以应用于任何目标，无论是内核还是用户态。这个环境允许对整个系统进行模糊测试，无需目标源代码。在虚拟机监控器层面可以收集代码覆盖率，如果需要，还可以使用 Bochs 模拟来在模拟环境中提供任意内省。这些覆盖率信息可用于判断模糊测试用例的有效性。如果一个模糊测试用例导致覆盖率增加，则可以将其保存下来，因为它是一个有趣的用例。这个输入可以在以后使用，并在此基础上进行新的变异。
快照模糊测试是此工具的主要用途。你可以对某个状态的系统进行快照并保存。这个快照随后可以加载用于模糊测试，注入一个模糊测试用例，然后恢复执行。由于虚拟机可以非常廉价地重置，因此可以频繁重置。如果 Word 启动需要 5 秒，但你可以正好在它读取文件时进行快照，那么你可以将模糊测试用例缩减到仅与输入相关的部分。这使得无需源代码即可实现非常紧凑的模糊测试循环。由于这些虚拟机是完全独立的系统，许多虚拟机可以并行运行，从而扩展到所有核心。
目前，此工具仅支持收集代码覆盖率、Windows 的动态符号下载以及 Windows 目标的符号/模块解析。添加模糊测试支持很快会完成。
鉴于我之前已经编写过这里的大部分功能（覆盖、模糊测试、快速重置等），我预计这个项目应该很快就能准备好进行模糊测试，除非我分心 :D
我计划在一月底之前完成覆盖率（已完成！）、反馈、模块列表（已完成！）、进程列表、快速重置和符号支持（已完成！）。这将使其成为一个非常强大的模糊测试工具。
主要支持的目标是现代的 Windows 10。Windows 目标支持从符号存储下载符号。这使得开箱即用即可获得 Windows 目标的符号化覆盖率。但是，代码的编写方式使得可以轻松添加 Linux 支持。
没有任何支持的情况下，任何能启动的操作系统仍然可以进行模糊测试并收集基本覆盖率。
在报告操作系统支持问题之前，请验证问题是否出在虚拟机监控器/对 Bochs 的修改上，方法是尝试使用标准的预构建 Bochs（不带虚拟机监控器）启动你的目标。Bochs 并不常用，经常会出现破坏性 bug，即使是启动 Linux 这样的常见操作也是如此。特别是随着 Spectre/Meltdown 缓解措施导致操作系统内部 CPUID/MSR 使用发生快速变化。
请查看 Github 上的问题页面以获取问题列表。我已经预先添加了一些问题。其中一些问题需要在开始模糊测试开发之前尽快解决。
构建需要以下内容：
安装 Visual Studio 2017 并确保其已更新。我们使用了一些前沿的 API、头文件和库。
我使用的 cl.exe 版本为：Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27025.1 for x64
SDK 版本为 10.0.17763.0
通过 https://rustup.rs/ 安装 Rust。我使用的版本是 rustc 1.32.0-nightly (b3af09205 2018-12-04)
请确保安装了 x86_64-pc-windows-msvc 工具链，因为本项目仅支持 64 位。
确保 cargo 在你的路径中。这应该是默认情况。
去 https://www.python.org/ 获取 Python，并确保它位于你的 PATH 中，以便可以调用 python。
安装 64 位 Cygwin（https://www.cygwin.com/setup-x86_64.exe），具体安装到 C:\cygwin64。安装 Cygwin 时，请确保安装 autoconf 和 make 包。
进入“打开或关闭 Windows 功能”，勾选“Hyper-V”和“Windows Hypervisor Platform”复选框。当然，这需要你的计算机支持 Hyper-V。
本安装过程指南已在以下环境中验证：
Windows 10 Build 17763 全新安装
rustc 1.33.0-nightly (8e2063d02 2019-01-07)
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27025.1 for x64
Visual Studio Community 2017 版本 15.9.4
applepie 提交 `f84c084feb487e2e7f31f9052a4ab0addd2c4cf9`
Python 3.7.2 x64
git version 2.20.1.windows.1
autoconf 包）make 包）git clone https://github.com/gamozolabs/applepie 检出 applepiepython build.py
这个初始构建过程大约需要 2 分钟，在现代机器上大概需要 20-30 秒。
只需从本项目的根目录运行 python build.py。它应该会检查环境是否正常，并且一切“都能正常工作”。
运行 python build.py clean 可清理 Bochs 和 Rust 二进制文件。
运行 python build.py deepclean 可完全删除所有 Bochs 和 Rust 二进制文件，还会删除 Bochs 的所有配置。如果你以某种方式重新配置了 Bochs，请使用此选项。
阅读 Bochs 配置文档来了解如何设置环境。我们有一些要求，例如 sync=none、ips=1000000，并且目前仅支持单处理器。这些要求会在代码内部强制实施，以确保你不会搬起石头砸自己的脚。
使用附带的 bochservisor_test\bochsrc.bxrc 和 bochservisor_test_real\bochsrc.bxrc 配置文件作为示例。bochservisor_test_real 可能是你应该参考的最新配置。
Windows 目标具有模块列表支持，这使我们能够看到我们正在运行的上下文中所有模块的列表。这样我们就可以将指令地址转换为模块 + 偏移量。这种模块 + 偏移量有助于在 ASLR 状态发生变化的模糊测试用例之间保持覆盖率信息。它还允许在像 IDA 这样的工具中对模块进行着色，以直观地看到哪些代码已被命中。
对于 Windows 目标，符号将使用你的 _NT_SYMBOL_PATH 和 symchk 从符号存储动态下载。如果路径中没有 symchk，则会静默失败。有了符号，就可以保存便于阅读的覆盖率版本以供查看。此外，使用私有符号，覆盖率可以转换为源文件:行号，从而可以对源代码进行着色。
好吧，实际上并没有测试，但是有一个 bochservisor_test，它是一个微小的操作系统，只验证所有内容都能在虚拟机监控器下启动。
然后还有 bochservisor_test_real，它是我用于 Windows/Linux 等场景的配置。这个配置可能会最频繁地更新。
这个代码库向 Bochs 引入了一小部分代码，以允许模块化地访问 CPU 上下文、客户机物理地址到其后备内存的转换，以及步进设备和 CPU 状态。
你想要查看的主要代码在 bochservisor Rust 项目中的 lib.rs 文件中。
在 Bochs 的主 CPU 循环中，我们改为使用 LoadLibrary() 加载 bochservisor DLL。这个 DLL 导出一个例程，即将被调用的 Rust CPU 循环。
Bochs 会向这个 bochs_cpu_loop 例程传递一个结构体，其中包含函数指针，用于从 Bochs 获取信息以及步进其中的设备和 CPU 状态。
当发生 MMIO 或 I/O 时，虚拟机监控器将因内存故障或 I/O 指令故障而退出。虽然 WHVP 确实提供了一个模拟 API，但它非常欠缺且不足。
相反，我们使用已经存在的 Bochs 并步进几条指令。通过保持虚拟机监控器 CPU 状态与 Bochs 同步，我们可以随时（或者至少应该能够）在虚拟机监控器和模拟之间动态切换。
这意味着完整的虚拟机监控器状态始终与 Bochs 同步，因此像 Bochs 快照这样的事情应该可以正常工作，并且可以在没有虚拟机监控器的情况下启动（可能除了一些需要存储在快照信息中的 CPUID 状态）。
当发生 MMIO 或 I/O 时，我们在模拟中运行一定数量的指令，而不仅仅是模拟一条指令。由于进入和退出虚拟机监控器的 API 开销，以及类似的 MMIO 操作很可能发生在相邻位置，我们步进几条指令。这使我们能够减少 API 的开销并降低 VMEXIT 频率。这是一个可调的数字，但代码库中的当前值很可能是有原因的。
我们以一种非常有趣的方式处理中断。我们不是安排中断传递给虚拟机监控器，而是所有中断都在 Bochs 模拟中处理。当然，完全在虚拟机监控器内部发生的异常（如异常）不由 Bochs 处理。
这也给了我们 WHVP 不支持的特性，比如 SMIs（用于 SMM）。Bochs 的 BIOS 默认使用 SMM，如果没有 SMI 支持，则需要构建自定义 BIOS。我在第一次迭代中做过这个... 不建议这样做。
本项目是为模糊测试而设计的，但它非常新（只有几天），目前还没有这些功能。
即将推出的一些功能包括：
我们可能让 Bochs 设备相关的东西在一个线程中以实时方式循环运行，而另一个线程运行虚拟机监控器。异步事件将通过 IPC 进行通信，并允许在客户机执行时更新设备。
目前，所有事情都在一个线程中进行，这意味着虚拟机监控器必须定期退出，以确保我们可以步进设备。这就像我们自己编写了一个调度器。
这可能会快一些，但也增加了复杂性，并引入了竞态条件的可能性。很难说这是否会发生。
我不确定我将使用哪种方法来收集代码覆盖率，但至少会有几个选项。从精确到快速等等。所有这些覆盖机制都将是系统级的，并且不需要目标的源代码或符号。
解析操作系统结构以获取原始信息，例如进程列表、模块列表等。然后将这些信息用于查询 PDB 以获取符号信息。
以某种有意义的方式报告崩溃。理想情况下，小型转储（minidump）会很方便，因为它们可以加载到 WinDbg 中进行处理。这可能相当容易，因为 DMP 文件只是物理内存和处理器上下文，而这些我们已经有了。
我有一些有趣的根因分析技术，这些技术在历史上很成功。我计划将它们引入到这里。
通过跟踪脏页并仅恢复已修改的内容，我们应该能够非常快速地重置虚拟机。这使我们能够在系统目标的所有核心上以最大速度进行模糊测试。这类似于我在 falkervisor 中所做的，所以已经经过思考设计。只需移植到这里即可。
极其快速的模糊测试，当发生 MMIO 或 I/O 时取消执行。这允许所有 CPU 时间都花在虚拟机监控器中，而没有模拟时间。缺点是在模糊测试用例期间不支持磁盘 I/O 之类的操作，但这很酷。
本项目的核心理念之一是对 Bochs 进行最小化修改。这使我们能够保持本仓库中 Bochs 部分的更新。
目标也是尽可能多地将代码移到 Rust 和 DLL 中，使系统更加模块化和安全。这将有望减少在虚拟机监控器本身中制造愚蠢的损坏错误的机会，从而避免产生无效的模糊测试结果。
目前，虚拟机监控器是一个 DLL，无需修改 Bochs 即可更换（除非 FFI API 发生变化）。
此外，对 Bochs 本身的进一步修改必须清晰记录，我将很快为此编写一份文档，以跟踪必须随着 Bochs 更新而移植和重新评估的更改。