图片缩放软件出了点问题，只能发原尺寸了，建议在手机上浏览，或者把窗口调小浏览
从steam上看到了一款游戏，玩了一会儿，不耐烦了，想玩玩资源提取，打开游戏文件夹，果不其然，资源被封包了成了PAC格式文件
QQ_1757770373334.png (105.46 KB, 下载次数: 0)
下载附件
2025-9-13 21:33 上传
我印象中感觉这家公司的封包难度不高，于是想尝试一下静态分析
速通流程
了解头部
首先打开010Editor，看一下最小的文件
QQ_1757770828178.png (174.5 KB, 下载次数: 0)
下载附件
2025-9-13 21:40 上传
这是一个字体文件，很显眼的文件名显现在眼前，说明包内目录和文件名未加密也未压缩，且包内只有一个文件，后面是不是文件数据尚不明确
QQ_1757685565924.png (23.35 KB, 下载次数: 0)
下载附件
2025-9-12 21:59 上传
这时看到文件名长度为0x1C，就会联想到记录文件名长度是游戏封包文件常用的手段，但是并没有在合理的地方发现1C字节，所以还要继续寻找线索。
再打开个其他文件
QQ_1757770941125.png (206.16 KB, 下载次数: 0)
下载附件
2025-9-13 21:49 上传
这次打开了一个封包有视频的PAC
QQ_1757771012418.png (213.58 KB, 下载次数: 0)
下载附件
2025-9-13 21:49 上传
发现这个PAC里有4个WEBM格式的视频文件，每个文件名后面用0x00字节来分隔开，这里也解释了没有记录文件名长度的原因，而是通过跳转到指定的偏移位置开始读取，遇到0x00就表示文件名读取结束。
不过，文件名后面是不是WWENM视频数据也尚不明确
但此时发现了头部有不一样，字体PAC和视频PAC的第5个字节不一样，一个是0x01，一个是0x04，正好对应字体PAC内有1个文件，视频PAC内有4个文件，两个文件的6-8字节也是0x00，所以可以断定第5到第8字节是通过小端存储的方式记录PAC内的文件数量。下面继续寻找线索。
再打开一个有音频的PAC
QQ_1757771091755.png (178.37 KB, 下载次数: 0)
下载附件
2025-9-13 21:49 上传
这是游戏BGM PAC，看到第5个字节是0x19，转变成十进制就是25d，这意味着上面这个PAC里有25个文件
了解目录表
往下拉。看到了文件名
QQ_1757771135677.png (204.01 KB, 下载次数: 0)
下载附件
2025-9-13 21:49 上传
接下来再做最后的验证，尝试Ctrl+F，搜索一下“.wav”有多少个
果然，一共匹配到了25个结果
QQ_1757751119727.png (110.9 KB, 下载次数: 0)
下载附件
2025-9-13 16:12 上传
再试着搜一下语音PAC里的WAV数量，010Editor匹配到2751个结果，5-8字节为0xBF 0x0A 0x00 0x00，将小端存储结果转换成普通十六进制为0xABF
QQ_1757751372656.png (81.72 KB, 下载次数: 0)
下载附件
2025-9-13 16:19 上传
计算器换算结果为2751
image.png (29.82 KB, 下载次数: 0)
下载附件
2025-9-13 16:20 上传
知道了文件数量存储方式，接下来寻找其他参数。
因为刚才我们不知道最后一个文件名后面的数据是不是文件数据，所以要用已知的文件头部来判断，我们知道，WAV文件头部标记为“RIFF”，所以再回到BGM PAC，看一下最后一个文件名后面是什么数据
很显然，正是“RIFF”
QQ_1757751372656.png (81.72 KB, 下载次数: 0)
下载附件
2025-9-13 16:31 上传
这里给了我们两个重要线索：1、文件名后面就是资源文件数据；2、数据未加密。
下面就好办了，找到记录资源数据的偏移和大小就OK了。
还是分析这个bgm1.pac，因为我们知道“RIFF”是WAV的文件头部，容易判断，先找一下首个“RIFF”起始位置。
这时看到状态栏的Pos显示的位置为十六进制524h
QQ_1757752529993.png (43.26 KB, 下载次数: 0)
下载附件
2025-9-13 16:38 上传
换算成小端存储方式就是“24 05 00 00”，来搜索一下。
QQ_1757771302950.png (184.05 KB, 下载次数: 0)
下载附件
2025-9-13 21:49 上传
搜到了7条结果，或许只有一个是记录其文件偏移的，其余的都是资源数据
第一条在8h字节处，但是突然出现了一个反常的情况
QQ_1757771352853.png (190.41 KB, 下载次数: 0)
下载附件
2025-9-13 21:49 上传
文件列表的前面位于288h处也出现了“24 05 00 00”，所以这两个只有一个才是记录资源数据的文件偏移。
先排查第二条结果相邻的数据。
我们先尝试搜索一下文件名后面的第一个与第二个"RIFF的间隔了多少个字节
QQ_1757753580583.png (102.98 KB, 下载次数: 0)
下载附件
2025-9-13 16:53 上传
第一个和第二个间隔了134987Ah个字节，小端存储就是“7A 98 34 01”，看一下刚才我们搜到的第二个“24 05 00 00”的位置，果然旁边就是“7A 98 34 01”！
QQ_1757753762093.png (154.54 KB, 下载次数: 0)
下载附件
2025-9-13 16:56 上传
此时文件偏移和大小顺利找到，两者后面都用四个0x00填充，所以这说明两者是八字节小端存储。
综上所述，PAC开头的“24 05 00 00”并不是文件列表的一部分。
继续往下看，文件偏移后面出现了“C1 70 83 CF 00 00 00 00”，转换成十六进制看起来数值很大，远远超出PAC文件大小更像是一组校验码，所以这里忽略。
再往后，出现了“70 04 00 00 00 00 00 00 00”，这个数值就比较小了，尝试转成十六进制470h，Ctrl+G跳转看一下
QQ_1757754447089.png (102.47 KB, 下载次数: 0)
下载附件
2025-9-13 17:07 上传
定位的位置为文件名首个字符
汇总PAC文件结构
到这里，PAC的基本结构就清晰明了
大概是这样的
PAC头部结构
[table]
[tr]
[td]类型[/td]
[td]作用[/td]
[td]备注[/td]
[/tr]
[tr]
[td]char
