虽然没有进决赛但还是记录一下吧，比起去年UE做的已经很多了

拿到题是一个godot引擎加godot-cpp扩展的游戏引擎版本是4.5.1（关系到后面对应哪一版源码，虽然每版改动应该也不大吧） assets目录下可以看到有.gdc脚本，应该有主要相关逻辑写在trigger.gdc\token.gdc等，但.gdc被加密，不能用GDRE工具直接解。

观察两个so文件：libgodot-android.so; libsec2026.so

libsec2026.so套了壳，用脚本dump一下

从so文件的大小和字符串信息可以判断出 libgodot_android.so是godot引擎库，libsec2026.so是godot-cpp扩展部分和native方法实现；

查找godot相关加解密，应该是要找一个32位的AES密钥，加密模式是CFB，发现教程说关键函数是core/io/file_access_pack.cpp：相关教程都是用字符串定位这个构造函数去拿到script_encryption_key 但是，出题人肯定不能出这么简单，已经把这种字符串信息抹去了但是，本人虽笨却非常的勤快，决定尝试照着源码硬推，这种字符串没有，总有别的字符串，（且秉持着恩师的源码在一起的函数和文件，汇编也会在附近。。。一番搜索下定位到了pck_packer.cpp：

file_access_pack.cpp是解包部分逻辑，而pck_packer.cpp是打包部分逻辑，二者一定会有关联：二者都跟FileAccessEncrypted::open_and_parse有关，这就缩小查找范围了，可以直接把pck_packer的地址和源码给ai让它去帮我们找这个构造函数了

后面发现还有一些办法：

1.用魔术头“GDPC”定位try_and_open函数

2.用“res://”的交叉引用定位排查等等（不太推荐，很多地方引用

总之在ai强大的能力和努力下，成功地获得一系列相关函数地址：

也自然可以直接定位到我们要的key，这里出题人非常非常善良啊，key不是动态生成的，直接就给了：

但是把key输入GDRE还是解密失败了，于是就再次利用ai分析加解密流程，肯定是中间有地方魔改了：

于是再让ai搓了一个解密脚本：

解密后的.gdc文件头就正常了，放进GDRE工具里就可以反编译了flag生成逻辑就是先异或一下然后传进native层加密（大概

但拿到flag这一步，其实根本不需要去看native层加密逻辑（所以flag只值20分吗。。

这里有了godotscript脚本，虽然因为有cpp扩展的缘故不能直接放回引擎直接运行修改，但可以修改gd脚本重打包，而且我只是修改，连parsepck索引文件都不用重新生成，只用把trigger.gd改一下再用GDRE编译一下.gdc再套刚那套魔改AES加密回去就行了！

（这里其实还想了一种更难的方法，如果能找到godot引擎load -> call 一个gd函数的调用链，然后找到对应地址可以构造出一个任意gd代码注入执行器？（太复杂了没尝试。。

回到trigger.gd，真的非常好改啊，连文件大小都不用变啊，只用把两个碰撞判断的对象调换一下，1改成2，这样碰到黄色方块就是拿到flag，碰到绿色才是示例flag~改完重打包签名，得到“开挂版”：下载链接： 重打包apk

接下来就是在libsec2026.so里找加密函数了从字符信息里已经知道godot-cpp扩展部分也在这个so里，所以再次对应源码分析函数

传播安全知识、拓宽行业人脉——看雪讲师团队等你加入！