现场笔记

这是记事本截图，当时我靠它把脑子里想的东西和看到的数据记录下来

  1. 用 Garbro 解包游戏脚本，没有找到文本，或者类似 lzss 压缩后的文本痕迹
  2. 用 x32dbg 附加游戏，根据游戏显示的文本，搜索到对应内存

  3. 发现每次游戏打开时，游戏文本的内存位置是随机的 ⇒ 卡住

    • 提出一个猜测：游戏是载入一个子文件，然后子文件随机解压解密到一个 new 出来的位置
    • hook 游戏的 createFile 和 readFile 等 API
    • 简单实验，发现游戏在点击 newGame 后内存没有文本，在选择第一个人物后内存才有文本
  4. 用 Api Monitor 附加游戏进程，在选择第一个人物前监听，文本正式展示后得到一堆对应的 log
  5. 观察这些 log，发现是规律性地 setFilePointer + readFile，没有 createFile，可以读出是在某个大文件上各个位置读取不同大小的字节区间载入内存
  6. 跟 EVE1.dat 作比较，可以确定就是在 EVE1.dat 上读东西，从 EVE1.dat 中拆出子文件
  7. 回到 x32dbg，在 readFile 上下断点，发现 log 里第一段 readFile 之后，第二段 readFile 之前游戏里就有目标文本内存，确定第一段 readFile 对应拆出的第一个子文件就是关键文件，是目标文本的压缩/加密形式
  8. x32dbg 在 readFile 找到载入原文件内容的地址，在原文件内存里找两个位置下硬件断点，逐步跟进发现游戏是对原文件每 2 个字节 NOT 之后写入，写入结果刚好是目标文本
  9. 回到 010 Editor，对拆出的子文件做一次 HEX 的取反操作，得到目标文本 ⇒ DONE


可能改进

现在想想，我在整个过程中还有一些可能的策略

比如说，我知道 fall asleep 是目标文本内存的一部分，我知道一个子文件它最终会解密出目标文本。那么，可以猜测它就是用简单的异或加密

对 fall asleep 的字节，分别用 01-FF 异或 255 次，得到 255 组字节。然后用这 255 组字节在子文件里扫描，在所有子文件里扫描，在整个包文件 DAT 里扫描，只要扫到了，就可以说明这文件大概率是异或加密，并且找到密钥

比如，老外给出的 Windows SCO.zip 压缩包里有很多 sco 文件，可以写一个脚本，加密 fall asleep 并逐文件扫描