1998 年发布的《Ultima Online: The Second Age》体验版蕴含着一份珍贵的历史遗产：其附带的UoDemo.exe不仅包含游戏客户端，更 bundled 了完整服务器代码的 Windows 移植版本。这段代码直接来源于 1998 年中期生产环境的 Solaris 服务器，是理解早期 MMORPG 架构的绝佳样本。历时十年、断断续续的逆向工程工作，最终将这近 5000 个函数从 MSVC x86 机器码翻译为可移植的 C99 代码，每个函数均经过指令级比对验证。本文将深入剖析这一逆向工程实践的核心方法论与关键参数，为处理同类遗留系统提供可落地的工程参考。
反汇编工具链与符号重建
逆向工程的第一步是获取可读的反汇编代码。原二进制UoDemo.exe编译于 Microsoft Visual C++ 5.0，采用 pre-C++98 的 C++ 方言，且未附带任何调试符号。工具链的选择至关重要：项目采用 radare2 作为反汇编框架，其开源、跨平台且支持脚本化的特性使其适合处理大规模二进制分析任务。在实际操作中，反汇编并非一次性完成，而是采用迭代式方法：首先对入口点进行基本块识别，然后逐步覆盖所有代码路径，确保无遗漏函数。
符号名称的推导是另一项挑战。项目利用了一个关键突破口：UO 客户端 1.25.37 的实验性 Linux 移植版本，该版本附带了 C++ 符号信息。通过将客户端符号与服务器二进制进行交叉引用分析，可以推断出服务器端对应函数的功能名称。这种方法本质上是利用同源代码的符号信息来「照亮」目标二进制，是逆向工程中常见且有效的技巧。实践中，约 30% 的公共函数可直接通过客户端符号映射，其余 70% 需要结合代码上下文和行为分析进行推断。
类层次结构的精确重建
在二进制逆向工程中，类层次结构的重建是决定成败的基础工作。一旦类布局和继承关系出错，后续所有基于该类的分析都将产生级联错误。项目最终确定的继承链为：CEntity (0x10 字节) → CResourceEntity (0x1C 字节) → CItem (0x50 字节) → CContainer (0x5C 字节) → CMobile (0x37C 字节) → CPlayer (0x458 字节)。每个结构体的精确大小来源于对虚函数表指针和成员偏移的反复验证。
虚函数表的处理尤其值得注意。逆向工程师通过追踪虚函数调用点，反向推导每个类的 vtable 布局。例如，vtable[0x18] 对应 IsPlayer 方法，vtable[0xD0] 对应 IsMobile，vtable[0xE4] 对应 IsNPC。这些偏移值必须与机器码中的调用目标严格匹配，任何偏差都可能导致程序行为异常。在实践中，建议先锁定层次结构顶端的基类，然后逐层向下验证每个派生类的布局，这种自顶向下的策略可以有效控制复杂度。
32 位到 64 位的迁移策略
原始二进制是 32 位 x86 架构，而项目默认构建目标为 64 位系统。这一迁移并非简单的重新编译，而是涉及深刻的内存布局调整。C++ 的标准布局确保了基类子对象在派生类中位于起始位置，但指针宽度变化会导致结构体中后续成员的实际偏移发生位移。以 CMobile 继承自 CContainer 为例：在 32 位环境下，CMobile 的 CContainer 子对象起始于偏移 0x37C；若直接转换为 64 位指针并沿用原偏移值，CContainer 的成员将错位至错误位置。
项目采用的解决方案是显式结构体嵌入（struct embedding）。通过在 C 代码中精确模拟原始 C++ 继承关系，确保 CMobile 结构体内部直接包含 CContainer 作为首个成员。当 CMobile* 指针被传递给期望 CContainer* 的函数时，C 的隐式类型转换会自动调整指针值，使其指向正确的子对象位置。部分结构体还进行了人为填充（deliberate padding），以在 32 位和 64 位两种模式下同时保持与原始二进制的兼容性。这种「双模兼容」策略对于需要同时支持新旧系统的遗留项目具有重要参考价值。
客户端兼容性与加密协议处理
服务器必须同时支持从 1.25.30 到 5.0.9.1（2007 年 3 月）的所有客户端版本，时间跨度近十年。不同版本客户端的通信协议存在显著差异，尤其是加密机制经历了五次完全不同的迭代。每次加密协议的逆向都需要在客户端二进制中定位加密初始化函数，分析其算法实现，然后在服务器端重新实现对应逻辑。实践中建议按客户端版本分组处理，每组内部先解决最早期版本，再逐步向后兼容，因为后期版本往往在前期基础上增加新算法而非完全替换。
加密处理的工程参数如下：客户端版本检测应在 TCP 连接握手阶段完成，建议在首次数据包到达时根据版本号选择对应的加密状态机；加密密钥的协商过程需要精确模拟原始服务器的握手时序，超时阈值建议设置为 5 秒以兼容高延迟网络；针对无加密的旧客户端，应提供显式的加密绕过开关，但需记录日志以供审计。
验证与质量控制
项目采用了严格的验证流程来确保逆向代码与原始二进制的一致性。具体做法是：将翻译后的 C 代码重新编译为二进制，再次使用 radare2 进行反汇编，然后与原始反汇编结果进行逐指令对比。只有当两者完全匹配时，对应函数才标记为完成。这种「双向验证」机制有效防止了翻译过程中的逻辑偏差。辅助函数（helper functions）的使用受到严格限制：仅当某段代码在原二进制中以内联方式出现多次、且 helper 展开后与内联版本完全一致时，才允许引入 helper。这一约束确保了翻译结果的可验证性。
项目中还发现并修复了大量原始代码的缺陷，包括崩溃问题、整数溢出、未初始化变量使用等。这些修复均带有明确标记，保留了与原始二进制的 diff 对比能力。对于功能层面，项目恢复了原本被禁用但代码仍存在的生成系统和 decay 系统 —— 通过反编译这些孤立代码片段并重新连接调用点即可恢复功能。著名的生态系统的捕食者 / 猎物 / 食腐动物机制也得以重建，使游戏世界呈现出动态的生态模拟。
遗留系统处理的工程启示
这一逆向工程实践为处理其他遗留服务器系统提供了几点关键启示。其一，符号信息的跨二进制复用是加速逆向的有效手段，尤其是当目标系统存在同源的其他组件时；其二，类层次结构的精确重建应当优先于任何功能分析，错误的结构假设会导致后续工作全面返工；其三，跨架构迁移需要深刻理解内存布局的底层机制，简单的指针类型转换往往不足以保证正确性；其四，版本兼容性处理应当采用分层架构，将协议版本检测与业务逻辑解耦；其五，自动化验证框架是确保大规模翻译质量不可或缺的基础设施。这些原则不仅适用于游戏服务器，也适用于工业控制、金融系统等领域的遗留软件现代化改造。
资料来源：draxinar.github.io