awesome-reverse-engineering 是一个精心整理的逆向工程工具与学习资源清单，覆盖二进制、应用、固件、文件格式与协议分析。与只列名字的清单不同，它在仓库内自带四组可复现实验，分别验证 Construct（二进制格式解析）、Scapy（协议数据包构造）、YARA-X（恶意文件规则扫描）和 Vineflower（Java 反编译）四个工具，并公开了固定版本、输入哈希与独立校验逻辑，方便新手跟着复现、建立对工具行为的第一手认知。

为什么需要"可复现"的逆向工具验证

逆向工具清单最容易踩的坑是：条目只写"这个工具能做什么"，读者无法判断它在当前版本、当前平台上是否真的如此。

awesome-reverse-engineering 的做法是：

• 为部分工具编写自建小样本（fixture），而不是套用上游测试套件
• 用固定版本号锁定依赖（requirements.txt中钉死construct==2.10.70、scapy==2.8.0、yara-x==1.21.0；Vineflower 的 JAR 则用 SHA-256 校验固定为 1.12.0）
• 每个样本都有独立计算的期望结果，断言失败即整体失败
• 用 CI 定期重跑，把结果快照（版本、输入哈希、结论）公开存档

💡 对新手来说，最有价值的一点：你可以完全在离线、受控环境里复现这些实验，不碰任何真实恶意样本或网络流量。

验证环境与一键复现

四组实验都在 examples/resource-intake/README.md 中说明，当前快照环境记录在 verified.json：Linux x86_64、Python 3.11.2、javac 17.0.20.1。

仓库支持只读使用；如果需要在本地跑实验，可以克隆后按说明执行：

git clone https://gitcode.com/gh_mirrors/awe/awesome-reverse-engineering

一键复现只需三步（在仓库根目录执行）：

python3.11 -m venv venv ./venv/bin/python -m pip install -r examples/resource-intake/requirements.txt ./venv/bin/python examples/resource-intake/verify.py --output results

脚本 examples/resource-intake/verify.py 会在每次运行时先校验三个 Python 包的版本是否与钉住版本一致，通过断言后写出results.json并保留生成物。CI 侧由 .github/workflows/resource-examples.yml 工作流在 Linux + Python 3.11 + Java 17 上定期重跑并上传当前结果。

四组验证样本速览

样本一：Construct —— 先写字段假设，再让数据说话

Construct 是一个声明式 Python 库，适合逆向未知文件格式：先把"魔数在第 0 字节、长度是小端 16 位……"这类假设写成 schema，再用真实数据验证。

输入：12 字节 golden 数据534d4b310500017472616365，含义是魔数SMK1+ 小端长度5+ 类型1+ 负载trace。

验证逻辑（见 verify.py 中 schema 定义）：

1. 解析后断言length == 5、kind == 1、payload == b"trace"
2. 用字段反向build出与 golden 完全相同的字节（双向能力）
3. 三种坏数据——截断 1 字节、尾部多 1 字节、魔数改成WRNG——都必须抛出ConstructError，否则验证失败

📌 结论：这组实验证明的是"这个 schema 的假设在这台 Python 主机上成立"，而不是 Construct 支持所有二进制格式。逆向时的正确姿势正是如此——一次只验证一个字段假设。

样本二：Scapy —— 离线组包与独立校验和

Scapy 是 Python 的协议数据包框架，适合逆向协议时手工构造请求、验证字段行为。

输入：一个 Ether/IP/UDP/Raw 报文，字段全部固定：MAC 对02:00:00:00:00:01 → 02:00:00:00:00:02，IP192.0.2.1 → 192.0.2.2，UDP1234 → 4321，payload 为trace。

验证逻辑：

• 生成的线格式必须是47 字节，前 14 字节与固定的 MAC 头 hex 完全一致
• 用一个独立实现的 RFC 1071 风格校验和函数，验证 IP 头与 UDP 头（含伪首部）的校验和结果均为 0——不依赖 Scapy 自身的计算
• 再用Ether(wire)独立解析回字段值做交叉验证
• 最后写入trace.pcap并读回，确认 IP 源地址与 payload 不变

📌 注意边界：全程离线，不发送任何流量、不做实时抓包。这组实验的意义在于：Scapy 的"构建—序列化—解析—落盘—读回"链路在一个可复现的闭环里是自洽的。

样本三：YARA-X —— 正反匹配 + 一个"踩坑"演示

YARA-X 是 YARA 的 Rust 重写继任者，用规则识别和分类文件（恶意样本分型、特征检测）。

正样本：规则Fixture要求包含字符串trace，且偏移 0 处的uint16小端值等于0x4d53（即SM）。golden 字节命中该规则；对照文本negative sample不命中任何规则——正反两个结果都被断言。

负样本（踩坑演示）：在正则中写一个未转义的{，例如/abc{，YARA-X 会抛出CompileError拒绝编译。

📌 这正是迁移规则时的真实风险：YARA-X 官方文档明确列出与 YARA 在正则、模块、API上的差异。这组实验只覆盖"Python API 的正负匹配 + 这一个文档化正则差异"，不能推广为"所有 YARA 规则都能无损迁移"。清单在 docs/priority-candidates.md 中为此单独记录了迁移注意事项。

样本四：Vineflower —— 反编译产物能否重建并跑通

Vineflower 是专注现代 Java 特性、输出可读的 Java 反编译器（清单中列于 Android 与托管代码一节，运行需 Java 17+）。

样本输入（两个文件，哈希已固定）：

• BranchDemo.java：Java 17 的record Pair+ switch 表达式（0 → 11，1, 2 → 22，默认-1），main预期输出25
• Probe.java：用输入[-1, 0, 1, 2, 9]驱动同一个choose，形成五个分支向量

验证流程（完整闭环）：

javac 编译原版 → java 运行得 25 与分支向量 ↓ Vineflower 反编译为 .java 源码 ↓ javac 用反编译源码重新编译 → 再运行 ↓ 两次输出必须一致：main 打印 25，分支向量为 -1:-1 / 0:11 / 1:22 / 2:22 / 9:-1

此外，Vineflower 1.12.0 的 JAR 在执行前会做 SHA-256 校验（verified.json 中记录了期望摘要），可用--vineflower-jar提供本地 JAR，但摘要检查同样生效。

📌 这组实验回答的是新手最关心的问题之一：反编译出来的代码还能不能编译运行？对本 fixture（Java 17 record/switch 表达式）答案是肯定的；未测混淆代码或其他 Java 目标版本。

如何正确理解"验证范围"

清单在 docs/priority-candidates.md 中刻意区分了两类证据状态：

• Reproduced（已复现）：本组四份有界样本确实跑通，但只证明描述的有限场景
• Documented（已记录）：仅核对了官方文档与仓库状态，未执行验证（如 CyberChef、strace、Renode 等 19 项）

快照 verified.json 记录的时间（2026-10-13）、主机平台、Python/JDK 版本、输入文件 SHA-256、golden hex 与期望输出，都是为了让任何人在任意时间用同样的输入得到同样的结论。这正是"可复现"三字的分量所在。

给新手的三条实操建议

1. 先复现，再信任：拿到工具后，照 examples/resource-intake/README.md 跑一遍四组实验，建立对"输入固定 → 输出可断言"的直觉，再上手真实目标。
2. 把"有界"写进你的实验报告：描述工具能力时注明版本与场景（如"YARA-X 1.21.0 在本环境下通过了 Python API 正负匹配"），避免以偏概全。
3. 从清单反查工具：awesome-reverse-engineering 的 README.md 按任务组织（文件分诊、原生分析、调试、恶意分析、Web 与协议、固件与硬件、文件格式等），找到工具后再回看本组四份样本的方法论，就能快速判断哪些能力可以同样方式自行验证。

四组样本很小，但完整展示了逆向工具验证的最小闭环：钉版本 → 给输入 → 独立算期望 → 断言结果 → 留痕。把这套方法迁移到自己的逆向工作上，工具选型会踏实很多。