逆向工程——未知Unity变种资源包（疑似加密bundle）的解包方法

Question

刚接触逆向，群友给我发来一个资源包文件（无扩展名，大小约16.4 MB），头部看起来像是UnityFS的变体，但标准工具无法解包。经过分析，文件特征如下：

其中：

魔数 15 1E 1C 0D 0D 23 21 类似于UnityFS的常见变种。
版本号 00 00 00 07 = 7。
主版本字符串 35 2E 78 2E 78 00 = "5.x.x"。
次版本字符串 32 30 31 39 2E 34 2E 31 34 66 31 00 = "2019.4.14f1"。
声明文件总大小 SIZE = 0xFB301E（约16.47 MB）。
COMP_BLOCKS = 0x3F8 (1016)
UNCOMP_BLOCKS = 0x1082 (4226)
COM_TYPE = 0x246 (582)
紧接着有2字节 VER = 0x32，可能是额外版本标识。
实际文件大小与 SIZE 基本一致（略有差异，可能是填充）。

数据结构：
文件头部之后，从偏移0x34到0x1000全是0。

从偏移0x1000开始出现有规律的非零数据（见附件截图），似乎是某种结构化数据。
然后再到0x2000再次出现非零数据。

已尝试的方法：
使用通用的UnityFS修复脚本，因 VER=0x32 未内置，手动设置 COMP_SHIFT 和 UNCOMP_SHIFT 在0~1000范围内穷举，均未成功解出有效文件。

直接解压：将偏移0x34处的1016字节分别用LZ4、Oodle解压，目标4226字节，结果解压失败或全零。尝试将偏移改为0x500也无果。

暴力搜索不同偏移和压缩大小，未找到任何能解出非零数据的组合。

修改文件头魔数为 UnityFS，将 COM_TYPE 改为3（LZ4HC），用AssetStudio打开报错“Lz4 decompression error”，提示写入/预期大小不匹配，似乎内部块信息错误。

用十六进制查看0x500开始的数据，无法识别格式，可能包含加密或自定义索引。

这种文件头结构是否有已知案例？
COM_TYPE=582 可能对应什么压缩类型？
VER 字段的作用是什么？
如何确定正确的 COMP_SHIFT 和 UNCOMP_SHIFT？
或者有无其他方式修正头部以正常解压？
从0x500开始的数据模式能否推断出文件结构（如目录、分块索引）？

如果有类似Unity资源包的解密经验，请各位指导手动提取资源的思路。

文件资源还在上传，这里只好展示部分截图：

然后到0x2000再次出现非零

Answer 1

上午好☀️☀️☀️️
本答案参考通义千问

你提供的信息非常详细，说明你已经对这个Unity资源包（疑似加密或自定义变种的bundle）进行了初步分析。根据你的描述，这个文件头部结构类似UnityFS，但存在一些特殊字段和压缩方式，导致标准工具无法正确解包。以下是针对你提出的问题进行的详细解答，并提供可行的解决方案。

---

一、问题分析与关键点

1. 文件特征分析

• 魔数：15 1E 1C 0D 0D 23 21，接近UnityFS的变体。
• 版本号：0x07（即7），对应Unity 5.x版本。
• 主版本字符串："5.x.x"。
• 次版本字符串："2019.4.14f1"，表明使用的是Unity 2019.4版本。
• 声明文件总大小：0xFB301E（约16.47MB）。
• COMP_BLOCKS = 0x3F8 (1016)，UNCOMP_BLOCKS = 0x1082 (4226)。
• COM_TYPE = 0x246 (582)，可能表示自定义压缩类型。
• VER = 0x32，可能是额外版本标识，如加密版本或自定义格式。

---

二、可能的解决方案与步骤

1. 确定文件头结构与修复方法

关键点：

• 魔数与UnityFS兼容性：虽然魔数类似UnityFS，但缺少标准的UnityFS头结构（如Magic + Version + FileSize等）。

• COM_TYPE = 582：在Unity中，常见的压缩类型包括：

  • 0x0003（LZ4HC）
  • 0x0004（LZ4)
  • 0x0005（Oodle）
  • 0x000A（LZMA）

  582（0x246） 可能是自定义压缩算法，需要进一步验证。

解决方案：

• 尝试将文件头改为标准UnityFS格式（例如：Magic为“UnityFS”），并手动设置 COM_TYPE 为 0x0003（LZ4HC）。
• 使用工具如 AssetStudio 或 UABE 加载修改后的文件头，观察是否能识别出部分数据。

注意： 如果文件经过加密，即使修复了文件头，也可能无法正常解压。

---

2. 解密与解压思路

关键点：

• VER = 0x32：可能是加密版本标识，用于判断是否需要解密。
• 从偏移0x500开始的数据：可能是加密后的索引表或元数据，需要进一步分析其结构。

解决方案：

• 暴力破解 VER 字段：尝试不同的VER值，看是否能解密出有效数据。
• 尝试不同压缩算法：虽然LZ4和Oodle失败，但可以尝试其他算法（如 zlib、gzip）。
• 尝试使用自定义脚本：编写脚本读取该文件，按 COMP_BLOCKS 和 UNCOMP_BLOCKS 分块读取，尝试用不同压缩算法解压。

示例代码（Python）：

import struct
import lz4.block

# 假设你已经提取了压缩块
compressed_data = b'...'  # 从0x500开始的压缩数据
uncompressed_size = 0x1082 * 0x1000  # 根据 UNCOMP_BLOCKS 计算

try:
    decompressed = lz4.block.decompress(compressed_data, uncompressed_size)
    print("Decompression successful!")
except Exception as e:
    print("Decompression failed:", e)

如果失败，尝试使用 zlib 或 Oodle 的API。

---

3. 分析0x500之后的数据结构

关键点：

• 数据看起来有规律，可能是目录表、资源索引或加密索引。
• 需要查看是否有可识别的Unity资源头（如 0x48 0x45 0x41 0x44，代表 "HEAD"）。

解决方案：

• 使用十六进制编辑器（如 HxD、WinHex）查看0x500之后的数据。
• 寻找Unity资源常见标志，如：
  • 0x00 0x00 0x00 0x00（空块）
  • 0x00 0x00 0x00 0x01（资源块）
  • 0x48 0x45 0x41 0x44（HEAD）
• 如果发现类似结构，可能是资源索引或加密元数据。

---

4. 推断文件结构

可能的结构模式：

• 0x0000 - 0x0034：文件头（含魔数、版本、压缩信息等）
• 0x0034 - 0x1000：填充或零数据
• 0x1000 - 0x2000：非零数据（可能是索引或加密元数据）
• 0x2000 - End：实际资源数据（可能被加密或压缩）

解决方案：

• 使用脚本遍历文件，按 COMP_BLOCKS 和 UNCOMP_BLOCKS 分割数据。
• 尝试将每个块用不同压缩算法解压，看是否能还原出Unity资源。

---

三、推荐工具与方法

| 工具 | 功能 | |------|------| | AssetStudio | Unity资源解析工具 | | UABE | Unity资源提取工具 | | HxD | 十六进制编辑器 | | [Python + lz4, zlib, oodle 库] | 自定义解压脚本 | | [IDA Pro / Ghidra] | 逆向分析（如果文件有加密逻辑） |

---

四、总结与建议

重点总结：

• COM_TYPE = 582 是一个关键点，可能对应自定义压缩算法。
• VER = 0x32 可能是加密版本标识，需尝试不同值。
• 从0x500开始的数据 可能包含索引或加密元数据。
• 尝试手动修复文件头 并结合自定义解压脚本是当前最可行的方式。

建议步骤：

1. 尝试修复文件头，改写为UnityFS格式。
2. 尝试不同压缩算法（LZ4、Oodle、zlib等）。
3. 分析0x500之后的数据，寻找Unity资源标志。
4. 编写脚本，分块读取并尝试解压。
5. 使用逆向工具（如IDA Pro）分析文件逻辑（如有加密）。

---

如果你愿意分享更多数据（如文件片段或截图），我可以帮助你进一步分析具体结构。希望这些方法对你有所帮助！