Godot逆向工程实战：三步把编译后的PCK包还原成可编辑的完整项目

【免费下载链接】gdsdecompGodot reverse engineering tools项目地址: https://gitcode.com/GitHub_Trending/gd/gdsdecomp

GDRE Tools（仓库名 gdsdecomp）是一款开源的 Godot 逆向工程工具，主打 GDScript 反编译与 PCK 文件提取，能把发行包还原成可编辑项目。这篇文章从新手视角出发，带你理解它怎么工作、怎么上手，以及最容易在哪一步踩坑。

凌晨两点，小林手里只剩一个 .pck 文件

小林的独立游戏上线三个月，口碑不错。然后他的笔记本报废了——硬盘彻底不读盘，而源码只存在本机，从未同步到云端。

他手里还剩什么？一个给玩家下载的 Windows 导出包，里面只有 game.exe 和一个 game.pck。

pck 是 Godot 打包项目资源后的容器文件，里面的 GDScript 源码已被编译成 .gdc 字节码——一堆只有引擎能读懂的机器指令，人眼根本看不下去。场景、贴图、音频也大多变成了二进制格式。

对着这份"天书"，小林差点放弃。但后来他靠一个开源工具把整个项目救了回来：反编译出全部脚本、还原了场景文件、找回了原始贴图，甚至重建了 project.godot。

这个工具就是 GDRE Tools，它做的事，专业说法叫"Godot 逆向工程"。

一句话定位：它是把"压缩饼干"泡回"面团"的热水

如果把发行包比作一块烤好的压缩饼干——原料被压紧、脱水、定型，营养还在，却不再是原来的形状——那么 GDRE Tools 就是那杯热水。

它不会凭空给你一份新源码，而是通过逆向分析，尽可能把你"压进去"的东西恢复原状：字节码还原成 GDScript、二进制场景还原成文本 .tscn、压缩贴图还原成 PNG。压缩饼干泡开不可能 100% 复原，但这个工具的还原度，已经足够支撑你继续开发。

一句话记住它：GDRE Tools 是给 Godot 开发者准备的"项目还原器"——丢源码、想学习、做审计，它都能把编译产物"泡回"可读的工程文件。

上手路径：从下载到第一次成功恢复

第一步：拿到工具

Windows 用户最快的安装方式是 Scoop，两步搞定：

scoop bucket add games scoop install gdsdecomp

执行完gdre_tools命令就装好了。不想用包管理器，也可以直接去项目 release 页面下载现成版本；想从源码构建，见文末。

第二步：第一次 GUI 体验

启动后是名为 "PCK explorer" 的主界面。把 .pck 或 .exe 文件直接拖进窗口，工具会立刻解析出包内所有文件，右侧还能预览脚本的字节码信息。

第三步：跑通第一条命令

觉得命令行更顺手？一条命令就能完成整个项目恢复：

gdre_tools --headless --recover=game.pck --output=recovered_project

它做的事：读取 game.pck → 反编译所有 .gdc 脚本 → 还原场景与资源 → 重建 project.godot → 输出到 recovered_project 目录。跑完你甚至可以直接用 Godot 打开这个目录，继续开发。

任务驱动式能力地图：遇到什么任务，用什么命令

按"你想做的事"来认识这个工具，比按功能清单记它高效得多。先把六类高频任务速查表放在这里：

下面逐一展开。

任务一：项目源码全部丢失，想把整个游戏还原

gdre_tools --headless --recover=my_game.pck --output=recovered

完整恢复会自动处理脚本反编译、二进制资源转文本、import 文件重建和插件配置。恢复时你可以选择模式，比如只解压或完整恢复，并指定目标目录。

恢复完成后，目录里会生成一份 gdre_export.log。它会告诉你检测到的 Godot 引擎版本、成功反编译的脚本数、失败数——恢复后第一件事就是读它。

任务二：只想学习脚本逻辑，资源一概不要

比如你研究某个游戏的实现方式，不需要贴图和音频，加一个参数就行：

gdre_tools --headless --recover=game.pck --scripts-only

想单独反编译某个 .gdc 文件，用--decompile，还支持通配符批量处理：

gdre_tools --headless --decompile="res://scripts/*.gdc" --output=./decompiled

任务三：只挑一部分资源，跳过占空间的大文件

用 include/exclude 做"选择性提取"，比如只要脚本、排除贴图：

gdre_tools --headless --recover=game.pck \ --include="res://scripts/**/*.gd" \ --exclude="res://assets/textures/*.png"

注意：glob 建议以res://开头，**表示递归匹配任意层级。

任务四：游戏加密了，只有密钥才能解开

Godot 的 PCK 支持 AES-256-CFB 加密。只要你有 64 位十六进制密钥，照常恢复：

gdre_tools --headless --recover=encrypted.pck \ --key=000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F

任务五：反向操作——把项目目录打成 PCK 包

恢复是"拆"，创建是"装"。把项目目录重新打成发行格式同样支持，还能顺便内嵌进 exe、加上加密：

gdre_tools --headless --pck-create=project_dir \ --pck-version=2 --pck-engine-version=4.3.0 --output=new_game.pck

做补丁、做汉化、给老游戏重新打包，都靠它。

深度一瞥：它凭什么兼容从 2.x 到 4.x 的几十个版本？

你可能会好奇：Godot 从 2.x 到 4.x，字节码格式变化那么大，GDRE Tools 为什么几乎全兼容？答案藏在项目根目录的misc/bytecode_versions.json里——这份文件有上万行，记录着 Godot 每个发行版本对应的字节码定义。

每个版本，一把专属的"钥匙"

GDScript 源码编译时会被切成一串 token（语言标记），再编码进字节码。麻烦的是，不同版本的 token 编号、函数签名、字节码头部结构都可能变化。GDRE Tools 的做法朴素但有效：为每个版本单独维护一套 token 表和解码规则。在仓库bytecode/目录下，每个版本对应一个解析器类，如GDScriptDecomp_ebc36a7、GDScriptDecomp_f3f05dc，全部继承自bytecode/bytecode_base.h中统一的GDScriptDecomp基类。

多层版本检测：猜不中就逐级回退

面对一个陌生的 .gdc，工具按这个顺序判断版本：

1. 看文件头魔数，判断是否为 PCK/EXE 格式
2. 解析字节码头，提取版本标识与 token 表，与已知版本比对
3. 精确匹配失败时，回退到该版本的"父版本"解析器（每个版本在 JSON 里都有 parent 字段）
4. 仍不满足时，你还能用--force-bytecode-version=4.3.0手动指定

这套"版本族谱 + 逐级回退"机制，就是它能覆盖 Godot 2.x/3.x/4.x 全系列的根本原因。想深入研究，从misc/bytecode_versions.json和bytecode/bytecode_base.h两个文件开始看最合适。

避坑手册：新手最常问的六个问题

Q1：反编译出来的脚本能直接用吗？逻辑结构基本完整，但变量名和局部变量类型可能被编译器优化或丢失。绝大多数场景下可以直接打开继续开发，复杂脚本可能需要手动微调。

Q2：恢复的项目该用哪个 Godot 版本打开？看 gdre_export.log，里面明确写了检测到的引擎版本。用同版本 Godot 打开兼容性最好。

Q3：加密包一直解密失败，怎么办？八成是密钥不对。检查 64 位十六进制密钥是否完整、大小写是否一致。另外有些游戏会对密钥做二次变换，密钥提取工具给出的值不一定直接用得上。

Q4：include/exclude 的 glob 怎么写才对？以res://或user://开头，**递归匹配。单独写*.gdc会被自动当成res://**/*.gdc。

Q5：为什么有些文件恢复不了？Godot 2.x 的模型格式（dae/fbx/glb 等）以及 GDNative/GDExtension 脚本目前尚不支持转换，这是工具已知的边界。

Q6：从源码编译时总报错，是我的问题吗？大概率不是。GDRE Tools 需要作为模块放进 Godot 源码的modules目录后一起重新编译，同时要装好 Rust 工具链和 .NET SDK。单独编译它自己是编不出来的。

进阶玩法：当普通恢复已经满足不了你

给非标准加密的游戏写自定义解密器

如果某款游戏用了魔改的加密方案，工具允许你写一个 GDScript 解密脚本：继承CustomDecryptor类，实现_parse_and_decrypt()方法，然后挂载：

gdre_tools --headless --recover=custom_encrypted.pck \ --custom-decryption-script=my_decryptor.gd

仓库docs/custom_decryptors.md里有完整指南，还附带了实现标准加密方案的参考脚本docs/gdre_standard_encryption.gd，照着改就行。注意：解密脚本里不要内置密钥，涉及法律风险。

导出并修改字节码定义，适配魔改引擎

遇到改过内部的引擎，可以先把内置定义全部导出成 JSON：

gdre_tools --headless --dump-bytecode-versions=./bytecode_defs

调整后再用--load-custom-bytecode=./custom_bytecode.json加载，相当于给工具配一把"自定义钥匙"。

批量恢复一整个目录的游戏

手里十几个 pck 要处理？循环一键跑完：

for pck in *.pck; do gdre_tools --headless --recover="$pck" --output="recovered_${pck%.pck}" done

最后：源码会丢，但工具不会跑

回到小林的故事：他最终从那个唯一的发行包里，拿回了几乎全部源码、场景和素材，游戏得以继续更新维护。

GDRE Tools 的真正价值，不在于"破解"，而在于给开发者留了一条退路：无论源码是意外丢失，还是你想从成品中学习实现思路，它都能把编译产物"泡回"可以读、可以改、可以继续开发的形态。

如果你正握着一个 .pck 无从下手，现在就可以动手：

# 从源码构建的话，先克隆到 Godot 的 modules/gdsdecomp 目录 git clone https://gitcode.com/GitHub_Trending/gd/gdsdecomp # 或者直接开始恢复 gdre_tools --headless --recover=your_game.pck --output=recovered_project

Happy reversing，祝你顺利找回自己的项目。

【免费下载链接】gdsdecompGodot reverse engineering tools项目地址: https://gitcode.com/GitHub_Trending/gd/gdsdecomp