Eric S. Raymond 最近提出了一个尖锐判断：把 Windows 驱动二进制文件交给前沿大模型，模型就能生成源码，因此依赖二进制保密的产业均衡已经结束。
这个判断抓住了一个真实变化：大模型正在显著降低逆向工程的阅读成本。但“生成一份像源码的文本”和“恢复可验证、可维护、行为等价的原始源码”并不是一回事。对驱动、安全模块和硬件协议实现而言，这个区别尤其关键。
大模型真正降低了哪部分成本
传统二进制分析通常包含几个环节：识别文件格式和目标架构、反汇编、恢复控制流、推测数据结构、识别系统 API，最后才是理解业务语义。反编译器已经能处理前几步，大模型带来的主要变化，是加速最后一公里：
- 根据调用关系给函数命名；
- 把反编译器生成的低可读性代码改写成伪 C 或伪 Rust；
- 解释寄存器、位掩码和状态机可能代表什么；
- 将 Windows 内核 API 调用归纳成初始化、I/O、内存映射或中断处理流程；
- 跨多个函数整理协议和数据结构假设。
过去，工程师可能需要几个小时才能读懂一段充满临时变量和跳转的伪代码。现在模型可以在几分钟内给出第一版解释。这足以改变漏洞研究、兼容层开发和遗留系统维护的成本结构。
但模型通常不是从机器码中“取回”原始源码。它更像是在反汇编证据和训练语料先验之间，生成一份最可能的高级语言解释。
能编译，不代表行为等价
编译会丢失大量信息，包括变量名、注释、宏、类型别名、构建条件和部分模块边界。优化器还会内联函数、合并分支、删除不可达代码，并重新安排指令。因此，即使模型输出的代码能够通过编译，也不能自动证明它与原二进制等价。
驱动程序进一步放大了风险。一个看似合理的错误可能发生在：
- 中断上下文与普通线程上下文之间；
- DMA 缓冲区的所有权和生命周期上；
- 内存屏障、原子操作及锁顺序上；
- 未公开寄存器的读写时序上；
- 电源状态切换和错误恢复路径上。
大模型很容易补出“符合常见模式”的结构体字段或寄存器含义。输出读起来越自然，分析者反而越容易忘记它仍然是假设。对内核态代码而言，一处幻觉不是普通业务错误，而可能导致系统崩溃、数据损坏或权限边界失效。
所以，更准确的说法不是“闭源代码已经自动变成开源代码”，而是：二进制不再能提供过去那种高成本的语义遮蔽。保密仍然存在，但保密带来的工程门槛正在下降。
可以这样实践：先构造证据包，再让模型解释
下面是一个可复制的最小脚本。它不会反编译驱动，而是为你有权分析的二进制文件生成 SHA-256、文件大小和可打印字符串证据包。随后可以把证据包与 Ghidra、IDA、Binary Ninja 或 objdump 产生的伪代码一起交给本地模型分析。
将以下内容保存为 build_evidence.py，运行环境为 Python 3.10 或更高版本：
#!/usr/bin/env python3
import argparse
import hashlib
import re
from pathlib import Path
def printable_strings(data: bytes, min_length: int = 6) -> list[str]:
pattern = rb"[ -~]{%d,}" % min_length
return [item.decode("ascii", errors="replace") for item in re.findall(pattern, data)]
def main() -> None:
parser = argparse.ArgumentParser(description="Build a binary-analysis evidence pack")
parser.add_argument("binary", type=Path)
parser.add_argument("--limit", type=int, default=200)
args = parser.parse_args()
data = args.binary.read_bytes()
digest = hashlib.sha256(data).hexdigest()
strings = printable_strings(data)[: args.limit]
print("# Binary evidence pack")
print(f"- File: `{args.binary.name}`")
print(f"- Size: `{len(data)}` bytes")
print(f"- SHA-256: `{digest}`")
print("\n## Printable strings")
for value in strings:
print(f"- `{value.replace('`', "'")}`")
if __name__ == "__main__":
main()
对测试文件执行：
python3 build_evidence.py ./sample.sys --limit 100 > evidence.md
如果目标格式受本机 objdump 支持，还可以补充节区和反汇编信息：
objdump -x ./sample.sys > headers.txt
objdump -d ./sample.sys > disassembly.txt
不要只问模型“这个驱动做什么”。应要求它区分证据、推断和未知项。可以直接使用下面的提示词：
你正在协助分析一个我有权研究的驱动二进制。
请严格执行以下规则：
1. 只根据提供的字符串、导入表、反汇编和伪代码作答。
2. 将结论分为“直接证据”“高置信度推断”“待验证假设”。
3. 不要虚构结构体字段、寄存器含义、锁语义或硬件协议。
4. 每项推断必须引用对应函数地址、API 名称或指令片段。
5. 输出用于动态验证该假设的最小测试建议。
任务：识别初始化路径、I/O 分发路径、共享状态和潜在并发风险。
这套流程的重点不是让模型一次性“吐出源码”，而是建立可追溯分析链：每个函数名、数据类型和协议判断都要能回到二进制证据。
别把商业机密直接上传到公共模型
把第三方驱动上传到云端模型，可能同时触发许可证、商业秘密、出口管制、隐私和供应链安全问题。即便逆向工程在某些司法辖区或兼容性场景中被允许，也不代表可以把二进制交给外部服务处理。
团队采用这类工作流前，至少需要确认：
- 对目标文件拥有分析授权；
- 模型服务是否保留输入或用于训练；
- 二进制及分析结果是否允许离开受控网络；
- 许可证是否限制反编译、再分发或衍生实现；
- 是否需要使用隔离环境和本地模型；
- 最终结论是否经过动态测试、差分测试或人工审计。
“闭源已死”更像警报，而不是完成时
大模型确实削弱了“发布二进制就等于隐藏实现”的假设。它让更多开发者能够读懂反编译结果，也让漏洞研究和兼容实现变得更快。但它没有恢复被编译器删除的信息，更不能替代硬件文档、动态观测和行为验证。
对驱动厂商而言，现实建议不是继续依赖晦涩性，而是把真正的安全边界放在签名、权限、隔离、协议认证和密钥管理上。对分析者而言，则应把模型视为一名速度很快、知识面很广、但必须逐句核验的逆向助手。
二进制保密的门槛正在坍塌；可验证的软件工程并没有因此消失。