硬盘里只剩一个 .pck我把丢失的 Godot 项目原样找了回来【免费下载链接】gdsdecompGodot reverse engineering tools项目地址: https://gitcode.com/GitHub_Trending/gd/gdsdecomp去年冬天整理硬盘时我一个手滑把整整三个月的心血——一个正在开发中的 Godot 小游戏工程目录连同所有.gd脚本源码一起塞进了回收站然后……按下了清空。等我反应过来一切已经来不及了。那个游戏的源码、场景、美术资源全都灰飞烟灭。我唯一还握在手里的是几天前为了发给朋友试玩而导出的那个安装包一个孤零零的my_game.pck文件。当时的我以为这个文件只是个成品外壳里面的东西再也掏不出来了。后来我才知道我错得离谱。就是这个看似封闭的.pck借助一个名叫GDRE Toolsgdsdecomp的开源逆向工程工具把我丢失的 Godot 项目几乎原样地找了回来——脚本反编译成了可读代码场景和资源也恢复了原貌。这篇文字就是那次失而复得的全过程。如果你也曾在深夜对着损坏的硬盘欲哭无泪或者手里恰好捏着一个来路不明的.pck想看看里面有什么希望我的经历能给你一点底气。那个只装了导出包的移动硬盘先说清楚事情的全貌好让你理解我当时的绝望。Godot 项目在开发时是一堆明文文件.gd脚本是能直接打开的代码.tscn场景是文本格式.png贴图、.ogg音频都是常见格式。但一旦用 Godot 的导出功能打包成.pck这一切就全变了。.pck是 Godot 的专用打包格式它会把整个项目压进一个文件里。更麻烦的是GDScript 脚本会被编译成.gdc字节码——那是一种给引擎读的二进制机器码人类基本没法直接看懂。场景文件也会被转成二进制.scn。换句话说就算你能把.pck里的文件全部解压出来你拿到的也不是源码而是一堆加密过的天书。丢失源码的那天晚上我做了三件事件件碰壁第一我尝试用解压软件直接打开.pck。结果当然是一堆乱码.pck根本不是 zip 格式。第二我把它改成.zip后缀再试。依然失败。第三我在网上搜Godot 项目恢复搜出来的要么是教程里语焉不详的付费服务要么是半懂不懂的论坛帖子。看着屏幕上那一长串我看不懂的报错我一度以为这三个月的心血真的就这么没了。那段时间我甚至开始自我安慰反正也只是个练手的小游戏大不了重写。可每次想到那些精心调过的数值、写过的一百多条注释胸口就堵得慌。重写不是难是心累。转折原来逆向 Godot 项目是件有人做过的事转折发生在一个游戏开发交流群里。有人随口提了一句如果只是丢了源码试试 Godot RE Tools 呗专门干这个的。Godot RE Tools就是仓库名gdsdecomp的这个项目官方定位是Godot reverse engineering toolsGodot 逆向工程工具。它做的事恰恰是我需要的把 PCK、APK甚至是嵌入了资源的 EXE 文件解开提取出里面的全部资源再把.gdc字节码反编译回.gd源代码最后把整个项目恢复成能在 Godot 编辑器里直接打开的样子。它支持的版本范围也让我意外——Godot 2.x、3.x、4.x 全系列都在覆盖范围内。这背后是一套很扎实的设计在项目里每个 Godot 引擎版本都对应着一个专门的字节码解析类比如GDScriptDecomp_ebc36a7、GDScriptDecomp_f3f05dc它们都继承自同一个基类。所有版本的定义统一维护在 bytecode_versions.json 里已经积累了几十个版本每个新版本发布后社区都会很快跟进补充。打个比方这就好比你在做一道菜菜谱被翻译成了几十种方言而这个工具手头攒齐了所有方言的对照词典拿到哪种口音的字节码它都能给你翻译回普通话。看到这里我像是抓住了一根救命稻草。但说实话当时我心里还是半信半疑一个开源工具真能把编译后的字节码还原成接近原文的代码反编译听起来就很不靠谱不是吗亲历把 .pck 拖进窗口的那一刻我决定亲自试试。先从发布页下载了现成的 GUI 版本解压后是一个图形界面程序如果你更习惯命令行它也提供了gdre_tools --headless的无界面模式功能完全一致。打开程序后界面出乎意料地简洁。左上角有几个菜单选项其中一个正是我梦寐以求的——Recover project...也就是恢复项目。程序提示我也可以直接把 PCK 或 EXE 文件拖进窗口。我深吸一口气把my_game.pck拖了进去。屏幕上弹出了一个文件浏览器程序自动过滤出了它支持的文件格式.pck、.exe、.apk。选定文件、点击确认后PCK 解析完成一个文件列表出现在我眼前版本信息它准确读出了这个包是用 Godot 哪个版本编译的文件列表res://下的目录结构完整呈现我看到了熟悉的scripts/文件夹、assets/文件夹甚至还有我心心念念的main.gdc。看到main.gdc的那一刻我的手有点抖。那是我写了两个月的入口脚本现在它以字节码的形式躺在列表里等着被翻译回来。界面下方有两个选项Extract only仅提取和Full Recovery完整恢复。区别在于前者只是把文件原样从包里取出来脚本仍是.gdc字节码后者则会做全套手术反编译脚本、转换二进制资源、恢复project.godot配置文件目标是让项目能重新在编辑器中打开。我当然选了 Full Recovery然后指定了一个空的输出目录点击Extract...。高光时刻恢复出来的项目在编辑器里打开了等待的时间并不长。进度条走完程序弹出一份恢复报告。这份报告我看了很久很久上面写着反编译脚本 9 个、失败 0 个导入资源 7 个、成功转换 4 个还贴心地在日志里提示了检测到该项目的 Godot 版本建议使用对应版本编辑器打开。我按它说的用同版本的 Godot 编辑器打开了恢复出的工程目录。那一刻的感受我至今记得很清楚——入口脚本main.gd静静地躺在那里双击打开熟悉的代码行扑面而来。变量名、函数逻辑、注释绝大部分都还在。虽然个别变量名被编译过程抹平了这是字节码编译的固有损失稍后细说但整体结构清晰可读我甚至能直接基于它继续开发。场景文件也回来了.tscn文本格式编辑器里正常显示贴图、音频也都还原成了原始导入格式。那一刻我坐在电脑前有种想给这个工具的作者鞠躬的冲动。要知道几个小时前我还以为这三个月的心血彻底烟消云散了。顺便说一句恢复出的项目直接拖进 Godot 编辑器打开就行。如果手头只有命令行环境整件事其实也就是一行命令的事gdre_tools --headless --recovermy_game.pck --outputrecovered_project这行命令的意思是用无界面模式对my_game.pck做完整项目恢复结果输出到recovered_project目录。对新手而言GUI 拖拽更直观对脚本党来说命令行则能轻松塞进批量处理流程。反复折腾后我总结出的几条经验找回项目之后我又拿自己以前导出过的几个旧包反复试了几次慢慢摸出了些门道。这几条经验或许能让你少走弯路第一恢复后的项目最好用与原游戏相同的 Godot 版本打开。这不是玄学。不同版本之间场景格式、资源导入方式、GDScript 语法都有差异用版本不匹配的编辑器打开轻则报警告重则直接报错。恢复日志里会明确写出检测到的引擎版本照着用就对了。第二加密包必须提供密钥。很多正式发布的产品会对.pck做 AES 加密。对付这种包得用--key参数把 64 位十六进制密钥喂给它格式像这样--key000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F。密钥不对恢复出来就是一堆乱码。第三不用全量恢复时可以用筛选参数。只想看脚本加个--scripts-only它会跳过所有非脚本资源速度飞快。只想恢复某个目录--includeres://scripts/**/*.gd能精确圈定范围配合--exclude还能把大体积贴图、音频挡在门外。对那种动辄几个 GB 的大项目这一手能省下大量时间。第四别急着删原始文件先看日志。恢复报告里的每一项数据都有意义——反编译成功率、转换失败列表、未支持格式清单。即便结果不完美日志也能告诉你问题出在哪而不是让你对着目录发呆。第五反编译出来的代码定位是参考而不是原文。经过编译再反编译局部变量名、某些表达式写法会和原稿有出入。对我来说这完全够用——我本意是找回项目继续做而不是复刻一模一样的源码。如果你的目的是精确逆向某个项目请对变量名保留一份宽容心。也要说点实话它救不了的部分我不想把这个工具吹成万能的。用得越久越清楚它的边界在哪。首先是资源格式的支持有缺口。Godot 2.x 时代的模型格式.dae、.fbx、.glb这类目前转换支持尚未实现遇到老项目里的模型它只能原样提取、无法还原成可编辑的源格式。其次GDNative 和 GDExtension 这类 C 扩展脚本不在反编译范围内——它们本来就不是 GDScript字节码格式完全不同。另一个我得诚实面对的坑是反编译的代码变量名可能被优化掉一部分。在编译阶段Godot 会把某些局部变量改写或合并反编译回来时这些名字就成了var _0 ...这种占位符。逻辑还在但可读性打了折扣。遇到复杂的战斗逻辑、状态机脚本靠反编译结果改 bug确实会比手改源码费劲一些。还有个现实问题从源码编译这个工具门槛不低。它本质上是一个挂载在 Godot 引擎上的模块需要拉取源码、放进 Godot 的modules目录重新编译引擎。如果你是新手我强烈建议先直接用官方发布的现成版本GUI 或命令行都有完全够用。只有当你想二次开发、或者需要最新的字节码支持时再去折腾编译这条路git clone https://gitcode.com/GitHub_Trending/gd/gdsdecomp克隆下来后按项目文档的指引把它放进 Godot 源码的modules目录然后重新构建引擎即可。尾声那个移动硬盘的保险故事讲到这里你可能会问那你后来把代码找回来了就没再丢过吗说实话那次事故给我留下的最大财富不是反编译后的代码本身而是两条教训。第一版本控制是底线代码要往远端仓库推本地硬盘永远不是备份。第二哪怕手里只有导出包也未必是绝路——GDRE Tools 这样的 Godot 逆向工具就是那道最后的保险。现在的我每次导出游戏后都会顺手把.pck单独存一份到移动硬盘。别人问我为什么我说这是压缩过的源代码保险箱。也许在大部分人眼里那只是个几百兆的安装包但只有经历过的人才知道只要它还活着项目的灵魂就还在。如果你的手边恰好也有一个打不开的.pck或者一段被字节码锁死的旧项目不妨也试着拖一次窗口。Godot 项目恢复这件事比你想的要靠谱得多。祝你也能失而复得。【免费下载链接】gdsdecompGodot reverse engineering tools项目地址: https://gitcode.com/GitHub_Trending/gd/gdsdecomp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 硬盘里只剩一个 .pck，我把丢失的 Godot 项目原样找了回来
硬盘里只剩一个 .pck我把丢失的 Godot 项目原样找了回来【免费下载链接】gdsdecompGodot reverse engineering tools项目地址: https://gitcode.com/GitHub_Trending/gd/gdsdecomp去年冬天整理硬盘时我一个手滑把整整三个月的心血——一个正在开发中的 Godot 小游戏工程目录连同所有.gd脚本源码一起塞进了回收站然后……按下了清空。等我反应过来一切已经来不及了。那个游戏的源码、场景、美术资源全都灰飞烟灭。我唯一还握在手里的是几天前为了发给朋友试玩而导出的那个安装包一个孤零零的my_game.pck文件。当时的我以为这个文件只是个成品外壳里面的东西再也掏不出来了。后来我才知道我错得离谱。就是这个看似封闭的.pck借助一个名叫GDRE Toolsgdsdecomp的开源逆向工程工具把我丢失的 Godot 项目几乎原样地找了回来——脚本反编译成了可读代码场景和资源也恢复了原貌。这篇文字就是那次失而复得的全过程。如果你也曾在深夜对着损坏的硬盘欲哭无泪或者手里恰好捏着一个来路不明的.pck想看看里面有什么希望我的经历能给你一点底气。那个只装了导出包的移动硬盘先说清楚事情的全貌好让你理解我当时的绝望。Godot 项目在开发时是一堆明文文件.gd脚本是能直接打开的代码.tscn场景是文本格式.png贴图、.ogg音频都是常见格式。但一旦用 Godot 的导出功能打包成.pck这一切就全变了。.pck是 Godot 的专用打包格式它会把整个项目压进一个文件里。更麻烦的是GDScript 脚本会被编译成.gdc字节码——那是一种给引擎读的二进制机器码人类基本没法直接看懂。场景文件也会被转成二进制.scn。换句话说就算你能把.pck里的文件全部解压出来你拿到的也不是源码而是一堆加密过的天书。丢失源码的那天晚上我做了三件事件件碰壁第一我尝试用解压软件直接打开.pck。结果当然是一堆乱码.pck根本不是 zip 格式。第二我把它改成.zip后缀再试。依然失败。第三我在网上搜Godot 项目恢复搜出来的要么是教程里语焉不详的付费服务要么是半懂不懂的论坛帖子。看着屏幕上那一长串我看不懂的报错我一度以为这三个月的心血真的就这么没了。那段时间我甚至开始自我安慰反正也只是个练手的小游戏大不了重写。可每次想到那些精心调过的数值、写过的一百多条注释胸口就堵得慌。重写不是难是心累。转折原来逆向 Godot 项目是件有人做过的事转折发生在一个游戏开发交流群里。有人随口提了一句如果只是丢了源码试试 Godot RE Tools 呗专门干这个的。Godot RE Tools就是仓库名gdsdecomp的这个项目官方定位是Godot reverse engineering toolsGodot 逆向工程工具。它做的事恰恰是我需要的把 PCK、APK甚至是嵌入了资源的 EXE 文件解开提取出里面的全部资源再把.gdc字节码反编译回.gd源代码最后把整个项目恢复成能在 Godot 编辑器里直接打开的样子。它支持的版本范围也让我意外——Godot 2.x、3.x、4.x 全系列都在覆盖范围内。这背后是一套很扎实的设计在项目里每个 Godot 引擎版本都对应着一个专门的字节码解析类比如GDScriptDecomp_ebc36a7、GDScriptDecomp_f3f05dc它们都继承自同一个基类。所有版本的定义统一维护在 bytecode_versions.json 里已经积累了几十个版本每个新版本发布后社区都会很快跟进补充。打个比方这就好比你在做一道菜菜谱被翻译成了几十种方言而这个工具手头攒齐了所有方言的对照词典拿到哪种口音的字节码它都能给你翻译回普通话。看到这里我像是抓住了一根救命稻草。但说实话当时我心里还是半信半疑一个开源工具真能把编译后的字节码还原成接近原文的代码反编译听起来就很不靠谱不是吗亲历把 .pck 拖进窗口的那一刻我决定亲自试试。先从发布页下载了现成的 GUI 版本解压后是一个图形界面程序如果你更习惯命令行它也提供了gdre_tools --headless的无界面模式功能完全一致。打开程序后界面出乎意料地简洁。左上角有几个菜单选项其中一个正是我梦寐以求的——Recover project...也就是恢复项目。程序提示我也可以直接把 PCK 或 EXE 文件拖进窗口。我深吸一口气把my_game.pck拖了进去。屏幕上弹出了一个文件浏览器程序自动过滤出了它支持的文件格式.pck、.exe、.apk。选定文件、点击确认后PCK 解析完成一个文件列表出现在我眼前版本信息它准确读出了这个包是用 Godot 哪个版本编译的文件列表res://下的目录结构完整呈现我看到了熟悉的scripts/文件夹、assets/文件夹甚至还有我心心念念的main.gdc。看到main.gdc的那一刻我的手有点抖。那是我写了两个月的入口脚本现在它以字节码的形式躺在列表里等着被翻译回来。界面下方有两个选项Extract only仅提取和Full Recovery完整恢复。区别在于前者只是把文件原样从包里取出来脚本仍是.gdc字节码后者则会做全套手术反编译脚本、转换二进制资源、恢复project.godot配置文件目标是让项目能重新在编辑器中打开。我当然选了 Full Recovery然后指定了一个空的输出目录点击Extract...。高光时刻恢复出来的项目在编辑器里打开了等待的时间并不长。进度条走完程序弹出一份恢复报告。这份报告我看了很久很久上面写着反编译脚本 9 个、失败 0 个导入资源 7 个、成功转换 4 个还贴心地在日志里提示了检测到该项目的 Godot 版本建议使用对应版本编辑器打开。我按它说的用同版本的 Godot 编辑器打开了恢复出的工程目录。那一刻的感受我至今记得很清楚——入口脚本main.gd静静地躺在那里双击打开熟悉的代码行扑面而来。变量名、函数逻辑、注释绝大部分都还在。虽然个别变量名被编译过程抹平了这是字节码编译的固有损失稍后细说但整体结构清晰可读我甚至能直接基于它继续开发。场景文件也回来了.tscn文本格式编辑器里正常显示贴图、音频也都还原成了原始导入格式。那一刻我坐在电脑前有种想给这个工具的作者鞠躬的冲动。要知道几个小时前我还以为这三个月的心血彻底烟消云散了。顺便说一句恢复出的项目直接拖进 Godot 编辑器打开就行。如果手头只有命令行环境整件事其实也就是一行命令的事gdre_tools --headless --recovermy_game.pck --outputrecovered_project这行命令的意思是用无界面模式对my_game.pck做完整项目恢复结果输出到recovered_project目录。对新手而言GUI 拖拽更直观对脚本党来说命令行则能轻松塞进批量处理流程。反复折腾后我总结出的几条经验找回项目之后我又拿自己以前导出过的几个旧包反复试了几次慢慢摸出了些门道。这几条经验或许能让你少走弯路第一恢复后的项目最好用与原游戏相同的 Godot 版本打开。这不是玄学。不同版本之间场景格式、资源导入方式、GDScript 语法都有差异用版本不匹配的编辑器打开轻则报警告重则直接报错。恢复日志里会明确写出检测到的引擎版本照着用就对了。第二加密包必须提供密钥。很多正式发布的产品会对.pck做 AES 加密。对付这种包得用--key参数把 64 位十六进制密钥喂给它格式像这样--key000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F。密钥不对恢复出来就是一堆乱码。第三不用全量恢复时可以用筛选参数。只想看脚本加个--scripts-only它会跳过所有非脚本资源速度飞快。只想恢复某个目录--includeres://scripts/**/*.gd能精确圈定范围配合--exclude还能把大体积贴图、音频挡在门外。对那种动辄几个 GB 的大项目这一手能省下大量时间。第四别急着删原始文件先看日志。恢复报告里的每一项数据都有意义——反编译成功率、转换失败列表、未支持格式清单。即便结果不完美日志也能告诉你问题出在哪而不是让你对着目录发呆。第五反编译出来的代码定位是参考而不是原文。经过编译再反编译局部变量名、某些表达式写法会和原稿有出入。对我来说这完全够用——我本意是找回项目继续做而不是复刻一模一样的源码。如果你的目的是精确逆向某个项目请对变量名保留一份宽容心。也要说点实话它救不了的部分我不想把这个工具吹成万能的。用得越久越清楚它的边界在哪。首先是资源格式的支持有缺口。Godot 2.x 时代的模型格式.dae、.fbx、.glb这类目前转换支持尚未实现遇到老项目里的模型它只能原样提取、无法还原成可编辑的源格式。其次GDNative 和 GDExtension 这类 C 扩展脚本不在反编译范围内——它们本来就不是 GDScript字节码格式完全不同。另一个我得诚实面对的坑是反编译的代码变量名可能被优化掉一部分。在编译阶段Godot 会把某些局部变量改写或合并反编译回来时这些名字就成了var _0 ...这种占位符。逻辑还在但可读性打了折扣。遇到复杂的战斗逻辑、状态机脚本靠反编译结果改 bug确实会比手改源码费劲一些。还有个现实问题从源码编译这个工具门槛不低。它本质上是一个挂载在 Godot 引擎上的模块需要拉取源码、放进 Godot 的modules目录重新编译引擎。如果你是新手我强烈建议先直接用官方发布的现成版本GUI 或命令行都有完全够用。只有当你想二次开发、或者需要最新的字节码支持时再去折腾编译这条路git clone https://gitcode.com/GitHub_Trending/gd/gdsdecomp克隆下来后按项目文档的指引把它放进 Godot 源码的modules目录然后重新构建引擎即可。尾声那个移动硬盘的保险故事讲到这里你可能会问那你后来把代码找回来了就没再丢过吗说实话那次事故给我留下的最大财富不是反编译后的代码本身而是两条教训。第一版本控制是底线代码要往远端仓库推本地硬盘永远不是备份。第二哪怕手里只有导出包也未必是绝路——GDRE Tools 这样的 Godot 逆向工具就是那道最后的保险。现在的我每次导出游戏后都会顺手把.pck单独存一份到移动硬盘。别人问我为什么我说这是压缩过的源代码保险箱。也许在大部分人眼里那只是个几百兆的安装包但只有经历过的人才知道只要它还活着项目的灵魂就还在。如果你的手边恰好也有一个打不开的.pck或者一段被字节码锁死的旧项目不妨也试着拖一次窗口。Godot 项目恢复这件事比你想的要靠谱得多。祝你也能失而复得。【免费下载链接】gdsdecompGodot reverse engineering tools项目地址: https://gitcode.com/GitHub_Trending/gd/gdsdecomp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考