Claude 五分钟修复 1991 年 DOS 游戏 Bug：AI 逆向工程实录

一位 Reddit 用户分享了一则让他"笑到合不拢嘴"的小故事：他从 Facebook Marketplace 淘来一台奔腾 75 的老机器，一方面用来读取十几张 5.25 英寸软盘做数据归档，另一方面满足自己对复古游戏的执念。然而当他想让儿子体验自己童年挚爱的 DOS 游戏时，却撞上了一个顽固的死机问题——最终是 Claude 在五分钟内逆向反汇编并打了一个 3 字节补丁，彻底解决了问题。

一台奔腾 75 与一个三十年前的 Bug

这位用户购入老式 PC 的初衷很实际：磁性介质能稳定保存三十年数据本身就值得庆祝，而一台真正的"时代原装机"既能读软盘又能跑老游戏，一举两得。过去一周，他沉浸在 CRT 显示器的"啪"声、机械硬盘的嗡鸣、软驱读写的蜂鸣之中——这些质感是 DOSBox 模拟器永远给不了的。

他想重温的游戏是 The Learning Company 出品的《Operation Neptune》。两天前第一次运行时，游戏在 VGA 画面加 AdLib 音效中正常启动了大约 30 秒。可当他真正准备让孩子上手时，游戏却怎么也跑不起来：每次尝试都导致整机冻结，只能 Ctrl+Alt+Del 重启。

他几乎试遍了所有常规手段——重新传输文件、更换 FreeDOS 启动配置、反复核对 BIOS 设置、确认其他程序和声音功能都正常。全部无果。这是一个典型的"玄学故障"：同样的文件，两天前能跑，今天就死机。

Claude 如何在五分钟内定位根因

走投无路之下，他把游戏的原始二进制文件连同问题描述一起丢给了 Claude。结果令他震惊：AI 在五分钟内反汇编了 EXE、追踪了执行路径、定位了最可能的根因，并对一份新的 EXE 副本打上了 3 字节补丁——复制到老机器上一次运行成功。

Claude 给出的诊断相当专业。游戏的声音库按固定顺序探测设备：Roland MT-32（经由 MPU-401 MIDI 端口）→ AdLib → Tandy/PS1 → PC 扬声器。它会向 330h 端口发送 reset 指令，等待标准的 FEh "OK" 应答来判断是否存在 MPU-401。

关键在于：这个检测环节有超时机制，但后续真正发送命令的例程没有。游戏播放音符时使用了 D7h 指令，这条指令只存在于原版 Roland MPU-401 的"智能模式"（intelligent mode）中。而大多数声卡的 MIDI 端口（Sound Blaster 16、各种克隆卡、许多现代复古卡）都是 UART-only 模式——它们会响应 reset，于是游戏误判为检测到了 Roland 设备，但它们永远不会确认 D7h 指令。结果游戏陷入一个没有超时保护的紧密循环，无限等待，整机锁死。

MPU-401 是 Roland 于 1984 年推出的 MIDI 处理单元接口标准，工作于 I/O 端口 330h/331h。它有两种工作模式：**智能模式（Intelligent Mode）**下，MPU-401 内置处理器负责 MIDI 定时、节拍同步等复杂任务，主机只需发送高层指令（如 D7h 代表"停止"）；UART 模式下，MPU-401 退化为透传接口，直接转发原始 MIDI 字节，不理解任何智能模式指令。DOS 时代大量游戏为兼容 Roland 音源而专门调用智能模式指令，而后来 Sound Blaster 等声卡内置的 MIDI 端口为节省成本普遍只实现 UART 模式。这一"假兼容"问题在当年便已困扰过许多玩家，社区后来开发的 SoftMPU 等 TSR 驻留程序，本质上就是用软件在 UART 模式之上模拟智能模式指令集，以修复此类兼容性缺陷。

为什么两天前能跑？

Claude 对"两天前为何正常"也给出了诚实而严谨的推测，而非武断下结论。它列举了几种可能：当时声卡处于不同的模式或配置、加载了类似 SoftMPU 的 TSR 驻留程序、或者 MPU 当时被禁用了。它还主动反问：那台机器里装的是什么声卡？并补充道，用户"童年记忆里的 90 年代家用 PC 配 Sound Blaster 16"的场景，恰恰会导致这种死机现象——这个判断与故障症状高度吻合。

这种"我不能百分百确定，但以下几种情况都合理"的表达，反而体现了诊断的可信度。它没有为了显得全知而编造单一答案，而是基于硬件行为给出了概率排序。

3 字节补丁背后的技术含量

最终的解决方案优雅得令人意外。Claude 生成了 ON_NOMPU.EXE，只修改了 3 个字节：文件偏移 0x1FB06 处，将 BA 31 03 改为 EB 18 90。这个改动让 MPU 检测逻辑直接跳转到"未找到"的出口，游戏从此不再触碰 330h 端口，转而自动选择 AdLib 音效。

从汇编角度看，BA 31 03 是将 0331h（即 331h，MPU 数据/状态端口区域）装入寄存器的指令，而 EB 18 是一条短跳转，90 是 NOP 填充——相当于用一条无条件跳转绕过了整段有问题的探测代码。短短三个字节，既没有破坏文件结构，也精准规避了死循环的触发条件。

这类工作在过去属于资深逆向工程师的领域：需要熟悉 x86 实模式汇编、DOS 时代的声卡 I/O 端口约定、MPU-401 的 intelligent/UART 模式差异，以及如何在不重新编译的前提下做二进制热补丁。而现在，一次对话加一份二进制文件就完成了。

x86 实模式（Real Mode）是 8086/8088 处理器的原生工作模式，DOS 程序几乎全部运行于此。在实模式下，CPU 通过 IN/OUT 指令直接读写硬件 I/O 端口，没有现代操作系统的驱动抽象层隔离。这意味着程序可以无限制地轮询某个端口等待响应——也正是这种"裸机编程"习惯，使得缺少超时保护的端口轮询循环足以锁死整台机器。二进制热补丁（binary patching）是在不拥有源代码、不重新编译的前提下，直接修改可执行文件中特定偏移处的机器码字节，是逆向工程和软件保育中的基础技术手段。EB（短跳转 JMP short）配合 90（NOP，空操作）是此类补丁中最常见的组合：跳转绕过问题代码段，NOP 填充保持字节对齐，既不破坏后续代码的相对地址计算，又能精准切断有问题的执行路径。

小故事里的大信号

发帖者自己也说，这件事"比不上有人用 AI 发现新行星"，但它恰恰揭示了大模型在实际工程场景中的价值：不是取代专家，而是把原本需要数小时甚至数天的专业调试压缩到几分钟，并让非专业用户也能触及。

对复古计算、老游戏保育、数据归档这类长尾领域来说，这种能力尤为珍贵——这些软件早已停止维护，源代码往往丢失，社区人力有限。AI 能直接在二进制层面理解、诊断并修复，意味着大量濒临"失传"的数字遗产有了被救回的可能。

当然，也要保持清醒：Claude 的诊断本身包含推测成分，3 字节补丁能一次成功既有 AI 分析的功劳，也有运气和问题相对清晰的因素。但无论如何，这个发生在一台奔腾 75 上的小插曲，是 AI 辅助逆向工程落地的一个生动注脚。