Twitter user Antonio Morales created the Fuzzing101 repository in August of 2021. In the repo, he has created exercises and solutions meant to teach the basics of fuzzing to anyone who wants to learn how to find vulnerabilities in real software projects. The repo focuses on AFL++ usage, but this series of posts aims to solve the exercises using LibAFL instead. We’ll be exploring the library and writing fuzzers in Rust in order to solve the challenges in a way that closely aligns with the suggested AFL++ usage.

推特用户 Antonio Morales 在2021年8月创建了 fuzzing101资源库。在回购协议中，他创建了练习和解决方案，旨在向任何想要学习如何在实际软件项目中发现漏洞的人传授模糊化的基本知识。回复主要关注 AFL + + 的使用，但本系列文章旨在用 LibAFL 来解决练习。我们将探索图书馆，并在 Rust 中编写模糊符号，以便以一种与建议的 AFL + + 使用密切结合的方式解决这些挑战。

Since this series will be looking at Rust source code and building fuzzers, I’m going to assume a certain level of knowledge in both fields for the sake of brevity. If you need a brief introduction/refresher to/on coverage-guided fuzzing, please take a look here. As always, if you have any questions, please don’t hesitate to reach out.

由于本系列将讨论 Rust 源代码和构建模糊，为了简洁起见，我将假定这两个领域都有一定的知识水平。如果您需要一个简短的介绍/复习/关于覆盖引导模糊，请看看这里。一如既往，如果您有任何问题，请不要犹豫，联系我们。

This post will cover fuzzing Xpdf in order to solve Exercise 1. The companion code for this exercise can be found at my fuzzing-101-solutions repository

为了解决练习1，这篇文章将覆盖 fuzzing Xpdf。这个练习的伴随代码可以在我的 fuzzing-101-solutions 存储库中找到

Quick Reference

快速参考

This is just a summary of the different components used in the upcoming post. It’s meant to be used later as a easy way of determining which components are used in which posts.

这只是在即将发布的文章中使用的不同组件的总结。这意味着以后可以用它作为一种简单的方法来确定哪些组件用于哪些帖子。

{
  "Fuzzer": {
    "type": "StdFuzzer",
    "Corpora": {
      "Input": "InMemoryCorpus",
      "Output": "OnDiskCorpus"
    },
    "Input": "BytesInput",
    "Observers": [
      "TimeObserver",
      "HitcountsMapObserver"
    ],
    "Feedbacks": {
      "Pure": ["MaxMapFeedback", "TimeFeedback"],
      "Objectives": ["MapFeedbackState", "TimeoutFeedback"]
    },
    "State": "StdState",
    "Stats": "SimpleStats",
    "EventManager": "SimpleEventManager",
    "Scheduler": "IndexesLenTimeMinimizerCorpusScheduler",
    "Executor": "TimeoutForkserverExecutor",
    "Mutators": ["havoc_mutations"],
    "Stages": ["StdMutationalStage"]
  }
}

LibAFL Background

图片来源: LIBAFL

LibAFL, the Advanced Fuzzing Library, is a collection of reusable fuzzer components written in Rust. It is fast, multi-platform, no_std compatible, and scales well over cores and machines. LibAFL is written and maintained by Andrea Fioraldi and Dominik Maier (they also maintain AFL++). You can learn more about the motivation behind LibAFL and the different components in their rC3 talk.

高级 Fuzzing 库 LibAFL 是用 Rust 编写的可重用模糊器组件的集合。它具有快速、多平台、无标准兼容性、可扩展性好于核心和计算机的特点。LibAFL 由 Andrea Fioraldi 和 Dominik Maier 编写和维护(他们也维护 AFL + +)。你可以在他们的 rc3演讲中了解更多关于 LibAFL 背后的动机和不同组件的信息。

Without further ado, let’s get started.

闲话少说，我们开始吧。

Exercise 1 Setup

练习1设置

Our first step is walking through the setup steps for Rust, Xpdf, and AFL++. If you’re wondering why we’ll need AFL++ when we plan to use LibAFL, it’s because we’ll use AFL++’s compiler for instrumentation once or twice before we try out some different instrumentation backends.

我们的第一步是完成 Rust、 Xpdf 和 AFL + + 的设置步骤。如果你想知道当我们计划使用 LibAFL 时为什么需要 AFL + + ，那是因为在我们尝试一些不同的插装后端之前，我们将使用 AFL + + 的编译器进行插装一次或两次。

As far as setup, my assumption is that you’re on some flavor of linux. Any linux package manager commands will be given as debian-flavor commands (apt).

至于安装，我的假设是你使用的是某种风格的 linux。任何 linux 包管理器命令都将作为 debian 风格的命令(apt)给出。

Install Rust

安装防锈

This one’s easy.

这个很简单。

Further information is here in case you need it.

如果你需要更多的信息，这里有。

Install AFL++

安装 AFL + +

I’m taking these steps directly from Exercise 1’s setup instructions.

我直接从练习1的设置说明中采取这些步骤。

Install dependencies

安装依赖项

sudo apt-get update
sudo apt-get install -y build-essential python3-dev automake git flex bison libglib2.0-dev libpixman-1-dev python3-setuptools
sudo apt-get install -y lld-11 llvm-11 llvm-11-dev clang-11 || sudo apt-get install -y lld llvm llvm-dev clang 
sudo apt-get install -y gcc-$(gcc --version|head -n1|sed 's/.* //'|sed 's/\..*//')-plugin-dev libstdc++-$(gcc --version|head -n1|sed 's/.* //'|sed 's/\..*//')-dev

Checkout and build AFL++

检查和构建 AFL + +

Test your installation

测试你的安装

afl-fuzz -h
════════════════════════════

afl-fuzz++3.15a based on afl by Michal Zalewski and a large online community

afl-fuzz [ options ] -- /path/to/fuzzed_app [ ... ]

Required parameters:
  -i dir        - input directory with test cases
  -o dir        - output directory for fuzzer findings

Execution control settings:
  -p schedule   - power schedules compute a seed's performance score:
                  fast(default), explore, exploit, seek, rare, mmopt, coe, lin
                  quad -- see docs/power_schedules.md
  -f file       - location read by the fuzzed program (default: stdin or @@)
-------------8<-------------

Project Directory Setup

项目目录设置

In order to keep us on track for the upcoming rust code/build setup, we’re going to deviate from the directory structure recommended by the Fuzzing101 README. Since we know that we’ll be creating multiple Rust projects (one for each exercise), we’ll start out with a Rust workspace.

为了保持我们对即将到来的 rust code/build 设置的跟踪，我们将偏离 Fuzzing101 README 推荐的目录结构。因为我们知道我们将创建多个 Rust 项目(每个练习一个) ，所以我们将从一个 Rust 工作区开始。

The first step in creating a workspace for our Rust project directories is to simply make a directory.

为 Rust 项目目录创建工作空间的第一步是简单地创建一个目录。

cd $HOME
mkdir fuzzing-101-solutions
cd fuzzing-101-solutions

fuzzing-101-solutions will be the top level directory that houses all of our different exercise specific projects. In the top level directory, we need to create a Cargo.toml file that tells Rust and cargo that this is a workspace. Since all of our projects in the workspace are going to be fuzzers, we’ll globally modify the release profile settings as well.

Fuzzing-101-solutions 将是顶级目录，存放我们所有不同的特定锻炼项目。在顶级目录中，我们需要创建 Cargo.toml 文件，它告诉 Rust 和 cargo 这是一个工作区。由于我们工作空间中的所有项目都将是模糊的，因此我们也将全局地修改发布概要文件设置。

fuzzing-101-solutions/Cargo.toml

[workspace]

members = [
    "exercise-1",
]

[profile.release]
lto = true
codegen-units = 1
opt-level = 3
debug = true

• lto=true :: perform link-time optimizations across all crates within the dependency graph
• 对依赖关系图中的所有板条箱执行链接时间优化
• codegen-units=1 :: controls how many “code generation units” a crate will be split into; higher codegen-units MAY produce slower code (max value 256)
• Codegen-units = 1: : 控制一个板条箱将被分解成多少“代码生成单元”; 较高的 codegen-units 可能生成较慢的代码(最大值256)
• opt-level=3 :: controls the level of optimizations; 3 == “all optimizations”
• Opt-level = 3: : 控制优化级别; 3 = = “ all optimizations”
• debug=true :: controls the amount of debug information included in the compiled binary; true == “full debug info”
• 控制编译后的二进制文件中包含的调试信息量; true = “完整的调试信息”

After that, we can create our first solution project.

之后，我们可以创建我们的第一个解决方案项目。

Having run the commands above, we’re left with a directory structure that looks like this.

在运行了上面的命令之后，我们得到了一个如下所示的目录结构。

fuzzing-101-solutions/
├── Cargo.toml
└── exercise-1
    ├── Cargo.toml
    ├── .git
    │   ├── description
    │   -------------8<-------------
    ├── .gitignore
    └── src
        └── main.rs

Now we can proceed with the fuzz target setup.

现在我们可以继续进行模糊目标设置。

Install Xpdf

安装 XPDF

Again, these steps are pulled directly from Exercise 1’s README. We’ll modify them a bit to take our slightly different folder structure into account.

同样，这些步骤直接来自练习1的 README。我们将对它们进行一些修改，以考虑到我们略有不同的文件夹结构。

Download Xpdf 3.02

下载 XPDF 3.02

The following set of steps will download Xpdf version 3.02 into a folder ultimately named xpdf.

下面的步骤将把 Xpdf 版本3.02下载到一个名为 Xpdf 的文件夹中。

Our directory structure now looks like this

我们的目录结构现在看起来像这样

fuzzing-101-solutions/
├── Cargo.toml
├── exercise-1
│   ├── Cargo.toml
│   ├── .git
│   │   ├── config
│   │   -------------8<-------------
│   ├── .gitignore
│   └── src
│       └── main.rs
└── xpdf
    ├── aclocal.m4
    ├── aconf2.h
    -------------8<-------------

The Fuzzing101 README recommends building Xpdf with gcc at this point as a test. Feel free to do so if you like.

Fuzzing101自述文件建议此时使用 gcc 构建 Xpdf 作为测试。如果你愿意，可以随时这样做。

Fuzzer Setup

模糊设置

The Goal

目标

In order to write our fuzzer, we should take a look at our goal.

为了编写我们的模糊器，我们应该看看我们的目标。

According to Fuzzing101:

根据 Fuzzing101:

the goal is to find a crash/PoC for CVE-2019-13288 in XPDF 3.02.

目标是在 XPDF 3.02中找到 cve-2019-13288的崩溃/PoC。

CVE-2019-13288 is a vulnerability that may cause an infinite recursion via a crafted file.

Cve-2019-13288是一个漏洞，可能通过一个精心制作的文件导致无限递归。

Since each called function in a program allocates a stack frame on the stack, if a function is recursively called so many times it can lead to stack memory exhaustion and program crash.

由于程序中每个被调用的函数都会在堆栈上分配一个堆栈帧，如果一个函数被递归调用太多次，就会导致堆栈内存耗尽和程序崩溃。

As a result, a remote attacker can leverage this for a DoS attack.

因此，远程攻击者可以利用这一点进行 DoS 攻击。

Alright, we know what we want to accomplish, and all of the dependencies have been gathered, let’s go!

好了，我们知道我们想要完成什么，所有的依赖都已经收集好了，我们走吧！

Cargo.toml

Our first stop will be the Cargo.toml file in the exercise-1 directory. We’ll begin by telling cargo that we plan to use a build script, as well as adding LibAFL as a dependency.

我们的第一站是 exercise-1目录中的 Cargo.toml 文件。首先，我们将告诉 cargo 我们计划使用构建脚本，并将 LibAFL 作为一个依赖项添加。

exercise-1/Cargo.toml

运动-1/Cargo.toml

[package]
name = "exercise-one-solution"
version = "0.1.0"
edition = "2021"
build = "build.rs"

[dependencies]
libafl = "0.6.1"

build.rs

北京建筑科技有限公司

Next up, we’ll add a build.rs file to our exercise-1 directory, resulting in a directory structure like what’s shown below.

接下来，我们将在 exercise-1目录中添加一个 build.rs 文件，生成如下所示的目录结构。

fuzzing-101-solutions/
├── Cargo.toml
├── exercise-1
│   ├── Cargo.toml
│   ├── build.rs
-------------8<-------------

Build scripts are useful when one needs to perform some set of actions at build time. Typical uses are building/linking to external C libraries or doing some sort of code generation before building a project. By placing a file named build.rs in the root of our project directory, we’re telling cargo to compile and execute build.rs just before building our project.

当需要在构建时执行一组操作时，构建脚本是非常有用的。典型的用途是构建/链接到外部的 c 库，或者在构建项目之前进行某种代码生成。通过在项目目录的根目录中放置一个名为 build.rs 的文件，我们告诉 cargo 在构建项目之前编译并执行 build.rs。

The build.rs file is where we’ll configure and build Xpdf using AFL++’s compiler. More specifically, we’ll use alf-clang-fast, since that’s what Fuzzing101 recommends for this exercise.

在 build.rs 文件中，我们将使用 AFL + + 的编译器配置和构建 Xpdf。更具体地说，我们将使用 alf-clang-fast，因为这就是 fuzzing101对这个练习的建议。

build.rs is essentially a program unto itself, so we’ll begin with its imports and its main function.

Rs 本质上是一个程序本身，所以我们从它的导入和主要功能开始。

use std::env;
use std::process::Command;

fn main() {
    // todo 
}

Within the main function, we can configure when the build script should be run (after the initial build). We’ll do that the the rerun-if-changed directive. These directives tell cargo to re-run the build script if any of the files at the given paths have changed. More specifically, if their mtime timestamp has updated or not.

在 main 函数中，我们可以配置何时应该运行构建脚本(在初始构建之后)。我们将执行重新运行 if-changed 指令。这些指令告诉 cargo，如果给定路径上的任何文件发生更改，则重新运行构建脚本。更具体地说，如果它们的 mtime 戳更新了或没有更新。

println!("cargo:rerun-if-changed=build.rs");
println!("cargo:rerun-if-changed=src/main.rs");

After that, we’re going to programatically execute the same commands that we would have run if we were to manually build Xpdf from the command line. Those commands are listed below to give you an idea of what build.rs is trying to accomplish.

在此之后，我们将通过编程方式执行相同的命令，如果我们从命令行手动构建 Xpdf，我们将会运行相同的命令。下面列出了这些命令，可以让您了解 build.rs 试图完成的目标。

# these are example commands that will be executed automatically by build.rs
# and were taken almost verbatim from Fuzzing101's README
cd fuzzing-101-solutions/exercise-1/xpdf
make clean
rm -rf install 
export LLVM_CONFIG=llvm-config-11 
CC=afl-clang-fast ./configure --prefix=./install
make
make install

Here’s what the first of the commands above looks like when written as a Command in Rust.

下面是上面的第一个命令在 Rust 中作为 Command 编写时的样子。

let cwd = env::current_dir().unwrap().to_string_lossy().to_string();
let xpdf_dir = format!("{}/xpdf", cwd);

// make clean; remove any leftover gunk from prior builds
Command::new("make")
    .arg("clean")
    .current_dir(xpdf_dir.clone())
    .status()
    .expect("Couldn't clean xpdf directory");

The rest of the commands follow the same kind of pattern. The entirety of build.rs is shown below.

其余的命令遵循同样的模式。

exercise-1/build.rs

练习-建造

use std::env;
use std::process::Command;

fn main() {
    println!("cargo:rerun-if-changed=build.rs");
    println!("cargo:rerun-if-changed=src/main.rs");

    let cwd = env::current_dir().unwrap().to_string_lossy().to_string();
    let xpdf_dir = format!("{}/xpdf", cwd);

    // make clean; remove any leftover gunk from prior builds
    Command::new("make")
        .arg("clean")
        .current_dir(xpdf_dir.clone())
        .status()
        .expect("Couldn't clean xpdf directory");

    // clean doesn't know about the install directory we use to build, remove it as well
    Command::new("rm")
        .arg("-r")
        .arg("-v")
        .arg("-f")
        .arg(&format!("{}/install", xpdf_dir))
        .current_dir(xpdf_dir.clone())
        .status()
        .expect("Couldn't clean xpdf's install directory");

    // export LLVM_CONFIG=llvm-config-11
    env::set_var("LLVM_CONFIG", "llvm-config-11");

    // configure with afl-clang-fast and set install directory to ./xpdf/install
    Command::new("./configure")
        .arg(&format!("--prefix={}/install", xpdf_dir))
        .env("CC", "/usr/local/bin/afl-clang-fast")
        .current_dir(xpdf_dir.clone())
        .status()
        .expect("Couldn't configure xpdf to build using afl-clang-fast");

    // make && make install
    Command::new("make")
        .current_dir(xpdf_dir.clone())
        .status()
        .expect("Couldn't make xpdf");

    Command::new("make")
        .arg("install")
        .current_dir(xpdf_dir)
        .status()
        .expect("Couldn't install xpdf");
}

If everything is configured correctly up to this point, we should be able to run

如果到目前为止一切都配置正确，我们应该能够运行

After which, the xpdf/install directory should look like this.

在此之后，xpdf/install 目录应该如下所示。

xpdf/install
├── bin
│   ├── pdffonts
│   ├── pdfimages
│   ├── pdfinfo
│   ├── pdftops
│   └── pdftotext
├── etc
│   └── xpdfrc
└── man
    ├── man1
    │   ├── pdffonts.1
    │   ├── pdfimages.1
    │   ├── pdfinfo.1
    │   ├── pdftops.1
    │   └── pdftotext.1
    └── man5
        └── xpdfrc.5

The binaries in the xpdf/install/bin folder were all compiled with afl-clang-fast, and as such, are instrumented for fuzzing!

Xpdf/install/bin 文件夹中的二进制文件都是使用 afl-clang-fast 编译的，因此可以检测 fuzzing！

corpus

语料库

I promise, we’re getting to the fuzzer soon, but before we do, we need a few sample PDF files to populate our input corpus. It’s just a few wget commands, so nothing too onerous.

我保证，我们很快就会得到的模糊，但在我们这样做，我们需要一些样本 PDF 文件填充我们的输入语料库。它只是一些 wget 命令，所以没有什么太麻烦的。

That’s it! These three PDF files will make up the initial input for our fuzzer.

就是它! 这三个 PDF 文件将构成我们的模糊器的初始输入。

Writing the Fuzzer

编写模糊语言

Ok, now we’re closing in on the good stuff. main.rs will house our fuzzer’s logic. Ultimately, the fuzzer is going to be put together piece-by-piece using different components from LibAFL. The majority of this code was derived from the forkserver_simple example in the LibAFL repo. We’re using a forkserver along with afl-clang-fast to keep somewhat in-line with what one would expect to see when following along with Fuzzing101’s recommendation.

好了，现在我们接近好东西了。主要的是我们的模糊逻辑。最终，我们将使用 LibAFL 中的不同组件逐件地将模糊器组合在一起。此代码的大部分来自 LibAFL repo 中的 forkserver _ simple 示例。我们使用叉式服务器和 afl-clang-fast 来保持与 fuzzing101的建议一致。

As we go through main.rs, we’ll attempt to dig in to why certain components were chosen and how they map to different fuzzing concepts.

在我们浏览 main.rs 时，我们将尝试深入研究为什么选择某些组件以及它们如何映射到不同的 fuzzing 概念。

Ok, I think that’s enough preamble, let’s get started.

好了，我想已经说得够多了，我们开始吧。

Components: Corpus + Input

References:

参考文献:

• Corpus Book Entry 语料库书目
• Corpus API Entry 语料库 API 条目
• Input Book Entry 输入书目
• Input API Entry 输入 API 条目

We’ll start building our fuzzer by creating our corpora (yes, I had to google the plural of corpus, don’t judge me). First up is the input corpus. The input corpus holds all of our current testcases. We’re using an InMemoryCorpus to prevent reads/writes to disk. Keeping our corpus in memory and preventing disk access should improve the speed at which we manipulate testcases.

我们将通过创建语料库来开始构建模糊语言(是的，我必须用谷歌搜索语料库的复数形式，不要评判我)。首先是输入语料库。输入语料库保存了我们当前的所有测试用例。我们使用 InMemoryCorpus 来防止对磁盘的读写。保持内存中的语料库并防止磁盘访问应该可以提高操作测试用例的速度。

While creating the input corpus, we need to define the Input type. The Input represents data received from some external source. In this case, we’re using the BytesInput, which means that our input corpus should contain items that can be represented as arrays of bytes. Those byte arrays will eventually be mutated by the fuzzer before being passed to the program being fuzzed.

在创建输入语料库时，我们需要定义输入类型。Input 表示从某个外部源接收的数据。在这种情况下，我们使用 BytesInput，这意味着我们的输入语料库应该包含可以表示为字节数组的项。这些字节数组在传递给模糊化的程序之前，最终会被模糊器变异。

let corpus_dirs = vec![PathBuf::from("./corpus")];

let input_corpus = InMemoryCorpus::<BytesInput>::new();

After that, we’ll move on to the output corpus. Testcases from the input corpus that cause a timeout are considered “solutions”. Our output corpus, which is of the type OnDiskCorpus, is the corpus in which we store those solutions. Said another way: any generated PDF that causes the program to hang will be stored in the output corpus.

之后，我们将继续讨论输出语料库。输入语料库中导致超时的测试用例被认为是“解决方案”。我们的输出语料库属于 OnDiskCorpus 类型，是我们存储这些解决方案的语料库。换句话说: 任何生成的 PDF，导致程序挂起将被存储在输出语料库中。

let timeouts_corpus = OnDiskCorpus::new(PathBuf::from("./timeouts")).expect("Could not create timeouts corpus");

Component: Observer

References:

参考文献:

• Observer Book Entry 观察者登记簿
• Observer API Entry 观察者 API 条目

The next component for our fuzzer is the Observer. An Observer can be thought of as something that provides information about the current testcase to the fuzzer. We’ll start with a simple Observer: the TimeObserver. The TimeObserver simply keeps track of the current testcase’s runtime. For each testcase, the TimeObserver will send the time it took the testcase to execute to the fuzzer by way of a Feedback component, which we’ll discuss shortly.

我们的模糊器的下一个组件是观察者。观察者可以被认为是向模糊器提供关于当前测试用例的信息。我们从一个简单的观察者开始: 时间观察者。TimeObserver 只是简单地跟踪当前测试用例的运行时。对于每个测试用例，TimeObserver 将通过一个 Feedback 组件将测试用例执行的时间发送给 fuzzer，我们将很快讨论这个组件。

let time_observer = TimeObserver::new("time");

While the TimeObserver was simple, the next Observer is less so. In addition to execution time, we also want to keep track of the coverage map (this is a coverage-guided fuzzer after all). In order to build a coverage map, we need some shared memory. This piece of shared memory, AKA the coverage map, will be shared between the HitcountsMapObserver and the Executor (we’ll discuss the Executor a little later in the post).

虽然时间观察者很简单，但下一个观察者就不那么简单了。除了执行时间，我们还需要跟踪覆盖率映射(这毕竟是一个覆盖率引导的模糊器)。为了构建覆盖范围图，我们需要一些共享内存。这部分共享内存，又称覆盖率映射，将在 HitcountsMapObserver 和 Executor 之间共享(稍后我们将讨论 Executor)。

First, we create a new instace of a StdShMemProvider, which provides access to shared memory mappings. We then use the StdShMemProvider to create a new shared memory mapping that is 65536 bytes.

首先，我们创建一个新的 stdout shmemprovider，它提供对共享内存映射的访问。然后，我们使用 stdout/shmemprovider 创建一个新的共享内存映射，其大小为65536字节。

const MAP_SIZE: usize = 65536;
-------------8<-------------
let mut shmem = StdShMemProvider::new().unwrap().new_map(MAP_SIZE).unwrap();

After that, we need to save the shared memory id to the environment, so that the Executor knows about it.

之后，我们需要将共享内存 id 保存到环境中，以便 Executor 知道它。

shmem.write_to_env("__AFL_SHM_ID").expect("couldn't write shared memory ID");

Next, we get a mutable reference to the memory map. The reference we create is of type &mut [u8].

接下来，我们得到一个对内存映射的可变引用。

let mut shmem_map = shmem.map_mut();

Finally, we create our Observer, passing in the reference to the shared memory map and giving it the name shared_mem.

最后，我们创建观察者，传递对共享内存映射的引用，并给它命名为 shared _ mem。

A HitcountsMapObserver needs a base object passed in as part of its constructor. The base we’re using is a ConstMapObserver. A ConstMapObserver is an optimization layer over a MapObserver. It allows for some performance gains by using a map size that’s known at compile time when deciding if a testcase is “interesting” (more on this in the Feedback section).

HitcountsMapObserver 需要一个基本对象作为其构造函数的一部分传入。我们使用的基础是一个 constanmapobserver。Constanmapobserver 是 MapObserver 上的优化层。在判断一个测试用例是否“有趣”时，它使用在编译时已知的映射大小来提高性能(在 Feedback 部分有更多关于这一点的内容)。

let edges_observer = HitcountsMapObserver::new(ConstMapObserver::<_, MAP_SIZE>::new(
    "shared_mem",
    &mut shmem_map,
));

Phew! We’re done with Observers for now, let’s see what’s next.

我们现在不需要观察员了，看看接下来会发生什么。

Component: Feedback

References:

参考文献:

• Feedback Book Entry 反馈簿记录
• Feedback API Entry 反馈 API 条目
• FeedbackState API Entry 反馈状态 API 条目

After the Observers comes our Feedback. The purpose of a Feedback component is to classify whether or not the outcome of a testcase is interesting. When a Feedback determines that a testcase is interesting, the input that was used in that testcase is typically added to the Corpus. Feedback components may have a FeedbackState component tied to them as well. FeedbackState components represent the state of the data that the Feedback wants to persist in the Fuzzer’s State (both of which are coming up later).

观察者之后是我们的反馈。Feedback 组件的目的是对测试用例的结果是否有趣进行分类。当一个 Feedback 确定一个测试用例是有趣的时候，在这个测试用例中使用的输入通常会被添加到语料库中。反馈组件也可能有一个反馈状态组件绑定到它们。FeedbackState 组件表示反馈希望保持在 Fuzzer 状态的数据的状态(这两个都将在稍后出现)。

For our fuzzer, we need to create a few different Feedback components. We’ll start with the Feedbacks that will keep track of our coverage map and execution time.

对于我们的模糊器，我们需要创建一些不同的反馈组件。我们将从跟踪覆盖范围图和执行时间的反馈开始。

The MapFeedbackState tracks the cumulative state of the coverage map while getting updates from its associated Observer.

MapFeedbackState 在从其关联的 Observer 获取更新的同时跟踪覆盖率映射的累积状态。

let feedback_state = MapFeedbackState::with_observer(&edges_observer);

The MapFeedbackState and its HitcountsMapObserver (discussed earlier) are passed into a MaxMapFeedback. The MaxMapFeedback determines if there is a value in the HitcountsMapObserver’s coverage map that is greater than the current maximum value for the same entry. If a new maximum is found, the Input is deemed interesting.

MapFeedbackState 及其 HitcountsMapObserver (前面讨论过)被传递到 MaxMapFeedback 中。MaxMapFeedback 确定 HitcountsMapObserver 的覆盖率映射中是否有一个大于同一条目的当前最大值的值。如果找到一个新的最大值，则认为 Input 是有趣的。

After creating the MaxMapFeedback, we also create a new TimeFeedback, which is then tied to the TimeObserver we saw earlier. You may be wondering how the TimeFeedback component helps to decide if an Input is interesting… Well, it doesn’t. TimeFeedback never reports an Input as interesting. However, it does keep track of testcase execution time by way of its TimeObserver. Due to the fact that it can never classify a testcase as interesting on its own, we need to use it alongside some other Feedback that has the ability to perform said classification.

在创建 MaxMapFeedback 之后，我们还创建了一个新的 TimeFeedback，它绑定到我们前面看到的 TimeObserver。您可能想知道 TimeFeedback 组件如何帮助确定一个输入是否有趣… … 好吧，它并不有趣。时间反馈从来不报告有趣的输入。但是，它通过其 TimeObserver 来跟踪测试用例的执行时间。由于它本身永远不能将一个测试用例分类为有趣的，因此我们需要将它与其他一些具有执行上述分类能力的 Feedback 一起使用。

With both of the new Feedback components created, we use the feedback_or macro to compile both Feedbacks into a single CombinedFeedback, which is joined together with a logical OR.

在创建了这两个新的 Feedback 组件之后，我们使用 Feedback _ OR 宏来将两个 Feedback 编译成一个 CombinedFeedback，这个 Feedback 与一个逻辑 OR 连接在一起。

The feedback variable below is essentially saying, if the current testcase’s input triggered a new code path in the coverage map, we should probably save that input to the corpus.

下面的反馈变量实际上是说，如果当前测试用例的输入触发了覆盖率映射中的新代码路径，我们可能应该将该输入保存到语料库中。

The true passed to new_tracking says that we want to track indexes. The false says we do not want to track novelties.

传递给 new _ tracking 的 true 表示我们想要跟踪索引。错误的说法是我们不想追踪新奇事物。

let feedback = feedback_or!(
    MaxMapFeedback::new_tracking(&feedback_state, &edges_observer, true, false),
    TimeFeedback::new_with_observer(&time_observer)
);

Alright, we’ve got the Feedbacks for coverage and time, now we’re going to add a second set of Feedbacks. These upcoming Feedbacks will also be used to determine if a testcase is interesting, but can be thought of more as a testcase’s solution or objective. They’ll be passed into our Fuzzer component later on in the code.

好了，我们已经得到了报道和时间的反馈，现在我们要添加第二组反馈。这些即将到来的反馈还将用于确定一个测试用例是否有趣，但可以更多地将其视为一个测试用例的解决方案或目标。它们将在稍后的代码中被传递到我们的 Fuzzer 组件中。

Similar to the first set, we need to create a MapFeedbackState. However, instead of tying it to an Observer, this one will create its own memory map of MAP_SIZE, consisting of u8’s.

与第一组类似，我们需要创建一个 MapFeedbackState。然而，不是将它绑定到一个观察者，这一个将创建它自己的 MAP _ size 内存映射，包括 u8的。

const MAP_SIZE: usize = 65536;
// -------------8<-------------
let objective_state = MapFeedbackState::new("timeout_edges", MAP_SIZE);

Also similar to before, we combine two Feedbacks using a boolean operator, but this time it’s a logical AND. We’ll combine them using the feedback_and_fast macro. The Feedbacks in question are the TimeoutFeedback and our old friend MaxMapFeedback from earlier.

同样与前面类似，我们使用布尔运算符合并两个反馈，但这次是逻辑与。我们将使用 feedback 和 fast 宏来组合它们。我们讨论的反馈是 TimeoutFeedback 和我们的老朋友 MaxMapFeedback。

Recall that our goal is to find an infinite recursion bug. Since we’re looking for something that causes infinite recursion, we’re mostly interested in looking for testcases that make the target program hang. The objective variable below is essentially saying, if the given input triggered a new code path in the coverage map, AND, if the time to execute the fuzz case with the current input results in a timeout, our testcase meets our objective.

回想一下，我们的目标是找到一个无限递归 bug。因为我们正在寻找导致无限递归的东西，所以我们最感兴趣的是寻找使目标程序挂起的测试用例。下面的目标变量实际上是说，如果给定的输入在覆盖范围图中触发了一个新的代码路径，并且，如果用当前输入执行模糊案例的时间导致超时，那么我们的测试案例符合我们的目标。

let objective = feedback_and_fast!(
    TimeoutFeedback::new(),
    MaxMapFeedback::new(&objective_state, &edges_observer)
);

That’s it for Feedbacks, moving on to…

这就是反馈，继续..。

Component: State

References:

参考文献:

• State Book Entry 国家登记簿条目
• State API Entry 状态空气污染指数条目

Our next component is the State component, specifically the StdState. A State component takes ownership of each of our existing FeedbackState components, a random number generator, and our corpora.

我们的下一个组件是 State 组件，特别是 stdout 状态。状态组件拥有我们现有的每个 FeedbackState 组件、一个随机数生成器和我们的语料库的所有权。

let mut state = StdState::new(
    StdRand::with_seed(current_nanos()),
    input_corpus,
    timeouts_corpus,
    tuple_list!(feedback_state, objective_state),
);

Component: Stats

References:

参考文献:

• Stats Book Entry 统计资料
• Stats API Entry 统计 API 条目

The Stats component defines how the fuzzer’s stats are reported. For now, we’ll use the simplest Stats representation: SimpleStats. SimpleStats will call println with SimpleStats::display as input in order to send a report to the terminal.

Stats 组件定义如何报告 fuzzer 的状态。现在，我们将使用最简单的 Stats 表示: SimpleStats。将使用 SimpleStats: : display 调用 println 作为输入，以便向终端发送报告。

let stats = SimpleStats::new(|s| println!("{}", s));

Component: EventManager

References:

参考文献:

• EventManager Book Entry 事件管理器登记
• EventManager API Entry EventManager API 条目

The EventManager component handles the various Events generated during the fuzzing loop. Some examples of an Event are finding an interesting testcase, updating the Stats component, and logging. Once again, we’ll use the simplest type available for our current Fuzzer.

EventManager 组件处理 fuzzing 循环期间生成的各种事件。事件的一些例子包括发现一个有趣的测试用例、更新 Stats 组件和日志记录。再一次，我们将使用当前 Fuzzer 可用的最简单的类型。

let mut mgr = SimpleEventManager::new(stats);

Component: Scheduler

References:

参考文献:

• Scheduler Book Entry 计划程序预订条目
• CorpusScheduler API Entry API 条目

During the fuzz loop, our fuzzer will need to acquire new testcases from the input corpus. The Scheduler component defines the strategy used to supply a Fuzzer’s request to the Corpus for a new testcase. For our fuzzer, we’re using the IndexesLenTimeMinimizerCorpusScheduler. The name is kinda scary, but it boils down to a minimization policy backed by a queue that is used to get test cases from the corpus. It will prioritize quick/small testcases that exercise all of the entries registered in the coverage map’s metadata.

在模糊循环过程中，模糊语言学习者需要从输入语料库中获取新的测试用例。调度器组件定义了一种策略，用于向语料库提供 Fuzzer 对新测试用例的请求。对于我们的模糊器，我们使用 indexlentmeminimizer/corpusscheduler。这个名字有点吓人，但它可以归结为一个由队列支持的最小化策略，该队列用于从语料库中获取测试用例。它将对快速/小型测试用例进行优先排序，这些测试用例执行覆盖率地图元数据中注册的所有条目。

The QueueCorpusScheduler is used as the IndexesLenTimeMinimizerCorpusScheduler’s backing queue.

这个 QueueCorpusScheduler 用作 IndexesLenTimeMinimizerCorpusScheduler 的备份队列。

let scheduler = IndexesLenTimeMinimizerCorpusScheduler::new(QueueCorpusScheduler::new());

Component: Fuzzer

References:

参考文献:

• Fuzzer Book Entry 模糊图书条目
• Fuzzer API Entry API 条目

The Fuzzer component contains our feedback, objectives, and a corpus scheduler. It’ll be the primary driver of our program, running the target program with the generated Input while triggering Observers and Feedbacks.

模糊组件包含我们的反馈、目标和一个语料库调度器。它将是我们程序的主要驱动程序，在触发观察器和反馈的同时，使用生成的输入运行目标程序。

let mut fuzzer = StdFuzzer::new(scheduler, feedback, objective);

Component: Executor

References:

参考文献:

• Executor Book Entry 遗嘱执行人登记簿
• Executor API Entry 空气污染指数报告

The Executor component is one of the few remaining. We’ll use a TimeoutForkserverExecutor. The TimeoutForkserverExecutor wraps the standard ForkserverExecutor and sets a timeout before each run. This gives us an executor that that implements an AFL-like mechanism that will spawn child processes to fuzz.

Executor 组件是仅存的几个组件之一。我们将使用 TimeoutForkserverExecutor。TimeoutForkserverExecutor 包装标准的叉车执行器，并在每次运行之前设置一个超时。这为我们提供了一个执行器，它实现了一个类似于 afl 的机制，这个机制将把子进程生成为模糊。

Part of creating our Executor is telling it what we want it to execute. In our case, we want to run the following.

创建我们的 Executor 的一部分是告诉它我们希望它执行什么。在我们的例子中，我们想运行以下代码。

./path/to/pdftotext INPUT_FILE

We’ll pass the path to pdftotext to the ForkserverExecutor constructor, along with the args it needs to run. We’ll use the double-@ symbol to tell the ForkserverExecutor that we want the BytesInput (covered earlier) generated from each testcase to be written to a file, and that the same file’s path should overwrite the @@ in the final command. Because we’re passing our generated Input via an on-disk file, we’ll set the use_shmem_testcase to false. Finally, we’ll pass our Observers into the ForkserverExecutor’s constructor, rounding out the call.

我们将把 pdftext 的路径和它需要运行的 args 一起传递给 forcserverexecutor 构造函数。我们将使用 double -@符号来告诉 forcserverexecutor，我们希望从每个测试用例生成的 BytesInput (前面已经介绍过)被写到一个文件中，并且在最终命令中，同一个文件的路径应该覆盖@@ 。因为我们是通过磁盘文件传递生成的 Input，所以我们将 use _ shmem _ testcase 设置为 false。最后，我们将观察器传递到 ForkserverExecutor 的构造函数中，完成调用。

let fork_server = ForkserverExecutor::new(
    "./xpdf/install/bin/pdftotext".to_string(),
    &[String::from("@@")],
    false,  // use_shmem_testcase
    tuple_list!(edges_observer, time_observer),
).unwrap();

With that out of the way, we simply need to choose the length of our timeout, and pass the resulting Duration and ForkserverExecutor to the TimeoutForkserverExecutor’s constructor.

解决了这个问题之后，我们只需要选择超时的长度，并将结果的 Duration 和 ForkserverExecutor 传递给 TimeoutForkserverExecutor 的构造函数。

let timeout = Duration::from_millis(5000);

// ./pdftotext @@
let mut executor = TimeoutForkserverExecutor::new(fork_server, timeout).unwrap();

Components: Mutator + Stage

References:

参考文献:

• Mutator Book Entry 记录条目
• Mutator API Entry 条目
• Stage Book Entry 舞台剧参赛作品
• Stage API Entry 阶段空气污染指数

The final pieces of the puzzle are the Mutator and Stage components. We’ll register our StdScheduledMutator as a Stage using the StdMutationalStage component. A mutational stage is the stage in a fuzzing run that mutates the Input. Mutational stages will usually have a range of mutations that are being applied to the input one by one, between executions. In our case, the range of mutations we’ve chosen are the ever popular Havoc mutations. Each mutation is scheduled by the StdScheduledMutator as part of the mutational stage.

拼图的最后一部分是 Mutator 和 Stage 组件。我们将使用 stdout 变换阶段组件注册我们的 stdout scheduledmutator 为 Stage。变异阶段是输入变异的 fuzzing 运行中的阶段。突变阶段通常会有一系列的突变，这些突变在执行之间一个接一个地应用到输入端。在我们的案例中，我们选择的突变范围是一直流行的浩劫突变。每个突变都是由 stdout/scheduledmutator 作为突变阶段的一部分进行安排的。

let mutator = StdScheduledMutator::new(havoc_mutations());
let mut stages = tuple_list!(StdMutationalStage::new(mutator));

Running the Fuzzer

运行 FUZZER

That’s it for the individual components. All that’s left is for us to run the fuzzer. Recall that the Fuzzer takes ownership of a bunch of different components and essentially makes everything run. Knowing that, we pass in our stages, executor, the state, and the event manager. The code to make that happen is shown below.

对于单个组件来说就是这样。剩下的就是我们来运行这个模糊器了。回想一下，Fuzzer 拥有一大堆不同组件的所有权，并且本质上让所有东西运行。知道这一点，我们通过了我们的阶段，执行者，国家和活动经理。下面显示了实现这一目标的代码。

fuzzer
    .fuzz_loop(&mut stages, &mut executor, &mut state, &mut mgr)
    .expect("Error in the fuzzing loop");

Build the Fuzzer

建立模糊器

Ok, it’s been a long time coming, but the moment has arrived! With build.rs setup to take care of building Xpdf, we can build our fuzzer and the fuzz target with a single command.

好吧，这是一个漫长的时间来了，但这一刻已经到来！通过 build.rs 设置来处理 Xpdf 构建，我们可以使用一个命令来构建 fuzzer 和 fuzz 目标。

cd fuzzing-101-solutions
cargo build --release

Commence Fuzzing!

开始模糊

After the build completes, we can kick off our artisnal, hand-crafted fuzzer.

建立完成后，我们可以开始我们的艺术，手工制作的模糊。

cd exercise-1
../target/release/exercise-one-solution

On my machine, it took roughly 10 minutes to get a timeout. The objectives: 1 shows that we have 1 testcase that met the fuzzer’s objective (a timeout that also produced new coverage).

在我的机器上，大概花了10分钟才得到一次暂停。目标: 1表明我们有1个测试用例符合 fuzzer 的目标(超时也产生新的覆盖率)。

[Stats #0] clients: 1, corpus: 640, objectives: 1, executions: 568810, exec/sec: 1744

Results

结果

We can confirm that we’ve found a bug by using the PDF inside the timeouts folder (our output corpus).

我们可以通过在超时文件夹(我们的输出语料库)中使用 PDF 来确认我们发现了一个 bug。

./xpdf/install/bin/pdftotext ./timeouts/7e3a6553de5cce87
════════════════════════════════════════════════════════
Error: PDF file is damaged - attempting to reconstruct xref table...
Error (677): Illegal character <2c> in hex string
Error (678): Illegal character <2c> in hex string
Error (679): Illegal character <2c> in hex string
-------------8<-------------
Error (3245): Dictionary key must be a name object
Error (3248): Dictionary key must be a name object
Error (3255): Dictionary key must be a name object
Segmentation fault

Outro

女名女子名

\o/ Huzzah! We’ve created our own fuzzer using LibAFL that was specifically tuned to find a recursion bug in real-world software; pretty neat eh? The companion code for this exercise can be found at my fuzzing-101-solutions repository.

啊，万岁！我们已经使用 LibAFL 创建了我们自己的 fuzzer，它专门用于在现实世界的软件中发现一个递归错误，很棒吧？这个练习的伴随代码可以在我的 fuzzing-101-solutions 存储库中找到。

In the next post, we’ll tackle the second exercise. See you then!

在下一篇文章中，我们将处理第二个练习。到时候见！

Additional Resources

额外资源

1. Fuzzing101 
2. AFL++ 
3. LibAFL
4. LibAFL API Documentation 文档
5. LibAFL Book
6. forkserver_simple example fuzzer 简单的例子 fuzzer
7. fuzzing-101-solutions repository Fuzzing-101解决方案库