ConsenSysDiligence/daedaluzz

# Daedaluzz：智能合约模糊测试器的基准生成器 *Daedaluzz 是一个用于自动生成智能合约模糊测试器基准的工具。该基准生成方法的灵感来源于针对 C 语言模糊测试器的 [Fuzzle](https://softsec.kaist.ac.kr/~sangkilc/papers/lee-ase22.pdf) 基准生成器。* *一个关键目标是尽可能多地比较不同的模糊测试器。因此，这些基准有意使用 Solidity 的一个有限子集，以避免某些工具可能以不同方式处理（或根本无法处理）的语言特性。* ## 基准生成方法 每个生成的基准合约都包含许多断言（有些可能会失败，而另一些由于不可满足的路径条件而无法失败）。模糊测试器可以创建一系列交易来触发这些断言失败。我们可以通过发现的不同断言违规的数量来衡量模糊测试器的性能。 宏观来看，每个合约都跟踪固定维度（例如 7x7）的二维迷宫中的当前位置。每笔交易都可以移动当前位置以探索迷宫。迷宫中的某些位置是不可达的（所谓的“墙壁”），而其他位置可能包含“漏洞”，当提供特定的交易输入时，模糊测试器可以发现这些漏洞。由于路径条件不可满足，其中一些漏洞是无法到达的。 生成的基准试图捕捉模糊测试智能合约时的两个关键挑战： 1. 只能通过满足复杂的交易输入约束才能到达的代码 2. 只能通过多笔先前交易首先达到合约的特定状态才能到达的代码 未来，我们可能会扩展基准生成器，以纳入我们在模糊测试现实世界合约时经常遇到的其他挑战。我们非常乐意讨论有关此类扩展的想法！ ## 基准示例 我们已经使用 Daedaluzz 生成了 5 个基准合约（参见 `generated-mazes` 文件夹）。然而，通过修改[随机种子](https://github.com/ConsenSys/daedaluzz/blob/2c163f4ed12484203345e1df2c619ba53739885d/main.go#L158)和其他超参数（例如 [`numFuncParams`](https://github.com/ConsenSys/daedaluzz/blob/2c163f4ed12484203345e1df2c619ba53739885d/main.go#L159)、[`dimX`](https://github.com/ConsenSys/daedaluzz/blob/2c163f4ed12484203345e1df2c619ba53739885d/main.go#L161) 和 [`maxDepth`](https://github.com/ConsenSys/daedaluzz/blob/2c163f4ed12484203345e1df2c619ba53739885d/main.go#L164)），可以轻松生成新的基准。 还可以调整基准生成器，为不支持默认基准的模糊测试器生成自定义基准变体。例如，我们使用它为 Foundry/Forge 模糊测试器生成了自定义基准实例；请参阅 [`foundry-code-generation`](https://github.com/ConsenSys/daedaluzz/tree/foundry-code-generation) 分支以及 `generated-mazes` 文件夹中以 `.foundry.sol` 结尾的文件。 ## 基准测试基础设施 该仓库还包含用于在生成的基准上运行几种流行模糊测试器的基础设施（例如脚本和 Dockerfile）： - [Echidna](https://github.com/crytic/echidna) - [Foundry/Forge](https://github.com/foundry-rs/foundry/tree/master/forge) - [Harvey](https://mariachris.github.io/Pubs/FSE-2020-Harvey.pdf) - [Hybrid-Echidna](https://github.com/crytic/optik) - [ItyFuzz](https://github.com/fuzzland/ityfuzz) `run-all-fuzzers.sh` 脚本可用于对上述模糊测试器进行基准测试，`show-stats.py` 脚本可用于聚合和可视化结果。 ## 常见问题解答 #### 为什么生成的基准使用 `uint64` 类型的输入？ 主要有三个原因： 1. 我们观察到一些模糊测试器——特别是那些使用约束求解器的——在处理较大位宽（例如 `uint256`）的算术运算时会遇到困难。我们希望基准能兼容尽可能多的模糊测试器。 2. 通过默认使用 64 位算术，我们可以轻松调整 Daedaluzz 以生成其他语言（如 C）的基准，并与更多的模糊测试器进行比较。 3. 可以通过调整 [`numFuncParams` 参数](https://github.com/ConsenSys/daedaluzz/blob/cb88f7d91bf21eefda047b98f8cb2e9efa7adeca/main.go#L159)轻松增加输入字节的数量（这可能会增加基准的难度）。 我们未来愿意重新审视这一设计选择。 #### 你们是如何确定当前的超参数的？ 我们尝试了几种设置，但没有详尽地评估每个超参数。主要目标是找到一种能够生成具有挑战性且符合 EVM 代码大小限制的基准的配置。 我们未来愿意对这些超参数进行更改。 我们希望避免模糊测试器开发者将其工具过拟合于这个特定版本的基准。因此，我们正在考虑定期调整基准（例如每年一次或两次）。基准生成工具（如 Daedaluzz）极大地简化了这项任务。 #### 在这些基准上表现良好的模糊测试器在我的代码上也会表现良好吗？ 不一定。唯一的验证方法是在您的代码上尝试该模糊测试器。如果您有时间，应该尽可能多地尝试不同的模糊测试器。然而，如果一个模糊测试器在这些基准上表现不佳，那么在您的代码上尝试它可能就不值得您花费时间了。

标签：Cutter, Fuzzing, Fuzzle, Solidity, 代码覆盖率, 以太坊, 区块链安全, 反取证, 可配置连接, 基准测试生成器, 安全评估, 日志审计, 智能合约, 测试基准, 测试工具, 状态探索, 程序分析, 约束求解, 请求拦截, 逆向工具