阅读OneDrive日志第二部分

在上一篇OneDrive博客文章中，我概述了ODL文件格式的结构。我们还创建了一个可工作的ODL解析器来读取这些文件。其中一个关键细节是如何对个人文件/文件夹、位置或凭据识别字符串进行混淆，原始值存储在ObfuscationStringMap.txt文件中。

然而在2022年4月的某个时候，Microsoft决定改变混淆的工作方式，解析器不再工作（反混淆部分）。

发生了什么变化？

OneDrive现在似乎对数据进行加密，不再使用ObfuscationStringMap.txt文件。该文件可能仍存在于旧安装中，但新安装包含不同的文件。

图1 - \AppData\Local\Microsoft\OneDrive\logs\Business1文件夹内容

如上图1所示，有一个名为general.keystore的新文件。该文件的格式是JSON，可以轻松读取，显然包含作为base64编码字符串的解密密钥。

图2 - 示例general.keystore内容

逆向工程时间

通过使用IDA Pro对OneDrive的LoggingPlatform.dll文件进行一些挖掘，我们可以看到该文件中使用了BCrypt Windows API。注意，这不是同名的bcrypt哈希算法！

图3 - LoggingPlatform.dll中的BCrypt*导入

跳转到使用这些函数的地方，很快就可以看出使用的加密是CBC（密码块链接）模式的AES，密钥大小为128位。

图4 - IDA Pro反汇编

在上面的代码片段中，我们可以看到对BCryptAlgorithmProvider的调用，然后如果成功，会调用BCryptSetProperty函数，该函数具有以下语法：

1
2
3
4
5
6
7

NTSTATUS BCryptSetProperty(
  [in, out] BCRYPT_HANDLE hObject,
  [in]      LPCWSTR       pszProperty,
  [in]      PUCHAR        pbInput,
  [in]      ULONG         cbInput,
  [in]      ULONG         dwFlags
);

不深入探讨太多无聊的汇编细节，我将跳过相关部分…

对于每个要加密的字符串，OneDrive使用存储在general.keystore文件中的密钥初始化一个新的加密对象，然后加密字符串并处理加密对象。加密的blob然后进行base64编码，并作为混淆字符串写入日志。在此过程中还有一些其他特点，例如将字符/和+分别替换为_和-，因为前者可能出现在base64文本中，但也用于URL中，以便以后解析。

为什么改变？

在ODL的前一个迭代中（当使用ObfuscationStringMap时），有时相同的键（3个单词组合）经常在文件中重复，使得难以或不可能知道使用哪个值作为替换以获得原始字符串。

使用加密而不是查找表似乎是一个更健壮的方案，消除了上述问题。它确实使用更多的磁盘空间，因为加密的blob将始终是16字节（128位）的倍数，因为这是基于块的加密。换句话说，对于小文本（小于10字节）来说效率低下。

更新代码

Python ODL解析器已更新以适应这种新格式，并且适用于旧版本和新版本。可在此处获取。