一次读懂 UEViewer从 .pak 字节流到模型贴图的完整资源提取链路【免费下载链接】UEViewerViewer and exporter for Unreal Engine 1-4 assets (UE Viewer).项目地址: https://gitcode.com/gh_mirrors/ue/UEViewerUEViewer社区俗称 umodel是一款面向虚幻引擎 1–4 全系列游戏资源的查看与提取工具它能从.pak、.upk、.uasset这些二进制包里还原出模型、贴图、动画与材质。想象这样一个场景你双击 UEViewer 主程序选定游戏目录展开包文件列表右键一个资源点下导出——几秒钟后磁盘上多出一个 PSK 模型和一张 TGA 贴图。这篇文章要回答的问题是这几秒钟里程序内部到底发生了什么我们把这次导出当成一场从字节到资产的旅行沿着数据流经的每一站看看 UEViewer 如何一步步把 0 和 1 翻译成你能用的文件。先给这场旅行画一张地图一次导出可以被拆成四个连续的驿站每一站只负责一件事把上一站的产物交给下一站四个驿站各司其职各站之间只通过文件路径和内存对象这两种简单的中间产物通信。这份地图很关键因为后面每一次为什么这么设计的讨论都可以回到这张图上找到落点。第一站先把压缩包伪装成普通文件夹它解决什么问题游戏资源通常被打进.pak或.upk包里一个包可能塞了上千个文件。如果上层解析逻辑必须自己处理文件在包内第几个字节、是否压缩、是否加密那么所有模块都会写满压缩相关的脏代码。它是怎么设计的Unreal/FileSystem/目录下的GameFileSystem与FVirtualFileSystem提供了统一抽象。包内每个文件都会被登记成一条CGameFileInfo记录字段里既保存文件名、大小也保存它在包内的索引IndexInVfs。为了快速查找每条记录还带一个基于文件名计算出的哈希指针HashNext于是按名字找文件变成一次 O(1) 的哈希命中而不是遍历整个包目录。底层解包工作在Unreal/FileSystem/UnArchivePak.cpp中完成。它先检查包头的魔数0x5A6F12E1再按FPakInfo里的版本号决定如何解释后续字段——因为从 UE4.13 到 4.25pak 格式本身也一直在演化pak 版本演进新增内容对应的解析策略早期版本只有偏移、大小、压缩方式基础字段直接读FNameBasedCompressionMethod压缩算法从数字改为名字读出 4 组 32 字节名称再映射IndexEncryption索引区可能被加密读入bEncryptedIndex标志EncryptionKeyGuid引入密钥 GUID读到 GUID 后去匹配用户提供的 AES 密钥为什么这样优于其他方案一个很能说明问题的细节是MAX_OPEN_PAKS 32程序刻意限制同时打开的 pak 文件句柄数量。注释里写明原因——C 运行时库对进程可打开的文件数有 2048 的上限而一个游戏可能有几十上百个 pak。用一个小型句柄缓存既绕开了操作系统限制又避免频繁开关文件的开销。这是典型的用工程经验换健壮性的取舍。第二站验明正身——这是哪一代引擎、哪一款游戏它解决什么问题同一个结构体在《真人快打 X》里字段是 64 位的在《子弹风暴》里多了一个来历不明的字段到了《火箭联盟》又换了字节序。如果不先搞清我在跟谁说话后续一切解析都是空谈。它是怎么设计的解析入口是Unreal/UnrealPackage/UnPackage.h里的FPackageFileSummary。第一步是核对标签标准包文件以PACKAGE_FILE_TAG 0x9E2A83C1开头。但不少厂商魔改了标签于是代码里维护了一张特殊标签表#define PACKAGE_FILE_TAG 0x9E2A83C1 // 标准 Unreal 包 // 部分游戏自定义的标签 // 0x9E2A83C2 - Killing Floor // 0x7E4A8BCA - iStorm // 0xEA31928C - Hawken // 0x12345678 - TaoYuan // 0xEC201133 - StormWar后面还跟了一个长度字段需要跳过如果读到0xC1832A9E标签的字节反转则说明文件是小端/大端互反的程序会翻转自己的读字节序开关Ar.ReverseBytes true再继续。这比逐字段判断要省事得多。确定标签后用版本号把引擎划分成几代#define PACKAGE_V2 100 // UE2 起的分界 #define PACKAGE_V3 180 // UE3 起的分界UE4 的情况更特殊它的包版本是负数且从某个版本起可能出现无版本号包unversioned package。此时版本信息退化成一组自定义版本容器FCustomVersionContainer程序无法自行推断只能回调UE4UnversionedPackage()向用户弹窗询问——这正是很多 UE4 游戏首次打开时会跳出一个版本对话框的原因。为什么这样优于其他方案看一个代表性特例——压缩块结构FCompressedChunk的序列化代码friend FArchive operator(FArchive Ar, FCompressedChunk C) { #if MKVSDC || ROCKET_LEAGUE if ((Ar.Game GAME_MK Ar.ArVer 677) || (Ar.Game GAME_RocketLeague Ar.ArLicenseeVer 22)) { // MK X 与 Rocket League 使用 64 位文件偏移 int64 UncompressedOffset64, CompressedOffset64; Ar UncompressedOffset64 C.UncompressedSize CompressedOffset64 C.CompressedSize; ... } #endif #if BULLETSTORM if (Ar.Game GAME_Bulletstorm Ar.ArLicenseeVer 21) { int32 unk10; // 未知字段可能是 0 或 1 Ar unk10; } #endif }注意这些特例全部被#if宏包裹MKVSDC、ROCKET_LEAGUE、BULLETSTORM宏来自Unreal/GameDefines.h。这套一个游戏一个宏的设计让每种特例都能独立开关编译时不需要的游戏支持会被整个剔除体积和解析负担都随之下降而新增一款游戏的补丁也只需改动个别文件不会污染主流程。第三站会报出版本号的尺子——FArchive它解决什么问题引擎里几乎每一个对象贴图、骨骼、动画曲线、材质节点都是按固定顺序写入的字段序列。需要一个统一的读写游标让几千处对象解析代码共享同一套行为。它是怎么设计的答案在Unreal/UnCore.h的抽象基类FArchive里class FArchive { public: int ArVer; // 引擎版本号 int ArLicenseeVer; // 厂商私有版本号 bool IsLoading; // 当前是读还是写 bool ReverseBytes; // 是否需要字节序反转 virtual void Seek(int Pos) 0; virtual void Serialize(void *data, int size) 0; void DetectGame(); // 根据版本号与内容推断游戏 int Engine() const { return (Game GAME_ENGINE); } };可以把它想象成一把会主动报出自己出厂版本的尺子它不只会移动游标和读写字节还随身携带ArVer、ArLicenseeVer和Game三个身份牌。任何一处结构体解析在拿不准时都可以低头问一句现在是在哪一代引擎、哪款游戏的环境下然后决定按哪种布局读取。包内的FObjectExport表则记录每个导出对象的类索引、名字、以及SerialOffset/SerialSize——即它在文件里的精确位置和长度对象模型层据此按图索骥地跳转读取。为什么这样优于其他方案一种朴素的做法是每代引擎写一套完整解析器但那样代码量会爆炸且难以维护。UEViewer 的选择是一份代码、多处版本分支把版本判断下沉到序列化函数内部用Ar.Game与ArLicenseeVer做细粒度分流。另外还有一处值得注意的取舍UnCore.h里定义了USE_COMPACT_PACKAGE_STRUCTS宏默认开启后FObjectExport中那些框架用不到的字段如SuperIndex、ObjectFlags会被直接跳过不读。代价是丢掉一部分调试信息收益是解析更快、内存更省——这是典型的为实用放弃完整的工程决策。第四站导出器的点名册与查重表它解决什么问题还原出来的对象种类繁多骨骼网格、静态网格、材质、纹理、声音、动画集……导出模块需要一种低成本的方式把对象类型分发到对应的导出函数同时保证同一资源不被重复写出。它是怎么设计的Exporters/Exporters.h暴露了一个极简的注册接口typedef void (*ExporterFunc_t)(const UObject*); void RegisterExporter(const char* ClassName, ExporterFunc_t Func); // 模板包装免去手写类型转换 templateclass T FORCEINLINE void RegisterExporter(void (*Func)(const T*)) { RegisterExporter(T::StaticGetTypeinfo()-Name 1, (ExporterFunc_t)Func); }Exporters/Exporters.cpp里维护了一个容量为MAX_EXPORTERS20的静态数组。每个导出实现文件在初始化时调用一次注册即可例如Exporters/ExportPsk.cpp注册 PSK 导出、Exporters/ExportTexture.cpp注册纹理导出。新增一种格式就是新建一个文件 追加一行注册分发逻辑一行都不用改。更妙的是去重机制。ExportContext用包指针 导出索引作为键构建了一张 4096 桶的哈希表ItemExists/AddItem。为什么必须去重代码注释里有个震撼的数字在某个测试案例中580 张纹理被不同材质引用了 18000 次——UE3/UE4 里一张贴图被成百上千个材质共享是常态。如果不查重一次批量导出会重复解压同一张贴图几千次。更绝的是OnObjectLoad回调会在纹理导出完成后把它替换成占位对象后续加载直接跳过真实数据省下的不仅是磁盘还有海量解压时间。从会用到能改三条上手路径理解了四站链路后你会发现 UEViewer 的扩展点被刻意做得很浅。按照你的角色有三条对应的上手路径你的角色目标该看哪里最小改动快速使用者编译并跑起来根目录common.projectpackage_lnx.sh克隆仓库后按脚本编译出可执行文件二次开发者加一种导出格式Exporters/下的现有实现新写一个导出函数 一行RegisterExporter格式研究者适配一款新游戏Unreal/GameDefines.h、Unreal/GameSpecific/、GameDatabase.cpp加一个游戏宏在特例处用Ar.Game分流值得说明的是这个项目没有用 CMake 这类主流构建系统而是维护了一套基于 Perl 的自定义构建器Tools/genmake。它读取人类友好的.project描述文件变量、条件、平台声明再生成对应平台的 Makefile。你可以在common.project里看到LIBC shared、OPTIMIZE size这类声明式配置——整个工程几十个源文件、上百个游戏宏全靠这一套脚本组织。想亲手验证本文的每一站可以这样开始git clone https://gitcode.com/gh_mirrors/ue/UEViewer cd UEViewer # 查看根目录的 package_lnx.sh 与 Tools/genmake了解构建入口地图的边界哪些地方走不通诚实地说这张地图有几处禁区。其一它只覆盖视觉资源——着色器还原、蓝图逻辑这类非可视化数据不在范围内。其二UE4 的 AES 加密包需要你手动提供密钥界面里那个密钥输入框就是干这个的且新引擎版本的支持往往要等社区跟进。其三部分厂商私有格式是通过逆向推断出来的个别字段含义不明时USE_COMPACT_PACKAGE_STRUCTS这类开关会选择跳过不读极端情况下模型可能出现细微瑕疵——这是所有逆向工程的宿命。读完这条链路你对 UEViewer 的理解就不再是一个能提取资源的黑盒而是一张有明确路标的地图哈希索引的文件登记、验明正身的包解析、随身携带版本号的FArchive、以及一行注册一个导出器的分发机制。下次当你导出一个模型时不妨想想它刚刚走过的四个驿站。那么轮到你了在实际逆向解析游戏资源的过程中最常让你卡住的是哪一环——是版本兼容判断、pak 的压缩与加密、纹理的 GPU 压缩格式还是骨骼动画的绑定关系欢迎分享你的经历也期待看到你基于这张地图扩展出的新玩法。【免费下载链接】UEViewerViewer and exporter for Unreal Engine 1-4 assets (UE Viewer).项目地址: https://gitcode.com/gh_mirrors/ue/UEViewer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考