从 APK/PCK 恢复完整 Godot 项目：gdsdecomp 上手与实战指南

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

gdsdecomp（Godot RE Tools）是一个面向 Godot 引擎的逆向工程工具集：它能从 APK、PCK 或内嵌 EXE 中加载项目资源，反编译全部 GDScript 脚本，重建 project.godot，并把导入后的二进制资源还原为原始格式——覆盖 Godot 4.x、3.x 与 2.x 三代字节码。如果你手上只有一个打包后的 Godot 游戏，又想看到它的源码和资源，这就是为这件事做的工具。

什么情况下你会需要它

三个真实场景，基本覆盖了这类工具的全部需求：

1. 源码丢失，只剩包：项目误删，磁盘上只剩下game.pck或 Android 的APK。手工解析 PCK 格式、逐版本手写字节码解释器不现实，gdsdecomp 一条--recover命令即可恢复可编辑的完整项目。
2. 学习/分析别人的实现：拿到竞品或演示项目的发布包，想知道某个系统（比如战斗状态机）具体怎么写的。--decompile可以只反编译脚本，不动资源。
3. 改包再打包：想给别人的 PCK 打补丁或自己重建 PCK，--pck-patch和--pck-create支持从目录生成 PCK、把 PCK 嵌入可执行文件（--embed），还能顺带加密（--key）。

工具以 Godot 模块的形式开发（仓库根目录有SCsub、register_types.cpp），但日常使用不需要源码编译——直接拿 release 版的gdre_tools二进制，或者在 Windows 上用 Scoop 安装：

git clone https://gitcode.com/GitHub_Trending/gd/gdsdecomp scoop bucket add games scoop install gdsdecomp

预期结果：本地有一份仓库（里面有测试用的 PCK 和脚本，后面直接拿来练手），以及一个可执行的gdre_tools。所有命令行用法都遵循同一模式：gdre_tools --headless <主命令> [选项]，--help可查看全部参数。

场景一：一条命令恢复整个项目

仓库自带 17 个不同 Godot 版本导出的示例项目（2.1.1 到 4.5.1），不用等自己找到目标游戏就能验证流程。以 4.5.1 为例，执行恢复命令：

gdre_tools --headless --recover=tests/test_projects/exported/4.5.1/2d/platformer/platformer.pck --output=recovered_451

预期会看到按步骤推进的恢复日志：加载 PCK、检测引擎版本、逐个反编译.gdc、还原资源。跑完后recovered_451目录里应该出现project.godot、反编译出的.gd源码，以及从导入格式还原的资源文件（比如纹理还原为 PNG、.res二进制还原为.tres文本）。

几个高频参数值得记住：

• --key=<64位十六进制串>：项目加密时提供 AES-256-CFB 密钥。注意大多数"解不开"的问题是密钥不对，而不是格式不支持。
• --scripts-only：只恢复脚本，速度快很多，适合只想看代码的情况。
• --include/--exclude：glob 过滤，如--include="res://**/*.gdc"。注意匹配的是 PCK 里实际存在的文件（.gdc），不是源文件名（.gd）。
• --force-bytecode-version=4.3.0：版本自动检测失败时手动指定，也接受 commit hash（如f3f05dc）。
• 恢复日志会打印检测到的引擎版本——编辑恢复出的项目时请装同一版本的 Godot，这是官方 README 明确提示的一点。

场景二：批量反编译 .gdc 脚本

如果只需要代码，不必恢复整个项目。仓库tests/test_scripts/4.4/code/里正好有成对的.gd（源码）和.gdc（字节码），方便对比反编译质量：

gdre_tools --headless --decompile="tests/test_scripts/4.4/code/*.gdc" --bytecode=4.4.0 --output=decompiled_44

--bytecode既可以是版本号（4.4.0），也可以是字节码的 commit hash；--output省略时，编译/反编译结果会直接落在原文件旁边（main.gd对应main.gdc）。预期输出是decompiled_44下出现main.gd、player.gd等文本脚本，内容可读、缩进正常。

反过来，工具也能把.gd编译成字节码（--compile=... --bytecode=...），以及做.res/.tres的二进制与文本互转（--txt-to-bin/--bin-to-txt）。这两组命令对"改完脚本再塞回 PCK"的工作流很有用。

它是怎么做到的：三个关键模块

理解三块实现，基本就理解了 gdsdecomp 的能力边界。

1. 字节码版本调度（bytecode/）

Godot 每个版本的 GDScript 字节码格式都不同，这正是逆向里最容易踩的坑。该目录里有 60 多个版本专用的解析器（bytecode_*.cpp，每个对应一个字节码修订号），由 bytecode_versions.cpp 统一注册和调度：先读.gdc文件头的版本号，再查表路由到对应解析器。完整版本谱系记录在 BYTECODE_HISTORY.md——从 2014 年分支 1.0 的 bytecode 1 一路到 4.x，每个 commit 改了什么一目了然。新增版本解析器不需要手写，bytecode_generator.py 可以自动生成。

2. PCK/EXE 容器解析（utility/）

gdre_packed_source.cpp 是容器层的核心：不仅解析 PCK 的头部与文件表，还实现了从 Windows PE、Linux ELF、macOS MachO 可执行文件中定位内嵌 PCK 的逻辑（EXEPCKInfo结构里能看到三种 EXE 类型的枚举）。这就是"直接拖一个game.exe进去也能恢复"的原因。pck_dumper.cpp 负责把解析出的文件落盘，pck_creator.cpp 则负责反向打包，task_manager基于 WorkerThreadPool 把独立任务分给多线程跑。

3. 资源还原与版本兼容（compat/ 与 exporters/）

Godot 4 导入后的资源大多是二进制格式（.res、.ctex等），要还原成编辑器里能直接编辑的文本/原始格式，且 3.x 与 4.x 的资源二进制结构还不通用。resource_compat_binary.cpp 和 resource_compat_text.cpp 提供跨版本的资源读写兼容层，exporters/ 里的gdscript_exporter、scene_exporter、texture_exporter等则按资源类型分派导出策略，保留原始导入设置，确保恢复出来的项目能在编辑器里正常打开。

加密项目怎么解

标准流程：确认游戏用的是 Godot 原生加密（AES-256-CFB），从 exe 里提取 32 字节密钥，转成 64 字符十六进制串传给--key。

如果游戏用的是自定义加密（密钥在加载后被置换、或换用了别的算法），原生解密必然失败。此时可以写一个自定义解密脚本：继承CustomDecryptor类，实现_parse_and_decrypt()，用仓库内置的AESContextGDRE、CamelliaContext、AriaContext三种加密上下文完成解密。完整的写法约定（文件头结构、解密流程、脚本如何注入）见 docs/custom_decryptors.md，标准加密的参考实现可以直接照抄 docs/gdre_standard_encryption.gd。

C# 项目是另一条支线：Godot 4 的 .NET 游戏需要额外提供程序集，--csharp-assembly=<路径>.dll（不给时会从 PCK 路径自动检测）。反编译由 godot-mono-decomp/ 下的 C# 工程完成，从源码构建时需要 .NET SDK。

进阶与避坑

• 报 "Unsupported bytecode version"：先--list-bytecode-versions确认工具覆盖的范围，再用--force-bytecode-version=<版本或commit>强制指定；仍不行说明游戏用的引擎版本超出支持区间。
• MD5 校验报错：--ignore-checksum-errors忽略校验失败继续提取，--skip-checksum-check则直接跳过校验。改包后校验必然不匹配，属正常现象。
• 恢复的项目在编辑器里打不开：九成是引擎版本不一致。恢复日志里会写明检测到的版本，用它打开项目即可；资源引用问题再看恢复日志中的警告条目。
• 已知能力边界（README 明说）：2.x 的模型格式（dae/fbx/glb）和 GDNative/GDExtension 脚本暂无转换支持，遇到这类资源只能拿到二进制原件。
• 大型项目：不必一次全量恢复。先--extract拿资源，再对**/*.gdc分批--decompile，最后--bin-to-txt处理二进制资源，既省内存也方便断点续做。
• 打补丁回写：--pck-patch=original.pck --patch-file="/abs/path/new.gd=res://scripts/main.gd" --output=patched.pck，--patch-file可重复多次，配合--embed能把补丁 PCK 直接写回可执行文件。

下一步

gdsdecomp 把"只能拿到编译产物的 Godot 项目"变成"可以打开、可以改、可以重新打包的项目"，核心就是版本全覆盖的字节码反编译 + 容器级 PCK 读写。建议的动作：先跑通上面 4.5.1 测试项目的--recover流程，打开recovered_451目录和反编译出的.gd文件确认效果；然后再拿一个真实目标包，从--list-files开始逐步深入。遇到新引擎版本时，查一下 BYTECODE_HISTORY.md 里对应 commit 的字节码改动，基本就能判断该版本是否已被覆盖。

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