Godot逆向工程完整指南：用GDRE Tools把PCK一键还原成可编辑项目

Godot逆向工程完整指南：用GDRE Tools把PCK一键还原成可编辑项目

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

如果有一天你发现游戏源码丢了、备份损坏了，或者想拆开一个用 Godot 做的游戏研究它的实现思路，GDRE Tools（Godot RE Tools）就是那个能把你从「两眼一抹黑」里捞出来的工具。它是目前覆盖面最广的开源 Godot 逆向工程方案：既能从 PCK、APK、EXE 里完整恢复项目，也能批量反编译 GDScript 字节码，还自带资源格式互转、PCK 打包与修补等周边能力。本文将带你从零走通「拿到一个游戏包 → 还原源码 → 在编辑器中重新打开」的全过程。

先弄明白：游戏发布后，你的代码到底藏到了哪里

在动手之前，值得花 30 秒搞清楚 Godot 项目的「变形」过程，这样后面看命令才不会懵。

• 脚本变成字节码：GDScript 源码在导出时会被编译成.gdc（或.gde）字节码文件。字节码不是明文，但也不是不可逆，这正是反编译的突破口。
• 资源打包进 PCK：场景、纹理、音频、字体等资源连同编译后的脚本，会被统一塞进.pck资源包；发布 Android 版时它们打进 APK，Windows 版则可以直接嵌入 EXE。
• 文本资源转二进制：.tscn场景和.tres资源在导出时默认转为二进制变体，进一步提升加载速度、也增加了阅读难度。

换句话说，一次正常导出之后，你手里的就是一个「封装严实」的包。而GDRE Tools 干的事情，就是把这个过程倒着走一遍：解包 → 反编译脚本 → 把二进制资源转回文本 → 重建project.godot配置 → 输出一个能直接丢进 Godot 编辑器的完整工程。

什么时候用得上？丢代码恢复、学习别人的关卡设计、做安全审计、给老项目做技术考古，都是典型场景。它支持从 Godot 1.0 一路覆盖到 4.5 的 59 个字节码版本，兼容面相当夸张。

一条命令把项目「挖」回来：核心能力全景

GDRE Tools 的招牌动作是完整恢复（Full Recovery），你只需要把包交给它：

gdre_tools --headless --recover=./release/mygame.pck --output=./out/mygame

--recover接受 PCK、APK、EXE，甚至已经手动解包好的目录，--output指定结果落地位置。整个恢复流程像一条流水线：

输入层：解析 PCK / APK / EXE 的目录与文件表 ↓ 解包层：提取文件、处理 AES 加密内容 ↓ 分类层：识别脚本、场景、纹理、音频等资源类型 ↓ 处理层：反编译 .gdc、二进制资源转文本、重建引用 ↓ 输出层：生成 project.godot、插件配置与恢复日志

除此之外，它还能独立完成这些高频任务，后文会逐个演示：

三分钟上手：安装并完成第一次项目恢复

安装方式挑一个

• Windows 用户最省事：用 Scoop 一条命令装好，之后gdre_tools直接可用：

  scoop bucket add games scoop install gdsdecomp

• 想用图形界面：下载官方发布版，解压即用，附带独立 GUI。
• 想自己编译：把仓库克隆到 Godot 源码的modules目录下（命名为gdsdecomp），准备好rustup和 .NET 10 SDK，用 SCons 重新构建引擎。仓库地址：

  https://gitcode.com/GitHub_Trending/gd/gdsdecomp

最快的图形化路径

如果你更习惯点鼠标：打开 GDRE Tools，把.pck或.exe直接拖进窗口，或者从「RE Tools」菜单里选「Recover project...」，然后指定输出目录。

注意对话框里有两个选项：「Extract only」只解包，「Full Recovery」做完整恢复。想拿到可编辑工程，请选后者。

怎么确认恢复成功了

恢复结束后会弹出报告窗口，同时在工作目录生成gdre_export.log：

日志里你会看到三样关键信息：

1. 检测到的引擎版本——请用这个版本（或同小版本）的 Godot 打开恢复结果；
2. 统计数字——成功反编译多少个脚本、失败多少个、导入多少资源；
3. 未实现清单——哪些格式暂不支持，先有个心理预期。

日常高频操作速查：提取、反编译与资源转换

完整恢复一次可能耗时较长，很多场景其实只需要其中一步。

只想要脚本

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

配合--include/--exclude可以精确圈定范围，比如只处理res://scripts/下的内容、跳过体积巨大的音频贴图：

gdre_tools --headless --recover=./game.pck \ --include="res://scripts/**" \ --exclude="res://assets/audio/*.ogg"

单独反编译 / 编译某个脚本

已经拿到.gdc文件的话，不必走完整恢复：

# 反编译单个脚本，输出到指定目录 gdre_tools --headless --decompile=./main.gdc --output=./src # 批量反编译整个目录（支持通配符） gdre_tools --headless --decompile="./extracted/**/*.gdc" # 反向操作：把改好的脚本重新编译成字节码 gdre_tools --headless --compile=./src/main.gd --bytecode=4.3.0

--bytecode参数接受引擎版本号（如4.3.0）或字节码提交哈希，改完再编译回去做热修复时非常有用。

场景资源在文本和二进制之间互转

# 二进制场景 → 可读文本 gdre_tools --headless --bin-to-txt=./level.scn # 文本资源 → 二进制（导出自用） gdre_tools --headless --txt-to-bin=./level.tscn

把项目重新打成 PCK

gdre_tools --headless --pck-create=./project \ --pck-version=2 --pck-engine-version=4.3.0 \ --output=./build/game.pck

--pck-version是包格式版本（0/1/2），--pck-engine-version指定目标引擎，必要时还能用--embed把包嵌进 EXE。

进阶玩法：加密包、自定义解密与不拆包的修补

标准加密项目

Godot 支持用 AES-256-CFB 加密资源包，密钥是 64 位十六进制字符串。只要你有密钥，恢复几乎无感：

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

非标准加密怎么办

部分游戏会魔改加密流程。这时可以用 GDScript 继承CustomDecryptor，实现_parse_and_decrypt方法描述自定义的头部解析与解密逻辑，然后这样加载：

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

写法和思路可以参考项目内的两份文档：docs/custom_decryptors.md 与 docs/gdre_standard_encryption.gd。

强制指定字节码版本

万一自动检测结果不理想（比如目标用的是魔改引擎），可以手动干预：

gdre_tools --headless --recover=./weird.pck --force-bytecode-version=4.3.0

不拆包直接修 PCK

遇到「游戏卡死了、想改个小逻辑再发布」的场景，不必重新打包整个项目：

gdre_tools --headless --pck-patch=./game.pck \ --patch-file=./hotfix.gd=res://scripts/main.gd \ --output=./game_fixed.pck

翻译更新同理，--patch-translations=./zh.csv=res://locale/zh.po即可。

摸清工具边界：这些事它暂时做不了

保持合理预期，能省下大量排查时间：

• Godot 2.x 的模型格式（.dae、.fbx、.glb等）转换尚未实现，老游戏的美术资源可能只能拿到原始文件；
• GDNative / GDExtension 脚本反编译支持有限，C# 项目则依赖独立的 Godot Mono 反编译组件；
• 反编译会还原逻辑结构与控制流，但编译器优化过的变量名无法 100% 复原，复杂脚本可能需要手工润色；
• 运行时动态生成、内存中加载的资源不在包内，自然无法恢复。

新手避坑清单与提效小贴士

几个提升效率的习惯：

• 先跑gdre_tools --headless --list-files=./game.pck看清楚包内结构，再决定恢复策略；
• 用--list-bytecode-versions查看当前工具内置的字节码清单；
• 批量处理多个包时写个 for 循环，把--output按包名自动命名；
• 恢复前备份原始文件，所有操作都在副本上进行。

你可能想问的五个问题

Q1：反编译出来的脚本还能再编译回去吗？可以。用--compile加对应的--bytecode版本即可，改动脚本后重打包做热修复是它的典型用法。

Q2：怎么快速判断一个 PCK 是什么版本导出的？直接对它跑一次完整恢复，日志里会给出检测到的引擎版本；也可以看字节码特征对比--list-bytecode-versions。

Q3：不知道加密密钥，还有救吗？标准加密前提下基本没救，密钥就是门锁钥匙。所以别指望工具帮你破解密钥，它的定位是「有钥匙时顺畅进门」，而不是撬锁。

Q4：日志里的「support has not been implemented yet」是什么？意思是该文件类型暂时没有对应的还原处理器，文件本身仍会被提取，只是不会做格式转换。通常不影响其余资源的恢复。

Q5：老版本 Godot 1.x 的项目能恢复吗？能。内置的字节码版本列表从 1.0-dev 一路覆盖到 4.5 stable，早期版本的项目同样在支持范围内。

不只是工具：背后的设计与你可以参与的方向

GDRE Tools 之所以兼容面这么广，得益于它把「每个引擎版本的字节码差异」做成了可维护的数据。打开项目里的 misc/bytecode_versions.json，你会看到每条记录对应一个引擎版本的 token 增删、函数改名、参数变化等定义；而 bytecode/ 目录下每个版本一个解析器类，统一继承自基类，形成了一套清晰的版本管理体系。

如果你有兴趣深入：

• 阅读 BYTECODE_HISTORY.md 了解历次字节码演进；
• 自定义解密器的 API 文档在 docs/custom_decryptors.md；
• 想给项目做贡献，从克隆仓库、编译源码开始，边用边提 issue 也是很好的方式。

社区目前关注的方向包括：提高反编译准确率、增量恢复、分布式处理大型项目、以及接入更多资源格式——AI 辅助还原也在探索之中。这类工具的生命力，恰恰来自每一个新引擎版本发布后的及时跟进。

一句话总结

GDRE Tools 是目前开源世界里覆盖 Godot 版本最全、功能最完整的逆向工程工具集：解包、反编译、恢复、重建、修补一条龙。别把它当成「破解神器」，把它当成你遗失代码后的救援队、研究他人作品时的显微镜。

现在就动手：克隆仓库、装好工具，挑一个你手头的.pck试试。从「拿到包」到「看到源码」，你与它之间只差这一条命令。

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