如何解析并修改宝可梦Row文件结构？

Question

在逆向分析宝可梦系列游戏的ROM时，开发者常需解析和修改“Row文件”结构（如PKX、PC保存数据等行记录格式）。一个常见技术难题是：如何准确识别并解析Row数据中的加密标志位与个体值（IVs）、性格、特性等字段的位偏移？由于不同世代（如Gen 6 vs Gen 8）采用不同的存储布局和加密方式（如PID与SID/XOR校验），直接修改可能导致数据校验失败或读取异常。此外，缺乏官方文档使得结构推断依赖于内存dump与交叉比对。因此，如何在不解密破坏完整性前提下，安全定位并修改关键属性（如将某宝可梦改为异色），成为实际操作中的核心挑战。

Answer 1

逆向分析宝可梦ROM中Row文件结构的技术路径与实践策略

1. 背景与挑战概述

在逆向工程任天堂宝可梦系列游戏（如《精灵宝可梦 X/Y》《剑/盾》《朱/紫》）的ROM过程中，开发者常需解析以“Row”形式组织的数据结构，例如PKX格式（代表单个宝可梦数据）或PC Box保存记录。这类数据通常以紧凑的二进制格式存储，每条记录长度固定（如Gen 6为28字节，Gen 8为32字节），包含加密状态、个体值（IVs）、性格、特性、性别、异色标志等关键属性。

由于任天堂未公开这些结构的官方文档，开发者必须依赖动态调试、内存dump、交叉比对合法存档与修改后数据等方式进行逆向推断。不同世代间结构差异显著：

• Gen 5及以前：使用简单的PID/SID XOR校验机制
• Gen 6-7：引入Checksum校验（位于0x1C偏移）
• Gen 8+：采用更复杂的加密标识位与数据完整性验证（如IsEncrypted标志）

2. Row结构字段识别方法论

准确识别字段的位偏移是解析的第一步。以下是系统性识别流程：

1. 提取多个已知属性的宝可梦实例（如通过游戏内合法捕捉并导出）
2. 执行差分分析：对比仅一个属性不同的两个PKX样本（如仅HP IV变化）
3. 定位变化位段，结合位域知识推测其位置与编码方式
4. 使用IDA Pro或Ghidra反汇编游戏代码，追踪ReadPokemonFromSave类函数调用逻辑
5. 结合符号信息（若存在）与字符串引用（如"TrainerID", "Personality")辅助定位

3. 加密机制与校验保护分析

宝可梦数据普遍采用双重保护机制：

世代	PID生成方式	加密启用条件	校验类型	关键偏移
Gen 6	RNG-based PID	IsEncrypted bit (bit 0 of 0x17)	16-bit Checksum @ 0x1C	0x1A–0x1B (Stats)
Gen 7	Same as Gen 6	Same	Checksum + OT Name Hash	0x1D (Ability)
Gen 8	Encryption Flag in 0x1E	Bit 0 of byte at 0x1E	XOR with Trainer Data	0x20 (Markings)
Gen 9	Enhanced RNG + Seed	Per-save encryption key	SHA-1-like MAC?	0x21 (Form)

4. 安全修改异色属性的实现路径

将某只宝可梦改为异色（Shiny），需操作其Personality ID（PID）中的低16位与高16位满足特定异或关系（Shiny Value = (TID ⊕ SID ⊕ PID_high ⊕ PID_low) & 0xF ≤ 7）。

但直接修改PID会导致Checksum失效或加密状态异常。正确步骤如下：

def make_shiny_safely(pkx_data, trainer_tid, trainer_sid):
    # 假设pkx_data为bytearray，长度32（Gen 8）
    pid_low = int.from_bytes(pkx_data[0:2], 'little')
    pid_high = int.from_bytes(pkx_data[2:4], 'little')
    
    current_shiny_val = (trainer_tid ^ trainer_sid ^ pid_high ^ pid_low) & 0xF
    if current_shiny_val <= 7:
        return pkx_data  # 已为异色

    # 修改PID_low以满足shiny条件
    target_pid_low = (trainer_tid ^ trainer_sid ^ pid_high ^ 0x0) & 0xFFFF
    pkx_data[0:2] = target_pid_low.to_bytes(2, 'little')

    # 重新计算Checksum（假设位于0x1C）
    checksum = sum(pkx_data[0x0:0x1C]) & 0xFFFF
    pkx_data[0x1C:0x1E] = checksum.to_bytes(2, 'little')

    return pkx_data
    

5. 动态调试与自动化分析工具链

为提升效率，建议构建如下分析流水线：

graph TD A[Dump Save File] --> B[Extract PKX Rows] B --> C[Cluster by Species & Level] C --> D[Differential Bit Analysis] D --> E[Generate Hypothesis Map] E --> F[Validate via Emulator Memory Watch] F --> G[Apply Safe Mutation] G --> H[Repack & Test In-Game]

6. 实践中的常见陷阱与规避策略

• 忽略加密状态：若IsEncrypted标志为1，则不能直接修改明文字段
• Checksum未更新：修改任何前28字节内容后必须重算校验和
• 跨世代误用偏移：Gen 7的Ability位于0x1D，而Gen 8在0x1E
• 性格值越界：25个合法性格值（0–24），超出将导致崩溃
• 异色修改破坏PID用途：PID还影响性别、特性、动画等，需整体评估
• 未处理OT信息绑定：部分校验依赖训练家名称哈希
• 大端/小端混淆：PID存储为little-endian，解析时需注意
• 未保留原始加密种子：Gen 9可能使用保存文件级密钥
• 过度依赖社区文档：部分Wiki信息过时或错误
• 缺乏版本指纹识别：同一世代不同补丁版本结构可能微调