检查 Process Monitor 日志中的事件

Process Monitor 会记录关于事件的每一个可能的数据点，让你了解这些事件的细节远不止它们作用的文件。仔细检查「结果」和「详细信息」等数据丰富的列，可以得出一些非常有趣的信息。

例如，我发现游戏有时会直接从文件中逐个元素地读取数据结构。当日志包含大量对同一文件的读取，且每次读取的偏移量连续但长度不同时，这种行为就很明显。考虑表 3-2 中所示的假设事件日志。

操作路径详细信息 Create FileC:\file.datDesired Access: Read Read FileC:\file.datOffset: 0 Size: 4 Read FileC:\file.datOffset: 4 Size: 2 Read FileC:\file.datOffset: 6 Size: 2 Read FileC:\file.datOffset: 8 Size: 4 Read FileC:\file.datOffset: 12 Size: 4.........继续读取一段时间的 4 字节块

这份日志揭示游戏正在逐块读取文件中的结构，透露出关于该结构外观的一些线索。例如，假设这些读取反映了以下数据文件：

struct myDataFile
{
    int header; // 4  0
    short effectCount; // 2  4
    short itemCount; // 2  6
    int* effects;
    int* items;
};

把表 3-2 中的日志与这个结构进行比较。首先，游戏读取 4 个 header 字节。然后，它读取两个2 字节的值：effectCount 和 itemCount。接着，它创建两个长度分别为 effectCount 和 itemCount 的整数数组 effects 和 items。然后游戏用文件中的数据填充这些数组，读取 effectCount + itemCount 次 4 字节。

注　开发者绝对不应该用这样的过程从文件读取数据，但你会惊讶于这种情况有多常见。幸运的是，这种幼稚反而让分析更容易。

在这种情况下，事件日志可以识别文件中的小块信息。但请记住，把读取与已知结构关联起来很容易，而仅凭事件日志逆向未知结构则困难得多。通常，游戏黑客会用调试器为每个有趣的事件获取更多上下文，而 Process Monitor 的数据可以无缝集成到调试会话中，有效地把两种强大的逆向工程范式联系在一起。