理解的代价：LLM驱动的逆向工程与迭代LLM混淆

简介

在过去的几年中，我们注意到 LLM 的能力发生了显著的变化，LLM 能够富有成效地执行各种任务，解决现实世界中的问题，如程序合成、恶意软件研究或漏洞研究。在逆向工程中，如果有合适的工具，LLM 尤其有效，因为即使没有符号，它们也能很好地读取源代码。不仅如此，由于知识渊博，他们还能够模仿和应用逆转方法。

程序混淆方法在对程序进行转换所需的时间和逆向工程所需的时间之间造成了明显的不对称，从而为逆向工程提供了相对有效的防御，并给研究人员带来了浪费时间和开发新方法的压力。LLM 的出现极大地改变了游戏规则，因为现在的模型能够在合理的时间内破解这些混淆（取决于所应用的转换），从而扭转了这种不对称，使之有利于攻击者。

然而，在这场 "猫捉老鼠 "的游戏中，我们假定，混淆器制造商迟早会采用新技术，并提高标准，就像面对逆向工程从未如此普及的新现实，软件生产商会系统地应用这些改造来保护自己的知识产权一样。

Elastic 每年两次在 ON 周期间为工程师提供为期一周的研究项目机会。在四月的 2026 会议上，受这篇文章的启发，我们研究了针对 LLM（特别是 Claude Opus 4.6）的 vibecode 混淆技术有多么便宜和容易。这项研究将涵盖我们进行的一项初步基准测试，在这项测试中，我们针对使用学术性（但非常强大）的Tigress混淆器进行各种转换组合编译的目标对该模型进行了测试。随后，我们将研究针对该模型的各种有效混淆技术，并使用 dev/test/prove 人工智能驱动流水线对这些技术进行完全振动编码。

由于时间有限，我们将重点放在静态分析防御上。不过，我们毫无疑问地认为，我们所使用的工作流程也可用于研究动态分析防御的思路，如规避和反调试技术，使 LLM 驱动的分析变得更加昂贵和不可靠。

关键要点

• LLM 快速重塑了软件行业，使逆向工程等复杂的课题变得更容易理解，包括破解各种级别混淆的能力
• 严重混淆会大幅增加计算成本和时间，破坏自动分析管道
• 针对 LLM 的有效静态分析对策开发成本低廉、速度快
• 成功的 LLM 防御利用了上下文窗口、预算上限和快捷键偏差

Claude Opus 4.6 与 Tigress Obfuscator 的基准比较

我们使用 Claude 对其静态解决用学术混淆器 Tigress 混淆的 crackme 的能力进行了基准测试。

基准管道

为了进行这些测试，我们使用了控制器/工作程序设置，其中一个 Opus 实例管理子实例：它监控子实例的进度，收集子实例的结果，如果它判断某个实例正在取得进展并具有潜力，就可以为该实例分配更多时间。反之，如果它估计模型在执行任务时陷入困境、兜圈子或开始蛮干，它也可以杀死实例。

每个 Worker 子实例都可访问安装了 IDA Pro 的 Windows 虚拟机，并可通过 IDA MCP 插件进行访问。它还可以访问其运行的 Linux 虚拟机的资源，以开发和启动脚本。

此外，我们还使用了与 Claude 兼容的Caveman 插件，它可以在启动时通过正确的指令减少 LLM 的絮语，最高可达 -75% 。这样可以提高工作速度，降低每项任务的成本。我们在默认模式下使用它。

这种设置允许每个 Worker 实例以空上下文和经典的逆向工程提示开始测试，因此它不知道自己作为基准的一部分正在被监控。

评估系统

在评分方面，每个目标由控制器实例在三个轴上评分（每个轴 0-2 分），最多 6 分：

测试用例

为了进行这些测试，我们使用了以下挑战：通过静态反向工程恢复编译二进制文件的密码r3v3rs3! 。

// Run 2 crackme — 4-round XOR cipher with LCG key schedule
// Password "r3v3rs3!" only recoverable by reversing the algorithm.
// No key array in the binary — only a 32-bit seed.

unsigned int key_seed = 0x5EED1234u;

unsigned char enc_expected[8] = {
    0x1a, 0xcb, 0x74, 0xaa, 0x1a, 0x8b, 0x31, 0xb8
};

void transform(const char *input, unsigned char *output, int len) {
    unsigned int s = key_seed;
    unsigned int subkeys[4];

    // Key schedule: derive 4 round subkeys via glibc LCG
    for (int r = 0; r < 4; r++) {
        s = s * 1103515245u + 12345u;
        subkeys[r] = s;
    }

    // Copy input to 8-byte buffer (zero-padded)
    for (int i = 0; i < 8; i++)
        output[i] = (i < len) ? (unsigned char)input[i] : 0;

    // 4 rounds: XOR with subkey bytes, then rotate left by 1
    for (int r = 0; r < 4; r++) {
        for (int i = 0; i < 8; i++)
            output[i] ^= (unsigned char)(subkeys[r] >> (8 * (i & 3)));

        unsigned char tmp = output[0];
        for (int i = 0; i < 7; i++)
            output[i] = output[i + 1];
        output[7] = tmp;
    }
}

int verify(const unsigned char *transformed, int len) {
    if (len != 8) return 0;
    for (int i = 0; i < 8; i++)
        if (transformed[i] != enc_expected[i]) return 0;
    return 1;
}

// main(): reads argv[1], calls transform(), calls verify()
// prints "Access granted!" or "Access denied."

实施结果

默认运行

我们用不同的转换来编译挑战，每种转换产生不同的二进制文件，但具有相同的行为和特征。第一次运行时，我们对每种转换都使用了默认选项。这里提供 Tigress 中的所有变身功能。测试分为 4 个阶段，难度依次递增，共有 22 个目标：

相位 0 - 无变换

• p0_baseline - 没有转变

阶段 1 - 个人变形（7 个目标）：

• p1_encode_arithmetic - 仅编码算术
• p1_encode_literals - 仅 EncodeLiterals
• p1_flatten_indirect - 仅扁平化（间接
• p1_jit - 仅 JIT
• p1_jit_dynamic - 仅 JitDynamic(xtea)
• p1_virtualize_indirect_regs - 仅虚拟化（间接、条例
• p1_virtualize_switch_stack - 仅虚拟化（交换机、堆栈

阶段 2 - 配对变形（7 个目标）：

• p2_both_data - 编码字面 + 编码算术
• p2_flatten_ind_enc_arithmetic - 扁平化（间接） + 编码算术
• p2_flatten_ind_virt_sw - 扁平化（间接） + 虚拟化（开关）
• p2_jitdyn_enc_arithmetic - JitDynamic(xtea) + EncodeArithmetic
• p2_virt_ind_enc_arithmetic - 虚拟化（间接、规则） + 算术编码
• p2_virt_ind_enc_literals - Virtualize(indirect,regs) + EncodeLiterals
• p2_virt_sw_enc_arithmetic - 虚拟化（开关） + 编码算术

阶段 3 - 重型组合（7 个目标）：

• p3_double_virtualize - Virtualize(switch) then Virtualize(indirect,regs) - 嵌套虚拟机
• p3_double_virt_both_data - 双重虚拟化 + 编码字面量 + 编码算术（老大）
• p3_flatten_ind_both_data - 扁平化（间接） + 编码字面 + 编码算术
• p3_flatten_virt_ind_enc - Flatten(indirect) + Virtualize(indirect,regs) + EncodeArithmetic
• p3_jitdyn_both_data - JitDynamic(xtea) + EncodeLiterals + EncodeArithmetic
• p3_virt_ind_both_data - Virtualize(indirect,regs) + EncodeLiterals + EncodeArithmetic
• p3_virt_sw_both_data - 虚拟化（开关） + 编码字数 + 编码算术

完整的转换列表以及我们使用的生成选项可在此处获取。

结果评估综合了三个关键标准：性能得分、成本和任务执行时间。必须指出的是，即使大型语言模型性能很高，其实际效率也总是受到成本和时间的限制。这两个因素在大规模二进制分析中起着决定性作用，我们的目标是通过 Elastic 开发的不同自动分析管道来优化这项任务。因此，我们的目标是确定使用 Tigress 等工具是否会显著提高这三个基本变量：性能、成本和时间。

Opus 4.6 解决了 40% 20 个任务（其中 22 2 挂起，无法评估），成功的平均成本为 2.39 美元，失败的平均成本为 4.83 美元。在这 40 个% 中，12.5 个% 来自 0 阶段（无混淆的裸挑战），50 个% 来自 1 阶段（简单转换），38.5 个% 来自 2 阶段（成对转换），0 个% 来自 3 阶段（多层）。

毫无意外，我们观察到，随着难度的增加，成本和时间性能系数都会显著增加。第 3 阶段包括最复杂的转换组合，结果最好，平均成本为 4.32 美元。在这一阶段，所有失败的任务都被终止，因为模型开始通过无线索或蛮力来浪费令牌，无法取得任何进展。

在第一阶段，JIT（准时制）类型的混淆被证明是我们的模型最棘手的转换。这种技术包括以加密的中间形式存储代码。执行时，混淆器读取字节码并生成有效的 x86 代码，然后在动态分配的内存中执行。这一过程与虚拟机（如 PlayStation 仿真器）的过程类似，后者为不同于目标机的架构编译代码，并使用仿真器，在执行前增加 JIT 步骤。

尽管 JIT 任务失败了，但值得注意的是，Opus 4.6 仍然在crackme 中识别出了承载 LCG 算法的引擎结构。失败的关键在于找回找到钥匙所需的关键常数。

其工作仍然令人印象深刻，可以假定，如果增加预算并提供更好的指导，该模式本可以取得成功。然而，我们必须考虑到，产生这样一项任务的难易程度与解决这项任务所需的时间和成本之间存在着实际的不对称。对于简单的转换来说，这种混淆技术非常有效，并使通过自动管道增加处理样本数量变得不可行。

第三阶段的特点是混淆层的倍增和组合，导致成本激增。虽然克劳德又一次出色地完成了部分工作，但这项任务超出了它独立完成的能力。

例如，我们的研究结果表明，面对双层虚拟化（如在 GBA 模拟器中运行 Game Boy Advance 游戏，而 GBA 模拟器本身又在 PlayStation 模拟器中运行），Claude 能够恢复上层虚拟机（PlayStation）的处理程序和字节码。然而，这一漏洞的利用需要大量工作：对处理程序进行静态分析，对目标仿真器进行迭代开发（多个开发/调试周期），然后对结果进行分析。

然而，克劳德把大部分预算都花在了这些初步步骤上。可以想象，只要有无限的时间和预算，再加上稍加指导，他就能成功完成整个任务。这种效率使他在执行特殊任务或 CTF（夺旗战）时非常强大。尽管如此，混淆仍然是一种有效的防御手段，可以最大限度地降低成本和缩短时间，从而处理尽可能多的样本。

硬化运行

Tigress 还有其他选项，可以让转换变得更加复杂；在上一次迭代中，我们使用的是默认选项。在这篇文章中，我们选取了克劳德成功破解混淆的案例，并使用了最激进的选项。

我们对以下任务进行了强化和基准测试：

• p1_encode_arithmetic - 仅编码算术
• p1_flatten_indirect - 仅压平（间接
• p1_virtualize_indirect_regs - 仅虚拟化（间接、条例
• p2_both_data - 编码字面 + 编码算术
• p2_flatten_ind_enc_arithmetic - 扁平化（间接） + 编码算术
• p2_virt_ind_enc_arithmetic - 虚拟化（间接、注册表） + 算术编码

完整的转换列表以及我们使用的生成选项可在此处获取。

对每种测试转换应用最激进的混淆选项并不会导致模型在之前托管的任务中失败。不过，成本和时间系数都有明显增加：就p2_flatten_ind_enc_arithmetic 任务而言，时间系数增加了 4 倍，成本系数增加了 4.5 倍。

将控制流扁平化（CFF）和复杂的混合布尔运算（MBA）表达式结合起来，似乎比将虚拟化（VM）和 MBA 结合起来更有效。这种优越性源于这样一个事实：即使代码被虚拟化，Tigress 实现的虚拟机处理程序仍然很小，而且易于分析。相反，CFF 会导致函数大小爆炸，这似乎是对 LLM 影响更大的弱点。

比较结果见下表：

针对 LLM 的混淆技术开发

近年来，法律硕士逆向工程封闭源代码软件的能力有了显著提高，而且肯定会继续进步。迄今为止，传统的混淆方法在保护软件所需的时间和保护到位后反向工程所需的时间之间造成了严重的不对称。然而，正如我们在上一节中演示的那样，LLM 驱动的逆向工程代理完全有能力击败这些保护措施，并在静态和无辅助的情况下，以令人印象深刻的方法和准确性恢复原始代码，从而首次显著减少了这种不对称。

不过，我们也观察到，随着混淆复杂度的增加，时间、成本和成功因素都会受到极大影响，从而大大降低了自动分析管道处理样本数量的可行性。

虽然 LLM 使逆向工程变得更容易，但它们也使针对自身构建混淆变得同样容易。利用 Opus 4.6，我们针对基于 LLM 分析的结构和分析弱点，开发了一套源代码级技术。使用与之前相同的 crackme，我们在所有因素上都取得了惊人的结果，接近使用 Tigress 混淆器最难变换时的结果。

法律硕士薄弱环节分析

LLM 的逆向工程工作与人类的推理工作惊人地相似，主要区别在于人类不受上下文窗口的限制，随着窗口的填满，他们会变得越来越愚蠢。因此，上下文窗口显然是模型的第一个弱点，或许也是最重要的弱点；随着任务时间的延长，每读一次代码、思考、编写脚本等，上下文窗口都会被填满。因此，让模型在不必要的路径和死胡同上浪费尽可能多的时间是当务之急。

提示注入是另一种针对 LLM 的技术，它使用专门制作的提示（输入）来触发模型的意外行为（输出）。这种技术的目的是操纵或混淆底层系统，从而绕过安全控制，产生非预期或未经授权的结果。这带来了巨大的安全风险，因为它可能利用语言模型在解释指令和确定指令优先级方面的弱点，尤其是当部署在可访问敏感数据、外部工具或读写能力的互联网连接系统上时。虽然我们尝试在一些测试中嵌入和隐藏提示注入字符串，以诱使 LLM 提前结束分析或得出错误结论，但迄今为止，我们的尝试在 Opus 4.6 中都没有成功。

遗憾的是，我们每天在工作中使用的功能最强大的模型尚未开放源代码，而且由于运行这些模型所需的硬件，我们更难获得这些模型。这就是为什么我们要订阅在线模型，虽然这些模型功能强大，但用户却要花很多钱。因此，处理成本（无论是时间成本还是货币成本）是另一个主要弱点，这一点显而易见，也不足为奇，因为我们已经对此进行了大量讨论。与上下文窗口一样，我们将努力使模型损失尽可能多的循环次数，从而使其消耗最多的资金。如果模型在耗尽预算后也失败了，那我们就中大奖了。

最后，这也是最有趣的弱点，模特往往会作弊或走捷径。具体来说，当问题比较棘手时，它就会想尽一切办法来节省时间，甚至会倾向于撒谎来缩短时间。因此，我们在这里试图利用这一弱点，故意向模型提供虚假信息，并尽可能隐藏真实行为，使其误以为这些信息是真的，而不去深入挖掘。在不透露任何信息的情况下，正如你在后面的文章中看到的那样，即使有了可以挖掘的信息，我们还是发现了一些技术，完全挫败了对它的分析。

开发工作流程

为了开发这些混淆技术，我们使用了稍作修改的基准流水线版本，经过多次迭代、测试和改进，直到达到预期效果。迭代过程非常简单：我们开发一个版本，将二进制文件提交给一个新的工作实例，并进行逆向工程提示，在任务完成后评估结果，并与控制器实例讨论需要改进的地方。

这种方法更加有效，因为逆向工程实例为我们提供了它的整个思维过程，使我们能够轻松识别我们的混淆方法中使它实现突破的部分。然后，我们"vibecode" 改进，并进行下一次迭代。

通过使用这一工作流程，我们能够更好地理解其方法和分析逻辑，从而快速开发和改进我们的技术，每次迭代的结果都有显著进步，直到模型被击败。

混淆器变体 1：马特里奥什卡墙

这种混淆技术利用了 LLM 静态和动态分析能力之间的不对称。通过强迫代理串行地重新实现大量本机执行成本低廉而静态仿真成本高昂的操作，该技术造成了令人望而却步的时间成本比，使分析工作在现实的预算范围内变得不切实际。

这种技术将破解逻辑隐藏在加载器和 100,000 层加密--由连锁 ChaCha20 阶段组成的 "马卓什卡娃娃"--之后。LLM 可以正确识别密钥生成方案和解密步骤，但要解决这个难题，就必须实际运行这些步骤，而代理的静态分析工具无法在本地执行这些步骤。它必须在自己的循环中用 Python 重新实现 ChaCha20，在这里，100,000 次连续循环的速度慢得令人望而却步--代理会碰壁，并在到达内部有效载荷之前耗尽其代币预算。

结构和技术

该程序是一个 4.4 MB 的 ELF 文件，名为authd ，由三个逻辑部分组成：

• 作为外层的小型装载机
• 4.4 MB 加密有效载荷 Blob 嵌入加载程序的.rodata 部分
• 16 KBcrackme二进制文件，包括原始密码检查

向加载器提供密码后，它会以相反的顺序运行 100k 级。每个阶段的 ChaCha20 密钥都是由嵌入的主机种子与 32 字节片段 XOR 后得到的，而 32 字节片段只有在解密前一个阶段后才会显现，因此密钥不能仅由主机种子预先计算。

每次迭代只解密阶段的 44 字节头部，验证一个魔法字和阶段索引，提取下一个片段，并向前推进一个读取偏移量；迭代后，缓冲区尾部保存明文crackmeELF，加载器将其写入匿名memfd_create 文件描述符，并通过execve 发送--用crackme 代替自身，然后根据硬编码的预期密码运行用户密码。

虽然 ChaCha20 才是真正的密码，但二进制文件中却加入了 Salsa20 的误导种子--一个工作salsa20_core 实现、导出符号和供应商 ELF 注释--旨在将分析引向错误的密码。

实施结果

在第一次测试中，每个阶段的密钥都不是链式的--每个阶段的密钥都是主机种子和阶段索引的纯函数，可以独立计算。由于每个密钥只取决于host_seed 和i （二进制文件中嵌入了这两个静态数据），因此提取了主机种子的分析师可以一次性离线计算出所有 100,000 个密钥，然后并行解密每个阶段，而无需执行二进制文件。阶段头大小为 12 字节，二进制大小为 1.2 MB。

在使用 Opus 4.6 进行的首次基准测试中，花费了 1.50 美元，总共耗时 10 分钟， 30 次。它能够穿过控制流，识别打包器元素，解密 100k 层，并提取 ChaCha20 基本密钥。

在对二进制文件进行分流后，代理得出结论，要解决这个问题需要运行时执行，而它并不具备运行时执行能力，因此在没有尝试解密的情况下就停止了。这次行动很便宜（1.5 美元），但仍然达到了核心目标：特工没有找回密码。

在第二次迭代中，对程序进行了修改，使每个阶段的 ChaCha20 密钥都来自主机种子与存储在下一个外层阶段头中的 32 字节片段的 XOR，因此只有在该外层阶段解密后才会显示该片段。这意味着密钥无法仅通过主机种子进行预计算；分析人员必须按顺序执行链，解密每个阶段以获取下一阶段所需的片段。这一步将每个标头的阶段大小增加到 44 字节，使程序总大小达到 4.4 MB。

在使用 Opus 4.6 进行的第二次测试中，我们项目每个二进制的最大成本为 10 美元，耗时 56 分钟， 61 次。这次，代理尝试静态执行解密，但时间不够了。

这两项测试表明，LLM 代理受限于其工具而非推理能力。代理们正确理解了每项挑战的技术细节，但由于他们的分析局限于静态工具而碰壁。Salsa20 的误导增加了少量成本，但并没有对两名特工造成有意义的误导。更持久的发现是成本比很重要：这些二进制文件的本地执行时间约为 55 毫秒，但静态失败的成本为 1.50 美元至 9.67 美元。恶意软件开发者和威胁行为者很可能会利用这一漏洞，设计用于廉价本地执行和昂贵静态仿真的二进制文件。随着 LLM 代理的规模不断扩大，并通过动态执行工具获得更多能力，纯粹依赖这一差距的防御能力将被削弱，从而使这一优势成为短期优势而非持久优势。

混淆器变体 2：双丰收

Claude Opus 4.6 喜欢通过尽可能少的投入来提高工作效率。我们混淆程序的目的是尽可能简化其工作，向其提供一个分析解决方案，让其自豪地将分析结果呈现出来，而真正的有效载荷则埋藏在代码中，只要知道如何触发，就能清楚地获取。

为此，我们使用了一个开源库，并为某些函数打上了补丁，这样只要输入正确的信息，就能触发有效载荷。显然，我们会尽力隐藏有效载荷，并隐藏触发机制。

结构和技术

该项目的架构基于这样一个假设：我们希望克劳德相信程序没有隐藏功能，只是一个使用给定加密算法对作为参数传递的字符串进行加密的程序。从高层次的角度来看，该架构由一个主函数组成，该函数调用我们的库，并使用它执行加密任务，就像没有任何问题一样。通过必要的修改，将加载器功能隐藏在程序中，这样 IDA 就不会通过程序的序言/后记检测到该功能。xor 加密有效载荷也隐藏在程序中。最后，我们对开放源代码库libgcrypt中的一些函数进行了修补，使主函数能够通过正确的输入触发有效载荷；稍后将详细介绍。

为了达到这些效果，我们使用了多种技术来最大程度地隐藏所有机制，首先是如何从主函数中触发有效载荷：程序接受三个加密参数：要加密的字符串、要使用的算法 ID 和十六进制格式的密钥。

if (argc != 4)
{
  fprintf (stderr, "Usage: %s <string> <algo_id> <key_hex>\n", argv[0]);
  return 1;
}

libgcrypt 库函数使用算法标识符来选择和调用正确的加密函数。为此，程序库有一个指针表，其中包含 25 插槽： 24 用于算法， 1 为空。每个槽指向一个描述每种算法的对象，并包含一个指向相应处理程序的指针。我们对该表进行修补，将其扩展到 256 处理程序，并将最后一个处理程序设置为指向假对象gcry_cipher_spec_t 对象的指针。

static struct {
  gcry_cipher_spec_t *list[256];
} _gcry_cipher_table = {
  .list = {
    &_gcry_cipher_spec_blowfish,        /* [0]  */
    &_gcry_cipher_spec_des,             /* [1]  */
    // (...)
    &_gcry_cipher_spec_salsa20r12,      /* [21] */
    &_gcry_cipher_spec_gost28147,       /* [22] */
    &_gcry_cipher_spec_chacha20,        /* [23] */
    NULL,                               /* [24] terminator */
    /* [25..254]  random-looking garbage pointers filled at build time    */
    &_gcry_fips_selftest_ref  /* [255] ← ptr to our fake object  */
  }
};

我们制作了这个假对象，其中的 "algo = -1" 和encrypt 函数指针指向我们的加载器函数，因此当库调用加密函数时，它实际上调用的是我们的处理程序。

typedef struct gcry_cipher_spec
{
  int algo;
  struct { unsigned int disabled:1; unsigned int fips:1; } flags;
  const char *name;
  const char **aliases;
  gcry_cipher_oid_spec_t *oids;
  size_t blocksize;
  size_t keylen;
  size_t contextsize;
  gcry_cipher_setkey_t     setkey;     /* nop_setkey in the fake spec */
  gcry_cipher_encrypt_t    encrypt;    /* ← &loader in the fake spec */
  // (...)
} gcry_cipher_spec_t;

algo 字段是算法 ID，必须与用户请求的 ID 一致。那么，为什么是-1 呢？这非常简单：我们将指向假对象的指针放在指针表的255 插槽中，因为我们知道最初只存在 25 插槽。然后，我们修改了索引该表的函数，用0xff 屏蔽了索引，这样-1 (0xffffffffffffffff) 就变成了255 (0xff) 并指向我们的假对象指针。

在以前的版本中，指针与结构体直接相邻，克劳德顺利地找到了它，然后通过xref ，它很容易就找到了我们的加载器。因此，我们将指针从表中移开，并用垃圾数据填充空隙，这样当 LLM 找到表时，就不会意外地发现指向我们的假对象的指针，从而缓解了这一问题。

我们遇到的第二个问题是，假对象的指针最初是在运行时写入的，在静态分析过程中不会出现在数据中，因此克劳德无法通过扫描程序内存找到它。为此，我们在运行时解析了假对象地址和写入地址，然后将逻辑分散到库的一个初始化函数的调用树中的不同函数中。遗憾的是，尽管采取了这些预防措施，克劳德还是在对图书馆功能的全面分析中系统地确定了这些要素。

为了缓解这一问题，我们选择直接修补库代码，使指向假对象的指针保持静态。不过，为了确保我们的指针不会给我们的假对象和加载器创建一个xref ，也为了确保它不会独立存在，我们对所有表指针和我们自己的指针进行了加密，这样整个表，包括中间的随机数据，看起来就像垃圾一样。然后，我们对程序库打了补丁，使其在处理解密时不会显得太可疑。加密过程非常简单：我们知道指针很少在其所有 64 位上定义，因此我们使用高阶 8 位作为密钥对指针进行加密。

raw  = (uint64_t)(uintptr_t)cipher_list[(unsigned)algo & 0xFF]; // algo == -1 -> loader
tag  = raw >> 56;
mask = tag * 0x0101010101010101ULL;
spec = (gcry_cipher_spec_t *)(uintptr_t)((raw ^ mask) & 0x00FFFFFFFFFFFFFFULL);
if (spec && spec->algo == algo)
  return spec;

最后一个问题是，IDA 分析发现了我们的加载器函数，并且该函数出现在函数列表中，因此模型在审查所有函数时会在某一时刻对其进行反编译。

为了解决这个问题，我们制作了没有序幕和尾声的加载器，这样反汇编启发式程序就不会自动找到它。调用加载程序时，它会解密并加载到一个预先分配的空 RWX 段，名为".note.fips"试图融入其中。该段是空的，以免在静态分析过程中引起怀疑，但会被用来将我们的有效载荷作为 shellcode 执行。用于加密功能的参数被用于 crackme 功能。

最后，为了减少二进制差异，我们特意下载了一个稍旧版本的库，并修补了版本字符串，以伪装成最新版本，这样做的目的是为了更好地将我们的修补程序隐藏在其他合法变更中。

实施结果

为了进行研究和测试，我们告知该模型，它正在作为测试的一部分进行基准测试，并且必须查找程序中隐藏的裂痕。我们的目标是确保它不会止步于最初的结论，而是迫使它尽可能深入地研究。这使我们能够评估其分析的优缺点，并找到正确的缓解措施。

Reverse Engineering Prompt — Informed Scenario

Child knows there's a hidden crackme. Tests technical resilience of concealment.

---

System Prompt:

You are an experienced reverse engineer. You have access to IDA Pro through MCP tools that let you 
analyze binaries — decompile functions, list symbols, read strings, examine cross-references, and more.

探测深度得分根据以下标准进行评估：

以下是我们在不同的开发迭代中获得的结果：

正如您所看到的，尽管克劳德每次都能成功破解我们的隐藏程序并恢复 crackme 的密码，但每次迭代都会增加各种成本和时间因素。实际上，我们的 V6 版本出现了倒退，它简化了将加载器指针写入内存的方式，从而带来了新的缺陷。V7 是一次突破，它采用了前面介绍的技术，对装弹器指针的隐蔽装置进行了彻底的重新设计。

即使明确提示破解程序隐藏在二进制文件中，V7 还是让 Claude Opus 4.6 完全失效，结果是 1 （满分 5 ），花费 5.2 美元，耗时 11.9 分钟。

起初，我们提到要使用一个提示，向模型提供有关 crackme 的详细信息。为了评估该模型在现实世界中的性能，我们在没有这些附加信息的情况下对其进行了测试，以了解它在与 V7 对决时的失败速度。结果如下

毫无意外，"盲目 "方案的效果更好，满分 5 分， 0 ，但没有最大限度地考虑成本因素。事实上，它很快就满足了主功能诱饵逻辑的要求，觉得没有必要再深入研究了。

我们的研究结果证明，只要有正确的工作流程和指导，我们就能轻松构建针对 LLM 的高效欺骗方案，我确信，在相同的静态分析限制条件下，面对熟练的人类反向工程师，我们的方案连五分钟都抵挡不住。

混淆器变体 3：派遣迷宫

这个混淆器变体实现了一个状态机调度程序，将crackme算法（为 Windows 重新实现）隐藏在数千个结构类似的函数中。其核心思想是迫使模型从成千上万个逼真的诱饵中分辨出少数几个真正的密码节点，所有这些节点都有类似的 API 调用模式和依赖数据的控制流。LLM 会尝试限制decompile MCP 工具的调用量，以优化令牌消耗和上下文窗口的使用，而混淆的设计是为了确保它所采取的任何捷径都会错过真正的逻辑。

结构和技术

原始密码被分割成 20 个有序的片段，分散在 20 个随机选择的函数中，总共有 3,000 个，通过数据相关的状态转换串联在一起。剩下的 2,980 个函数是诱饵，包含实际的 Windows API 调用（文件、注册表、内存、密码、线程/同步、字符串操作）以及一些数学噪声。

执行流经易失性函数指针表：每个节点计算state_acc = state_acc * 0x6C078965 + CONST ，返回state_acc % 3000 ，然后调度器调用下一个节点。

以下是 4 随机函数处理程序的示例：

我们还促使 LLM 引入更多的复杂性，在其中实施了一些其他技术：

• 常数扩散 - 密码的 LCG 常数作为数学噪声被复制到约 50 个诱饵函数中，因此搜索这些值会返回与真正密码节点同时存在的假阳性结果
• 分散的enc_expected 全局 - 预期密码文本的 8 字节 (0x1a, 0xcb, 0x74, 0xaa, 0x1a, 0x8b, 0x31, 0xb8) 分别存储在一个单独的易失性全局中，隐藏在带有随机字节值的 92 诱饵全局中
• 不透明谓词把关假密码操作
• ~20 个逐字节构建的误导性字符串 (This is a standard Windows service manager utility.,String buffers used for Windows event log formatting., 等等)
• 通过模块化指数化的构造器派生key_seed (0x5EED1234)。

在运行初始测试时， 1 版本的混淆二进制文件在不到 12 分钟的时间内就被破解得干干净净。利用迭代开发工作流程，我们开发了第二个版本，通过两种主要加固技术对 1 进行了扩展，每种技术都针对破解基础变种的攻击中的特定步骤。

多样化的过渡模板

每个节点函数都以相同的算术运算结束：state_acc = state_acc * 0x6C078965 + CONST ，但在第 1 版中，所有 3,000 个函数都以相同的imul+lea 指令发出。LLM 利用了这一统一性，通过运行单个字节模式搜索，在一次执行中提取每个过渡常数。

在第 2 版中，代码生成器会为每个函数随机分配 11 结构不同的代码模板之一（底层运算相同）。有些乘法器的计算方法各不相同：将乘法器分成 16 位 hi/lo 部分或使用俄式农民比特循环。其他常量的表示方法也不尽相同，例如在运行时通过 XOR、ADD 或 SUB 从两个或三个易失子值组合中导出常量，或者从一个 500 条目易失性全局数组中读取常量，而实际上只有 13 条目用于查找所需的常量。没有一个模板的功能超过 ~10% 。

观察到的一个局限是，一些模板表达式，特别是较简单的算术拆分，在分析过程中被反编译器折回，从而减少了有效的多样性。更激进的模板（位环乘法、查表、易失中介）在反编译过程中完好无损。

真实链中的转运诱饵

在版本 1 中，分析员 LLM 从状态机的入口点开始对其进行模拟，发现了 20 访问函数，所有这些函数都包含原始密码逻辑。法律硕士选择完全忽略其他 2 980 个节点。在版本 2 中， 91 ，在实际执行链中插入了中转节点，每对连续的密码节点之间大约有 3-7 个中转节点。中转节点在执行过程中被访问，但不执行密码工作（包含相同的 API 调用、数学噪声和不透明谓词）。链式模拟后，将有 111 个访问过的函数，必须对每个函数进行反编译，以确定携带密码片段的 20 个实际函数。

实施结果

1 版本已完全解决。LLM 确定了调度程序，识别出所有 3,000 个过渡函数共享相同的指令模式，并使用单字节模式搜索一次性提取每个过渡常量。在此基础上，它模拟了状态机，发现只有 20 函数被访问过，对其进行了反编译，并识别出了 XOR 密码和 LCG 密钥时间表。最后，它以高置信度恢复了密码r3v3rs3! 。它似乎忽略了那些旨在打草惊蛇的误导性字符串。整个分析过程不到 12 分钟，在 68 个回合中花费了 2.56 美元。

版本 2 没有解决。流水线耗时长 3.8 倍（约 46 分钟），使用次数多 1.75 倍（119 次），成本高 3.4 倍（8.83 美元）、但未能恢复密码。它正确识别了调度表、不透明谓词和终止处理程序，并识别了噪声处理程序的使用，这表明它至少理解了混淆的高层结构。

2 版删除了 LLM 对抗第 1 版所依赖的捷径，该模型未能将分散的密码片段连接成一个连贯的算法，而是停滞在寻找比较目标上，无法反转。它返回的答案 (\x1a\xcb\x74\xaa\x1a\x8b\x31\xb8) 就是二进制比较的原始密码文本。

以下是使用原始评估系统绘制的结果：

结论

在这项研究中，我们在第一部分探索了克劳德 4.6 静态解决混淆程序逆向工程问题的能力，其难度不断增加。尽管性能令人印象深刻，但我们还是证明，程序混淆远非 LLM 所提供的自动方法所能攻克，但经典转换在今天仍然很容易被破解。在第二部分中，我们探索了三种混淆变体的迭代开发方法，这些变体完全是"vibecoded，" ，这表明，至少如果我们专注于静态分析，开发有效、快速、定制和低成本的混淆方法是完全可行的。

虽然这项研究只是蜻蜓点水，但我们可以从中窥见混淆和自动分析之间正在进行的军备竞赛。它表明，目前针对 LLM 探针开发有效反制措施的门槛很低，任何有积极性的操作员都可以在一个长周末内完成。

因此，请系好安全带：猫捉老鼠的游戏正在升级，双方都不再带着训练用的轮子玩了。