84天逆向还原任天堂64游戏:Snowboard Kids反编译项目深度揭秘
了解Snowboard Kids如何在短短84天内完成100%反编译,探索AI工具链、IDO编译器特性与社区协作如何重塑经典游戏逆向工程的速度与边界。
在复古游戏保护与研究的版图上,反编译一直是一项门槛极高、耗时漫长的工程。然而,2026年夏季,一个名为Snowboard Kids的项目以84天的惊人速度完成了对原版任天堂64游戏的100%反编译,这意味着游戏中的每一个函数都拥有了能够编译出与原版完全一致机器码的C语言实现。这不仅是一项技术成就,更代表着AI辅助逆向工程、工具链迭代与社区协作在当下所能达到的全新高度。 这项工作的核心动机源于Speedrunning社区与mod制作者的长期需求。长期以来,Speedrunners对Snowboard Kids初代投入了大量精力,但缺乏源码使得外部观察到的现象,例如角色CPU路径选择、玩家速度的影响因子等,难以被系统性地解释与优化。拥有可编译的C源码,意味着研究者能够精确分析每一处逻辑对游戏行为的影响,同时为静态重编译与未来更宏大的mod项目奠定基础。
与续作Snowboard Kids 2相比,初代项目的完成速度令人震撼。前作耗时596天,而初代仅用84天,速度提升至原来的七倍。这种差距并非单纯归功于AI。Snowboard Kids的反编译作者在续作中已经积累了将近两年的实战经验,这种领域直觉的提升很难量化,但也伴随着新的挑战,例如初代使用了不同的编译器 - - IDO 5.3,而非续作所用的GCC 2.7.2。 IDO编译器对于大多数现代程序员而言是陌生的。它是SGI开发的专有编译器,与任天堂64的历史紧密交织。
任天堂在设计N64时采用了源自SGI的架构,而其开发环境同样以SGI Indy工作站为核心,IDO就是被官方支持的编译器之一。如今,IDO的源码早已不可获取,其原始开发环境依赖于已经过时的SGI硬件与软件。为了在现代硬件上运行并正确理解IDO的行为,反编译社区不得不逆向工程并反编译编译器工具链本身,甚至对IDO 5.3和7.1进行了静态重编译。 IDO的编译过程与GCC截然不同。它将优化与代码生成分散在多个阶段,代码在传递过程中会被激进地变换。微小的C源码改动可能在多个阶段引发连锁反应,最终导致寄存器分配的全面改变。
这种特性使得反编译工作具有高度不可预测性。对于人和AI而言,核心难点往往不在于理解函数的功能,而在于如何用C表达这种逻辑,以及编译器会如何处理这种表达。 尽管社区在理解IDO方面取得了长足进步,但这仍然更像是一门艺术而非科学。在工作流程上,作者和AI代理通常首先确定函数的功能,然后编写能够近似实现该目的的C代码。接下来,借助permuter等工具进行微调以捕获剩余的差异。然而,当底层结构存在根本性错误时,permuter也无能为力。
这种工作流的不可预测性是IDO带来的最大挑战之一。 值得注意的是,一支拥有合适专业知识和直觉的人类团队,在速度上完全可以匹配甚至超越Snowboard Kids的反编译进度。Pilotwings 64的反编译仅用74天便告完成。尽管Pilotwings 64的函数数量比Snowboard Kids少16%,但其编译代码总量更大,因此两者并非完全可比的案例。Snowboard Kids本身比续作更小,包含2145个函数,而续作有2995个,函数数量虽是衡量难度的粗略指标,但确实反映了工作量上的差异。 在AI代理真正发挥作用的领域,库代码的匹配是早期阶段的一大亮点。
从理论上讲,标准库代码是任何N64反编译项目中最显而易见的部分,因为这些代码并非游戏独有,互联网上存在大量可参考的版本。Snowboard Kids包含超过一百段源自任天堂libultra的代码段,以及libmus音频库的函数。工具如N64Sym能够识别ROM中可能的库函数。 这一阶段的成功主要面临一个障碍:说服AI代理依赖现有的库源码,而非从头开始重新反编译相同函数。这需要更加强力的提示工程。一旦识别出可能的库函数,代理会被指示将对应源码作为起点,在尝试自行实现之前穷尽合理的SDK版本、编译器选项与条件编译路径。
这种策略显著提升了效率。 另一个优化是让代理编写脚本,对所有未匹配的函数运行m2c,并自动集成任何精确匹配,而不是依赖代理逐个尝试这些函数。虽然该脚本在1830个函数中仅匹配了17个,成功率低至0.93%,但通过这种方式匹配的任何函数都比燃烧代理token来得便宜。 IDO虽然怪异,但其怪异之处往往以重复模式出现。成功匹配一个函数可能揭示出适用于许多其他函数的编译器特性。Codex通过本地记忆等功能在任务之间携带经验的能力正在提升。
为了使这些经验对所有代理都可用,作者提示代理将观察到的IDO行为记录在DECOMPILATION_LEARNINGS.md文件中。当代理发现可泛化的编译器特性时,可以将证据记录在那里供后续尝试参考。这形成了一个有用的反馈循环:代理帮助记录IDO,而这些记录又使后续代理在匹配IDO代码时更加高效。 但最实用的资源是N64 Decomp Workbench,这是一套用于调试后期MIPS反编译不匹配的工具与文档集合。它能够对不匹配进行分类,处理重定位,重放单个编译器阶段,并帮助区分结构性问题与寄存器分配问题。阶段重放功能需要相关的编译器二进制文件和项目特定设置,但一旦配置完成,它所暴露的信息是原始汇编差异无法提供的。
原始差异只能告诉你两个函数不同,而Workbench能够让代理更深入地理解函数差异的原因,以及何种改动可能修复差异。 在工作组织方面,作者在四个Git worktree上并行运行反编译工具。每个worktree为代理提供独立的代码库副本,使得多个函数可以同时被尝试。一个小而有用的改进是为每个任务设定明确的截止时间,并将其暴露给代理。在Snowboard Kids 2项目中,代理经常难以有效使用permuter,因为它会持续运行直到找到100%匹配或被手动停止。明确的截止时间使代理能够设置合理的超时,在permuter时间与其他问题解决方法之间进行权衡。
根据经验,这也帮助代理判断在放弃困难函数之前应该坚持多久。作者可以根据简单函数的消失和剩余工作的难度增加,动态调整时间配额。 随着worktree的增加,同步问题变得愈发突出。每个代理被分配一个待反编译函数以及一组已经匹配的相似函数作为参考。这些参考对于复现特定的IDO指令模式非常有用。工作通过Nigel的--shard选项在worktree之间分配,该选项使用基本哈希在指定数量的worker之间划分候选项。
这允许更多工作并行进行而不会重复,但也引入了worktree发散时的新问题。例如,一个worktree可能成功反编译了一个与其他worktree正在尝试的函数99%相似的函数,但这一新参考在其他代理合并更改之前是不可见的。定期将所有内容合并到主分支并重新同步worktree可以解决这个问题,但同步全部四个worktree可能需要一个多小时。持续同步会浪费时间,而等待太久则会增加漂移。 为了降低同步的紧迫性,作者更新了相似性搜索以检查每个worktree。新匹配的函数可以立即成为另一个代理的参考,而无需等待它到达主分支。
工具会产生诸如某候选函数已被修复之类的消息,其中包含来自不同worktree的参考函数。这帮助流程在简单函数消失后保持高效。同步仍然是整合和推送更改所必需的,但对于代理之间相互学习而言已不再是必要条件。 在模型选择上,作者测试了GPT-5.5和5.6、Claude 4.5和Fable,以及GLM 5.2。这完全是非科学的,模型是在不断变化的困难函数集上进行测试的,有时甚至是在另一个模型已经取得部分进展之后。总体而言,Codex延续了其在上一项目末期对Claude的优势。
Sol xhigh在可用后表现特别出色。 相比之下,GLM 5.2由z.ai提供,表现令人失望。作者曾是GLM的忠实粉丝,它即使不是前沿模型也相当有效,其慷慨的使用限制弥补了能力差距。随着限制变得不再慷慨而延迟依然糟糕,这种权衡的吸引力大大降低。反馈周期太长,以至于作者最终停止给它分配工作并取消了订阅。 100%匹配意味着每个函数都有对应的C代码,但这并不意味着我们理解每个函数的功能。
项目仍有许多清理和文档化工作要做。生成名称需要替换,未知结构字段需要识别,尴尬的匹配需要清理,大量数据需要描述。目前的优先事项是更好地记录游戏。 与此同时,Snowboard Kids的重编译工作正在进行。幸运的是,初代游戏与续作Snowboard Kids 2: Recompiled中通过补丁解决的许多特性相同,这为重编译工作提供了便利。作者还在研究将初代的关卡和其他内容移植到续作引擎中,尽管尚不清楚这将涉及多少工作。
更长远来看,作者对反编译PlayStation版的Snowboard Kids Plus很感兴趣,这是初代游戏的日本独占扩展版本,包含额外的关卡和角色。对于任何对反编译和Snowboard Kids感兴趣的人来说,反编译项目中仍然有大量清理和文档化工作要做,欢迎贡献。这项84天的壮举不仅是对AI工具能力的展示,更是对社区协作力量、工具链迭代速度以及复古游戏保护未来可能性的生动诠释。 。
