Quimera：一种反馈驱动的以太坊智能合约漏洞利用生成工具

+++ title = "Quimera 介绍：使用 LLM 的以太坊智能合约的反馈驱动的漏洞利用生成" date = "2025-07-03" description = "一篇描述 Quimera 的博文，Quimera 是一种利用 LLM 为以太坊智能合约生成反馈驱动的漏洞利用的工具。它包括功能列表、初步结果和近期展望" tags = [ "quimera", "LLM", "exploit-generation", "foundry" ] +++ 在过去的几周里，我一直在原型设计一个名为 Quimera 的新开源工具。Quimera 的诞生源于我对自动漏洞利用生成的浓厚兴趣、LLM 推理的最新进展，以及坦率地说，大量的空闲时间。 Quimera 背后的核心思想是使用反馈驱动 的以太坊智能合约漏洞利用生成，充分利用 LLM 和 Foundry 追踪。本质上，该工具为 LLM 提供迭代反馈，以帮助它在 Solidity 中构建智能合约漏洞利用，模仿真正的安全研究人员处理任务的方式。此反馈来自源代码分析、链上数据和 Foundry 追踪的组合。

常规方法和功能

Quimera 旨在针对一种单一但至关重要的漏洞类型：允许攻击者耗尽目标合约（或多个合约）资金的漏洞。整个过程可以概括为以下步骤：

1. 获取目标智能合约的源代码，并生成一个描述漏洞利用目标的提示（例如，在偿还闪电贷后产生利润）。
2. 要求 LLM 创建或改进一个 Foundry 测试用例，以尝试利用该合约。
3. 运行测试，检查交易追踪，并检查是否产生了利润。
4. 如果漏洞利用成功，则停止。如果没有，则返回步骤 2，并向 LLM 提供失败尝试的追踪，以帮助改进下一次迭代。

提供给 LLM 的初始提示包含以下信息：

• 目标合约的名称、地址和链。
• 完整的源代码，包括所有依赖项和目标合约的扁平化接口。
• 公共和私有变量的当前值。公共变量可以使用 Solidity 直接访问，但私有变量更难。对于这些变量，我们使用 slither-read-storage 来检索它们的值。
• 最后，我们通知 LLM，合约中存在一个高危漏洞，允许耗尽资金。虽然这可能不一定是真的，但我们遵循 George Costanza 的智慧：“如果你相信它，那它就不是谎言。”“It’s not a lie if you believe it.”.

此外，LLM 被授予访问一组“工具”的权限，它可以在推理阶段（即在“思考模式”中）调用这些工具。这些工具允许它收集上述任何任意地址的信息，从而使 LLM 能够在漏洞利用生成过程中动态扩展其目标集。

Quimera 背后的主要目标之一是探索这项技术的实际能力：哪些 LLM 表现更好，如何编写有效的提示，以及哪些类型的漏洞最容易重现。我测试了几种 LLM 服务（例如，Gemini、Grok、Claude、DeepSeek）和一些本地模型（例如，Qwen），并且在撰写本文时，我唯一可以推荐的是 Gemini 2.5 Pro。其余的通常会产生次优结果：频繁的编译器错误、未能遵守约束等。

在功能方面，我想强调 Quimera 的两个小而有用的方面：

文本用户界面 (TUI)

Quimera 包括一个漂亮的文本用户界面 (TUI)。

此功能不仅仅是为了美观，它还具有实际用途。TUI 允许用户浏览先前生成的代码，从而更容易手动调整、分析或继续漏洞利用开发，而不会忘记该工具到目前为止所做的事情。当漏洞利用接近工作状态，几乎产生利润，但由于一些细微问题而被阻止时，这尤其有用。人工操作员可以介入，快速获得见解，并将其推过终点线。

支持开发中的合约

虽然 Quimera 最初是为测试已部署的合约而构建的，但它也可以轻松地用于仍在开发中的智能合约。为此，你只需要添加一个新的 Foundry 测试，如下所示：

...
​​contract QuimeraBaseTest is Test {
    address public target;
    IWETH public WETH = new MockToken();
    address internal user1 = address(0x123);
    address internal user2 = address(0x456);
    function setUp() public { ... }
    //$executeExploitCode
}

在本地模式下，Quimera 将使用此测试作为起点。开发人员只需要设置合约并定义任何相关的约束，以确保结果有意义。这使得 Quimera 成为一个灵活的工具，不仅可以重现现实世界中的漏洞利用，还可以帮助开发人员在开发的早期阶段验证他们的代码。

积极的结果（到目前为止）

在深入研究一些结果之前，重要的是要澄清一个方法论问题：闭源 LLM 在海量数据集上进行训练，这些数据集可能包括已知的漏洞利用、分析或我们正在测试的漏洞的善后报告。但是，根据我的观察，在漏洞利用生成过程中表现出的迭代行为与简单的检索或“记忆化”输出不符。相反，它似乎是每个步骤中真正推理的等级。

无论如何，让我们开始积极的结果，一个我经过几天使用该工具后能够重现的已知漏洞列表：

此外，在观察 LLM 推理过程几个小时后，我确定了三种易于识别的不同“精神状态”：

1. 探索或高层规划：

这是模型尝试随机想法只是为了看看什么有效，或者它试图制定一个高层计划的阶段。总的来说，该模型在这里往往无效：它经常无法识别缺失的步骤或逻辑上的差距。我认为这个阶段可以从规划代理或外部过程（例如，模糊器或静态分析器）的支持中大大受益，以指导推理。

2. 解决问题或克服障碍：

这是模型尝试修复特定问题（例如，由未满足的条件引起的恢复）的地方。它在这个阶段表现出奇的好，可能是因为任务是具体的，并且成功很容易衡量。反馈循环很紧密，这使得它成为我测试过的大多数 LLM 的优势。

3. 优化或微调工作路径：

一旦模型找到一些执行没有错误并且看起来像潜在漏洞利用的代码，它就会进入一个阶段，它需要优化结果以实际达到最终目标（例如，在偿还闪电贷后获得利润）。该模型在这里做得“还可以”：它倾向于通过一次调整一个参数并观察效果来缓慢迭代。例如，它可能会在每个步骤中将值调整 0.01 ETH，而十倍的增加会更合适。尽管效率低下，但它通常最终还是会设法完成工作。

挑战

我也想谈谈负面结果，因为它们对于理解当前方法的局限性以及确定如何改进它至关重要。

一个值得强调的特殊案例是 Alkimiya 漏洞利用。选择该漏洞利用进行重现是因为它达到了平衡：它既不太容易也不过于复杂，但确实需要非常精确的步骤序列才能复制。它也相对较新，只有几个月历史。 从理论上讲，Gemini 不应该事先知道该漏洞利用，因为 其知识截止日期是 2025 年 1 月。直接询问它会产生幻觉的技术细节，这些细节甚至与真实细节相差甚远，因此我们不必担心来自训练数据的污染。

对于这个小规模的实验，我在 Quimera 中运行了大约 20 次迭代，看看它是否可以达到漏洞利用条件。虽然该模型没有完全成功（即，它没有以导致利润的方式发现该漏洞利用），但它仍然能够重现大多数步骤，包括识别根本原因。你可以在此处看到该过程的快照：

（注意：此视频不是实时的。它被加速以跳过每次响应之间的等待时间。）

有几个因素导致了无法产生有效漏洞利用的失败：

事实证明，此漏洞利用比预期更难，不仅是因为代码复杂性或所需的函数调用序列，还因为它在迭代重现过程中不会发出强烈的利润信号。该模型最终停留在高原上，尝试不同的操作，但没有一个操作会导致利润的任何有意义的变化。这种信号的缺乏使得很难确定一个富有成效的探索方向。这与其他成功的漏洞利用重现形成对比，在其他成功的漏洞利用重现中，要么在进行一些调整后很容易获得利润，要么模型可以慢慢迭代以获得积极的结果。

也就是说，Foundry 追踪仍然提供了有用的见解，可以了解阻塞者和死胡同。

未来的工作

除了继续尝试寻找新的漏洞来重现之外，我还想测试其他一些想法：

• 更好与规划代理集成。
• 允许该工具使用模糊测试工具，甚至在某种有限的范围内使用符号执行，以帮助它达到漏洞利用条件。
• 将 DefiHack 存储库 转换为 Quimera 可以浏览的过去漏洞利用库。

与软件领域的许多趋势一样，这种应用始终有可能 永远不会超出概念验证阶段。尽管如此，我仍然充满希望，并且计划继续努力，以帮助揭示这些模型真正能够做什么。

• 原文链接： github.com/gustavo-griec...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～