分析被感染的文件，文件感染前的所显示的内容
本次解密需要两个文件，一个是加密后的 .enc 文件，一个是 ransom_key 解密密钥。
我们在解析（第三篇）找到的文件头是 0x574D5352。
病毒加密过程：时间戳生成并写入8字节。通过计算 0x6836E298 = 1748384408，然后转换时间戳得到 2025-06-18 14:20:08。可以从代码得知，文件头 + 时间戳这两部分是直接写入的没有加密，所以直接跳过。
那么剩余的部分才是被加密的数据，加密方法上一篇也讲到了，典型的 异或 (XOR) 加解密 。
所以关键代码行在这里，我们找到核心代码解析。
i & 0xF 用按位与运算取 i 的低 4 位（二进制最后 4 位），结果只能是 0~15 之间的整数。直接限定了只能使用密钥的前16个字符。
- 0xF = 15（十进制）
- 二进制：1111（4位）
- i & 1111 保留最后4位
- 4位二进制最大表示15（1111）
那么密钥我们只取 16 位：22ad307d5b542336。
解密大家可以自行去 AI 生成 Python 代码，本文就不提供了，只写出第一位解密。
解密字节 = 加密字节 XOR 密钥字节
- 加密文件第一位加密字节为 65（HEX），转换成十进制为 101（DEC）
- 密钥第一位是 2（HEX），转换为 50（ASCII）
为什么密钥要转换成 ASCII 而不是 DEC 呢？
病毒作者错误地将密钥的十六进制字符串表示（文本）当成了密钥本身（数值）使用。生成密钥后计算了16字节的二进制哈希值，但错误地将其转换为十六进制字符串。
在 main 函数片段，v17 是16字节二进制数据，Buffer 是32字符的十六进制字符串，传递给加密函数的是 Buffer（字符串），而不是 v17（二进制）。
生成16字节二进制哈希值（存储在v17）：
将二进制转换为十六进制字符串（存储在Buffer）：
调用加密函数，传递Buffer（十六进制字符串）：
a2 是传入的参数（即 Buffer），a2 是 char* 类型（字符串指针），a2[index] 获取字符串中该位置的字符，字符在内存中存储为其ASCII值。
注：*(_BYTE *)((i & 0xF) + a2) 获取密钥的第 (i & 0xF) 个字符的ASCII值，相当于 a2[index]。
最后，101 XOR 50 = 87，对应的是大写的 W，剩下解密可以手动也可以直接代码解决。
