打开游戏，触发示例方块得到样例flag，目标是触发屋顶的方块，得到真正的flag，常规游玩、车是开不到那地方的。所以第一个目标：传送车的坐标到触发块的坐标。解包APK发现是Godot引擎制作的游戏，gdc脚本也被加密了，本身对godot不是很熟悉，不过既然是开源的就下载源码下来看看，同时上网搜索发现：Godot官方是支持用脚本加密的。懒了: cfbK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3f1#2x3Y4m8G2K9X3W2W2i4K6u0W2j5$3&6Q4x3V1k6@1K9s2u0W2j5h3c8Q4x3X3b7J5x3o6l9J5y4K6M7&6i4K6u0V1x3g2)9J5k6o6q4Q4x3X3g2Z5N6r3#2D9 ，直接照抄思路dump密钥（脚本末尾）得到ce4df8753b59a5a39ade58ac07ef947a3da39f2af75e3284d51217c04d49a061 ，尝试使用社区工具gdre_tools来解密显然是不行的，下载源码后发现脚本解密逻辑中的AES_MODE和游戏逆向出来的处理方式不太一样，要改掉那部分逻辑又得重新下个godot引擎编译很麻烦，干脆直接复用游戏内的解密逻辑，然后再用gdre_tools读取gdc脚本：游戏引擎（libgodot_android.so）解密魔改部分：解密脚本：同时获取到了flag的获取逻辑： 然后就是处理传送车的问题：反过来利用 Godot 自己的对象系统和场景系统，直接让游戏正常执行这段逻辑。根据Unity开发经验猜测：Godot肯定也有某种find gameObject方法，找了一下 Godot 恰好给了这样做的条件。只要在 Frida 里拿到引擎内部的这些能力：就可以像脚本层一样直接操纵场景节点。这部分的实现对应脚本是frida_move_trigger_sec2026.js(太长放末尾了)。核心思路远程调用引擎提供的接口实在懒得搜坐标手动改，还是原生的办法通用性高一些。如果只是改可见节点的位置，车不一定真的算“进入触发器”，因为场景里真正参与碰撞的是物理对象。也正因为这样，frida_move_trigger_sec2026.js 不是只改一次 transform 就结束了，而是同时做了两层同步：IDA打开可以分析的函数不多： 主要是解压子程序，然后通过BR命令跳转到子程序去执行逻辑。二环主要逻辑：选择在00001764 通过Frida脚本动态dump（脚本见末尾）下来继续分析：三环：因为三环入口 0x1c48 会先自修改代码，静态分析已经啃不动了，看静态毫无头绪，Hook要打上还得抓时机控制、不然直接崩。想着应该可以用Stalker去追执行流说不定方便点，但由于页权限切换、还有自修改代码等原因、反正我是一个个线程去试了，没扒下来。一番静态压根找不到Process的链路，转向动态，从native层和游戏层之间的沟通入手：根据解包的配置知道，libsec的在游戏中被调用的入口点是而Godot GDExtension的标准API是：在Godot游戏引擎要调用拓展的时候第一个传入的函数指针p_get_proc_address类似于引擎接口查询函数可以直接查到Godot 的注册接口地址classdb_register_extension_class_method 在注册拓展函数的时候，会交一个GDExtensionClassMethodInfo:call_func注册了拓展函数的入口点，注册时可以拿到三环关键函数的地址：对照dump下来的逻辑：可以发现自修改改了不少，动态分析就省去了那部分分析逻辑，而因为执行函数的时候是通过method_userdata下发分发的，调用时又加上了userdate做了一层偏移，触发flag获取的逻辑后，可以得到Object.Process在三环内的真正地址：结合静态来看，开始套娃：此时已经可以根据运行的参数，计算出之后的调度链（大致会执行哪些函数都看一遍、结果发现是套娃），通过binary ninja继续跟，直到套娃：0x4ffd0 类似的分发函数，按照类似的思路去做：重复这个操作下来两三次：0x4d7a8 -> 0x4ffd0 -> 0x4bd68 -> 0x4c8e4 -> 0x4e198 -> 0x4e548 -> 0x5bf18 -> 0x5b69c -> 0x5b5e0 -> 0x5b950。其中 0x5b818/0x5bcec 的 state dump 直接打出了 ChaCha20-like 常量、key、nonce，正式把整个处理逻辑给扒干净了，非常之搞笑。（脚本见末尾）正好有运行时反汇编的操作，顺手就可以确定加密逻辑，并把flag推随机值的一起做了，验证之后是没问题的：（见样例源代码）其实思路和2021还是2022的ACE保护差不多，都是游戏引擎侧对入口(global-meta.data、gdc)这种做加密，然后提高保护程序的分析难度，上混淆vmp、控制流平坦化什么的，这次赛题没有反调试、但是多环嵌套代码、自修改和动态跳转已经对Hook时机、方式有了一定的保护。同时三环的自修改写得也挺有意思，有外部分发、根据参数跳转执行的方式也对静态分析有了不小的挑战，同时动态分析时Frida的inlinehook是没法随意提前打上去拿各种信息的，stalker不知道为什么总是会崩。总之，很有意思！解题优化思路：如果有动态trace多线程dump执行流的办法，其实这道题就变得非常简单了，用的frida脚本其实已经有了雏形，可能以后再继续研究看看有没有更好的办法去自动化吧。打完决赛再放dump执行流的脚本，之后有时间可能改进一下做成工具，思路还是比较自信的，运行时dump听起来就很酷炫，这里多宣传一个个人写得zygisk工具：5eaK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6y4j5i4u0U0K9o6N6Q4x3X3c8U0L8$3c8W2i4K6u0r3h3Y4W2Y4K9i4y4C8d9h3&6B7k6h3y4@1i4@1g2r3i4@1u0o6i4K6S2o6i4@1f1$3i4K6R3@1i4K6W2r3i4@1f1#2i4K6R3#2i4@1t1@1i4@1f1^5i4@1t1$3i4@1p5K6i4@1f1%4i4K6W2m8i4K6R3@1i4@1f1#2i4@1p5@1i4@1p5%4i4@1f1@1i4@1u0p5i4@1q4o6i4@1f1#2i4K6S2r3i4@1q4r3i4@1f1@1i4@1u0n7i4@1p5#2i4@1f1%4i4K6W2o6i4K6S2n7i4@1f1%4i4K6W2o6i4K6S2n7i4@1g2r3i4@1u0o6i4K6S2o6i4@1f1#2i4K6R3H3i4K6W2r3i4@1f1&6i4K6R3&6i4@1t1@1i4@1f1^5i4@1q4q4i4@1u0m8i4@1f1#2i4K6W2p5i4K6W2n7i4@1f1#2i4K6R3$3i4
...(已截断)
---
来源: 看雪论坛
原文链接: https://bbs.kanxue.com/thread-290814.htm
[原创][讨论] 南极企鹅游戏安全2026-Android-初赛
136 浏览
1 回复
tql