💻 computer science

Erlang Binary and Source Code Obfuscation

该论文研究了针对 Erlang 程序在源代码、抽象语法树、BEAM 汇编及字节码层面的多种混淆技术，旨在通过利用高级语义与底层执行模型之间的表达差异来增加逆向工程难度，同时确保代码在编译器、验证器及虚拟机中的正常运行。

原作者： Gregory Morse, Tamás Kozsik

发布于 2026-04-16

📖 1 分钟阅读☕ 轻松阅读

原作者： Gregory Morse, Tamás Kozsik

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文就像是在讲如何给 Erlang 程序（一种用于构建高可靠性系统的编程语言）穿上“隐身衣”或“变形金刚战甲”，让想要破解、分析或修改它的人（逆向工程师）感到头大，甚至放弃。

作者并不是通过把代码变成乱码来混淆视听，而是利用了 Erlang 编译器、验证器和虚拟机（BEAM）之间存在的**“认知温差”**。

我们可以把整个过程想象成**“在严格的交通法规下，驾驶一辆能变形的赛车”**。

1. 核心概念：规则的缝隙

想象 Erlang 的编译器是一个极其严格的交警（Validator），它负责检查你的车（代码）是否符合交规。如果不符合，它绝对不会让你上路。
但是，交警虽然严格，他只能看到你提交给他的图纸（源代码或中间代码），而看不到你实际上是怎么开车的（虚拟机运行时的真实行为）。

这篇论文的核心发现就是：只要你的车在交警眼里是合法的，但在实际驾驶中，你可以利用一些交警没想到的“物理漏洞”来做出一些极其诡异、难以预测的驾驶动作。

2. 五大“隐身”战术（通俗版）

战术一：利用“寄存器”的假象（Custom Register Usage）

比喻：想象你的车仪表盘上有一个专门的“速度显示灯”（寄存器 x0），交警规定只有这个灯亮着才算正常。
操作：作者发现，虽然交警规定必须用 x0，但如果你偷偷把数据藏在 x2 里，只要最后把 x2 的值“假装”成 x0 传出去，交警就看不出来。
效果：逆向工程师看着代码，以为数据在 x0，结果实际运行时数据在 x2 里乱跑。这就像你给车贴了个假车牌，交警检查时没问题，但警察（逆向工具）想追踪你时，发现车牌号对不上，彻底迷路。

战术二：用“收信”来伪装“循环”（Loops via Receive）

比喻：通常，循环就像是在跑道上跑步，一圈圈转。但在 Erlang 里，你可以用“收信”（Receive）机制来模拟跑步。
操作：想象你不再直接跑圈，而是每跑一步，就给自己发一封信，然后停下来等信。收到信后，再决定下一步是继续跑还是停下来。
效果：在逆向工程师眼里，这看起来不像是一个循环，而像是一堆杂乱无章的“收信 - 处理 - 再收信”的碎片。这就好比把一条直线跑道，伪装成了无数个需要不断等待快递的驿站，让人根本看不出你其实是在绕圈跑。

战术三：制造“迷宫般的控制流”（Irregular Control-Flow）

比喻：正常的代码像是一个结构清晰的迷宫，有入口有出口。
操作：作者利用 Erlang 的异常处理（Try/Catch）和消息接收机制，制造出一些**“多入口、多出口”**的复杂路口。
效果：逆向工具通常假设代码是规整的（比如一个函数只有一个入口）。但作者把代码变成了“九曲十八弯”，从一个点可以跳到十个不同的地方，从十个地方也能跳回这里。这就像把迷宫的墙壁打通，让侦探（逆向工具）在分析路径时彻底晕头转向，无法还原出原本的逻辑结构。

战术四：利用“可变元组”进行性能伪装（Efficiency via Mutability）

比喻：Erlang 的默认规则是“数据不可变”（Immutable），就像你写下的字不能擦除重写，只能写新的一页。
操作：作者利用底层指令，强行让某些数据块（元组）变得可以“擦除重写”。这就像在一张不可擦写的纸上，偷偷用一种特殊的墨水，让字看起来没变，但实际上内容已经改了。
效果：
- 对黑客：如果你把这段代码反编译回源代码，你会发现它写得非常笨拙、低效（因为反编译器不知道底层可以“原地修改”）。
- 对原作者：实际运行时，它快得像闪电。
- 结果：黑客虽然看懂了逻辑，但一旦试图重新编译运行，程序就会变得慢如蜗牛，根本没法用。这就好比给了你一张藏宝图，但上面的路标是反的，你照着走只会走进死胡同。

战术五：自我修改的代码（Self-Modifying Code）

比喻：通常程序是印在纸上的，印好就不能改了。但 Erlang 允许“热更新”，就像一本活页书，可以在阅读时随时撕掉一页，换上一张新写的纸。
操作：程序运行时，会自己修改自己的源代码，重新编译，然后继续运行。
效果：当你拿到这个程序时，它是一副样子；等你分析完，它已经变成了另一副样子。这就像你正在看一本侦探小说，每翻一页，作者就在后台把下一页的内容重写了一遍。你永远无法抓住它“真实”的样子。

3. 总结：为什么这很重要？

这篇论文告诉我们，真正的安全（或真正的混淆）不在于把代码藏得有多深，而在于利用工具之间的“信息差”。

对于逆向工程师：如果你只盯着源代码看，或者只盯着简单的字节码看，你会被耍得团团转。你必须理解 Erlang 虚拟机（BEAM）到底是怎么“思考”和“执行”的，才能看穿这些伪装。
对于保护者：最好的保护不是把代码锁起来，而是利用语言本身的特性，设计出一些**“合法但反直觉”**的结构。

一句话总结：
这就好比在严格的交通规则下，作者发明了一种**“合法但极其反常”的驾驶方式**。交警（编译器）觉得你完全合规，但路过的侦探（逆向工具）看着你的行车轨迹，完全猜不出你到底要去哪，甚至以为你在原地打转。这就是 Erlang 代码混淆的精髓。

这篇论文《Erlang Binary and Source Code Obfuscation》（Erlang 二进制与源代码混淆）由 Gregory Morse 和 Tamás Kozsik 撰写，深入探讨了针对 Erlang 程序的混淆技术。文章不仅关注源代码层面，更重点分析了 BEAM 字节码（Erlang 虚拟机指令集）层面的混淆策略，揭示了如何利用 Erlang 工具链、验证器（Validator）和运行时系统（VM）之间的语义间隙来构建难以逆向工程、反编译和重新编译的代码。

以下是该论文的详细技术总结：

1. 研究问题 (Problem)

核心挑战：现有的软件保护研究多集中在 C/C++ 或 Java 等语言，针对 Erlang/BEAM 生态系统的混淆技术研究较少。
逆向工程的痛点：逆向工程师的目标通常是理解、修改并重编译代码。现有的反编译器（Decompiler）通常假设代码结构是规范的（如单入口/单出口的控制流、标准的类型系统），而 Erlang 的 BEAM 字节码允许一些在高级源代码中无法直接表达、但在虚拟机层面合法的结构。
验证器的限制：Erlang 编译器包含严格的验证器（BEAM Validator），用于检查未初始化变量、堆分配等问题。这使得直接生成非法字节码变得困难，但同时也留下了“合法但误导”的操纵空间。

2. 方法论 (Methodology)

作者采用了一种分层分析方法，研究了从源代码到 BEAM 字节码的整个转换链条，并识别出其中的“表示间隙”（Representational Gaps）：

转换边界分析：分析了 Erlang 源代码、抽象语法树（AST）、BEAM 汇编（.S 文件）和 BEAM 字节码（.beam 文件）之间的转换过程。指出某些转换（如从 .S 文件回退到 AST）需要特殊的内部函数或重新编译编译器模块。
利用验证器与执行器的差异：研究 BEAM 验证器（Validator）与虚拟机执行器（Loader/VM）之间的假设差异。验证器基于静态分析，而 VM 执行基于指令流。作者发现可以通过操纵寄存器状态、利用未定义行为（但在特定 VM 实现中有效）或绕过验证器的死代码检测来注入混淆逻辑。
动态与静态结合：结合静态字节码修改（Binary Patching）和动态模块加载（Hot-swapping）技术，实现自修改代码。

3. 关键贡献与主要技术 (Key Contributions & Techniques)

论文将混淆技术分为以下几类：

A. 字节码层面的指令依赖与结构操纵

操作码序列依赖 (Opcode Sequence Dependencies)：
- 利用二进制（Binary）和元组（Tuple）初始化的指令序列（如 bs_init2, put_tuple）。
- 技巧：通过动态计算大小或插入无关指令，破坏反编译器对数据加载指令数量的静态推断，导致反编译后的控制流图（CFG）混乱。
基于 receive 的循环编码 (Receive-based Loop Encodings)：
- 利用 Erlang 的消息传递机制构建非标准的循环结构。
- 技巧：使用 loop_rec、wait、wait_timeout 等指令，结合进程邮箱（Mailbox）状态和唯一标识符，构建多入口、多出口甚至不可约（Irreducible）的循环。这违反了大多数反编译器对递归或迭代结构的假设。
不规则控制流构造 (Irregular Control-Flow Constructions)：
- 构建多对一（Many-to-one）、一对多（One-to-many）甚至多对多（Many-to-many）的控制流边。
- 技巧：利用 try/catch 和 receive 语句的异常处理机制，结合可变数据（如进程减少计数器 reductions）作为跳转条件，创建复杂的控制流图，迫使反编译器进行大量的代码复制（Code Duplication）或引入复杂的条件判断。
寄存器与栈的“未初始化”利用：
- 利用 BEAM 验证器对寄存器存活性（Liveness）的静态检查与 VM 实际执行之间的差异。
- 技巧：故意使用未初始化变量（在 VM 中通常表现为空列表 [] 或 nil），通过二进制补丁（Binary Patching）修改字节码中的寄存器索引（例如将 x0 改为 x2），从而绕过验证器但保持运行时行为一致。

B. 性能导向的混淆 (Performance-oriented Obfuscation)

可变元组 (Mutable Tuples)：
- 利用 BEAM 指令 set_tuple_element（通常被编译器禁止，除非有特定的 erlang:setelement 调用）。
- 技巧：通过动态加载模块或修改编译器源码来绕过验证，允许直接修改元组元素。
- 效果：在 BEAM 字节码中，元组读写是 $O(1)$ 的；但在反编译并重编译为高级 Erlang 代码时，由于 Erlang 的不可变性，必须复制整个元组，导致性能从 $O(1)$ 退化为 $O(n)$ 。这使得重编译后的代码在性能上完全不可用，从而保护了算法逻辑。

C. 自修改代码 (Self-Modifying Code)

动态重载：利用 Erlang 的热替换（Hot-swapping）特性。
技巧：函数在运行时读取自身的源代码字符串，修改 AST 或字节码，然后动态重新编译并加载自身。
效果：代码在磁盘上的静态表示与内存中的执行表示不一致，使得静态分析工具失效。

4. 结果与发现 (Results)

验证器并非绝对防线：虽然 BEAM 验证器能阻止明显的错误，但通过精心构造的指令序列和二进制补丁，可以生成“合法”但具有误导性的字节码。
反编译器的脆弱性：现有的反编译器在处理非标准控制流（如基于 receive 的循环）和可变数据结构时表现不佳，往往无法还原出可读的源代码，或者还原出的代码性能极差。
性能退化作为保护：通过利用 BEAM 底层优化（如直接修改元组），可以制造出“语义正确但性能灾难”的反编译版本，这是一种有效的保护手段。

5. 意义与影响 (Significance)

对逆向工程的启示：要构建一个可靠的 Erlang 反编译器，不能仅关注语法还原，必须深入理解 BEAM 验证器的约束、加载器的行为、消息传递模型以及虚拟机的执行语义。
对软件保护的启示：最有效的混淆往往不是随机破坏代码，而是利用高级语言语义与底层执行模型之间的“间隙”。Erlang 的分布式、热替换和进程模型为这种混淆提供了独特的土壤。
安全性评估：该研究揭示了 BEAM 生态系统比表面看起来具有更丰富的对抗面（Adversarial Surface），提示开发者在构建高安全性的 Erlang 系统时需警惕这些底层攻击向量。

总结：
这篇论文通过深入剖析 Erlang 编译器和虚拟机的内部机制，展示了一系列高级混淆技术。它证明了在 BEAM 字节码层面，通过操纵控制流、利用验证器漏洞以及结合动态代码加载，可以构建出极难逆向工程且难以重编译的程序。这不仅为软件保护提供了新思路，也为改进 Erlang 反编译工具提出了明确的挑战和要求。