扒尽手游的底裤——Cocos2dx与LuaJIT完全解密
嘿嘿嘿~在吾爱被加精了,毕竟是人生第一篇精华帖,庆祝一下~两天的夜没白熬😄
唔……今天早上又被吾爱官微推了一波,链接在这里。
为了满足收集欲,想要拿下某个卡牌类游戏的所有立绘。在逆向的过程中,开拓了一些前人没有发掘的领域,无论是中文还是英文都没有相应的资料。本文证明了,即使Lua源码被编译过,也不是绝对的安全。厂商们打的小算盘可能是——没有成熟的工具,不好破解。但是对于了解原理的安全研究者,这不是问题。反而对于不了解原理,着重于快速开发复用代码的游戏开发者来说,没有成熟的防护体系,无论是自己造轮子还是用别人的轮子,造成的威胁都会更大。
由于不知道会有什么影响,担心会让抄袭之风来的更快,在此有选择性的隐去一些源码和细节,但是思路都在这里一点没有删减,权当自己的笔记和对游戏厂商的警醒。我们开始咯~
先上一张解密后的样图。
玩过的童鞋可能一眼就能认出来,嘿嘿嘿。游戏名叫妖萌战姬,游戏本身我不多作评价。本文所分析的版本为官网下载20170922版本,截至本文发布时为官方最新版。
编译修改Luajit-lang-toolkit
解包后发现所有的png资源全部加密了打不开(嘿,但是音频还没有加密……不过并不会有人看嘛)。结合lib发现游戏是cocos2x与Lua编写。虽然Lua出了名的好逆,但是查看文件头后发现是编译后的LuaJIT……还是最新的2.1版。一番操作后找到一个项目 luajit-lang-toolkit(以下简称LLT),不过用起来有点小问题。make以后在src文件夹生成了luajit-x程序,与luajit的命令行工具参数一样。
$ luajit-x -bl main |
我们可以看到……啥也看不到……但是官方命令行工具的反汇编结果却大有不同。
你看人家至少有个RET啊!
$ luajit -bl main |
直接撸汇编可以,但是LLT可以解析更多的东西,怎么办?我仔细参考了一下opcode表[1],发现很多指令与正确指令之间在指令表之间(比如第一行的TGETV
与GGET
)只有两个指令的距离。再翻了翻LLT的issues里面有提到了2.1版本,某人还为他写了个patch[2]。我才明白——因为2.1的指令表与2.0相比,中间插入了两个指令,因此后面的指令在表中的位置都相应后挪。
我完善了一下这个patch,将更新的指令表加入了读写过程中,修改后的版本位于我的Github中的v2.1
分支。运行修改后的版本输出就正常了。
$ luajit-x -bxg main |
这个工具可以列出文件的hexdump与子程序的栈帧、局部变量等信息,是我特别心水的地方。下面进入逆向部分。
首先先把所有字节码反汇编并保存至src目录。在命令行中运行
ls | xargs -I% sh -c 'echo "Processing %" && luajit-x -bxg "%" > "src/%.lasm"' |
查看PNG头发现字样img.libla
,在png以外的文件里查找此字符串
$ grep libla . -R | grep -iv png |
如此看来解密过程应该就在libcocos2dlua.so
中。先拖IDA里让它分析起来。好吧勉强承认一下南辕北辙了(没事Lua部分后面用到)。
分析libcocos2dlua
在这个so文件里搜索img.libla
定位到函数cocos2d::Image::isMpi(uchar const*,int)
。去cocos2d-x官方文档里查询了一下竟然连Image这个类都没有。感觉不太可能,翻2.x版本的文档找到了对应的类CCImage,一直往后翻发现3.4是最后一个拥有这个类的版本。在字符串里搜一下3.
找一下有没有具体版本,有了意外发现。
.rodata:0119FB8B 0000004D C E:\\MyWorkSpace\\ACGProj\\cocosEngine\\Quick-Cocos2dx-361\\/cocos/./math/Vec3.cpp |
噫~原来是用了框架。在GitHub上找到这个框架[3],作者表示选择了“公认最稳定的版本”3.3。 其实就是懒得学新API了吧。 随便搜一搜还能找到很多有意思的加密方式[4][5]。我们开心的开始带源码作业。但是简单搜索后却发现源码里根本没有这个函数。我们回到IDA中,查看调用这个函数判断文件类型的地方。
signed int __fastcall cocos2d::Image::detectFormat(cocos2d::Image *this, const unsigned __int8 *a2, int a3) |
而调用这个函数的地方附近又是这样。
int __fastcall cocos2d::Image::initWithImageData(cocos2d::Image *this, const unsigned __int8 *a2, int a3) |
于是我们的目的就明确了——开发者魔改了cocos2d::Image::initWithImageData
加入了自己的文件格式,并在 detectFormat
识别格式时调用 isMpi
判断并指定输入文件是否为自己的私有文件格式,然后自己写了一个initWithMPIData
并在其中进行了解码或解密操作。我们要做的就是解析或利用这个函数的反向过程来解密图片资源。
以直接调用方式绕过资源加密
开始我尝试了用unicorn-engine模拟运行。但是后来发现函数里调用了malloc等标准库函数,处理起来很麻烦。IDA调试的选项也被我pass掉了,结合cocos2dx在CCImage.cpp中对图片的处理过程可知,内存里面存的是原始的RGBA数据,即使做出来内存dump也卵用无。折腾两天后决定利用NDK自己写一个wrapper,利用这个函数已导出的特性,从so里面获取这个函数并调用它来为我们解密。
我们先从已有代码入手判断一下Image类的结构。结合一下 CCImage.h 与 CCImage.cpp 中cocos2d::Image::initWithPngData
与其在IDA中反汇编的对应关系整理如下。
class CC_DLL Image : public Ref |
其中要注意,这里一定要打开IDA的Show casts
显示强制类型转换,例如*((_DWORD *)this + 6) = 4 * v5;
这一句中实际被赋值的成员变量的偏移量不是6个字节而是6*DWORD=24字节。
我们据此编写这个对象的测试用例
class Image { |
经NDK编译在armv7设备上运行结果如下(如果编译遇到缺标准库问题,在Application.mk里指定一下GNU C++运行时[6]即可)
Image layout: |
bingo~由于里面的成员变量都是int或指针一类的东西,所以不怎么需要考虑对齐的问题[7]。如果有问题的话参考一下下面参考资料里的ARM文档。
然后就是编写程序了。C++类成员函数在编译时被mangle成一个乱乱的字符串,在IDA里或objdump都可以获得,原样拿来并用dlsym寻找函数指针,用我们伪造的Image类作为第一个参数的this指针调用即可。至于如何将Image对象的内容保存为png,这个就留给大家作为思考题,方法是类似的。伸手党我们都是拒绝的。
注意,这里没有写但是我已经提前分析过我们要调用的函数对Image类的读写状况,对成员变量的所有操作都是先写入再读取,不存在未初始化的情况。如果大家要用类似方法调用其他函数,也要注意传入的数据成员的值。
|
push到手机上运行一下。顺便一提,1.out.png和1.png的大小是完全一样的。说明这个算法完全可逆。就是我懒而已……
$ ./decrypt assets/res/photo/imgs/normal/1.png |
OK,然后用shell脚本批量处理一下就可以把所有文件都解密掉了。接下来我们要做的就是,将每个图片与他的角色匹配起来,顺便看一看能不能挖掘出其他的信息。
LuaJIT探幽
这是一个三国题材的游戏,我们搜索关键字“赵云”,定位到类 app.data.db.cardDef 。这里再赞一下LLT,kgc和knum信息都是官方工具无法dump出来的。而官方文档[8]又晦涩难懂(还一堆TODO干脆就是没写完),稍微好一点的教材就是LLT对字节码解析过程的源代码[9]了。
在这里就结合一下例子来解释一下 LuaJIT 生成的二进制文件格式。看最左边的hex与右侧的数字注释
1b 4c 4a 02 | Header LuaJIT 2.0 BC | 1 |
- 3 bytes固定头部"\x1bLJ",第四位
02
是bytecode版本,01
为LuaJIT 2.0,02
为LuaJIT 2.1。2.1版本目前没有官方文档,只能从代码略窥一二。区别见参考资料[2:1]。 - flags定义参考LLT源码bytecode.lua[9:1]
- 用ULEB128表示的不定长数字开始一个“节”(prototype,相当于一个函数定义)并指定节的长度,若读到0则认为文件结束。
- flag参考同上,1byte
- 参数数量,1byte
- 栈帧大小3 猜测与内存分配相关,1byte
- 此处四个数字分别为:
- uv: Upvalue来自调用者的变量,1byte
- kgc: 动态分配的变量数量(猜测,翻译是garbage collected?),可存储字符串(str*B指针)、数组(karray)或字典(khash),ULEB128
- kn: 常量,可理解为const,ULEB128
- bc: bytecode,汇编码条数(每条指令都是4bytes定长),ULEB128
- kgc格式:类型(字符串或数组/字典)1位,若类型为数组或字典。此处为
01
表示数组。- 数组/字典(ktab)格式,在kgc类型后紧跟的2bytes
- narray:存储的数组元素个数(可理解为Python中的*args)
- nhash:存储的字典元素个数(可理解为Python中的**kwargs)
- 紧跟一串ktabk按上面两个值来计数。一个数组元素一个ktabk,一个字典元素两个ktabk
- ktabk的类型在LuaJIT的lj_bcdump.h文件的
BCDUMP_KTAB_XXX
枚举定义中。int为03
,字符串为05
加上字符串长度。此项类型为ULEB128
我解释的比较概括,更准确的定义需要参考官方文档上的范式。
我们可以看见,字节码格式非常紧凑,几乎没有浪费什么空间。而且不得不说,写程序解析原始字节码比读取LLT输出的文本要容易得许多……所以我写了一个。
下面的脚本用于解析LuaJIT产生的文件并将其中的常量信息提取到一个csv文件中。
#!/usr/bin/env python3 |
得到类似下面格式的csv。表头被我删去了。太长,丑。但是下面这一串信息里面已经包含了绝大多数我们可能需要的信息,包括角色攻击力、生命值、售价、技能ID、语音ID等等,甚至还有放大招的时候喊的口号。也有很大的潜力哦~
0,0,0,0,0,0,0,0,9,7,1,17,430,75,327,327,327,1,1,1,14500,14500,14500,65,0,2000,5,0,6,1250,0,90,240,道为核心 天道无为 道法自然 且善且行,3273,3,60,30,100,150,45,5,327,136,Y01,249,255,481,3272,130,1400,130,梦里繁花,3,75,左慈,0,0,0,0,35,240,5,0,0,3273,23,24,24,0,0,1,1,1,0,0,149,290,5,5,0,0,0,0,0,0,0,0,0,6,6,100,45,0,0,0,350,45,0 |
搜索一下文首配图的文件编号2308,找到大概在关羽那行的第……呃……58列。当然这列有名字就叫icon,而名字顾名思义列名就叫name。继续祭出python把解密输出目录中所有名字中含编号的文件批量重命名。
import csv |
大功告成!
这部分是弄完了,但是学无止境嘛~好了我学PIL去了,再把图切切剪剪做个卡牌合集去(逃
防护措施
- 加壳反制静态分析。
- 不要导出敏感函数。
- 增加加密函数上下文依赖性。(划重点)
- 混淆。(有成熟方案吗?)
参考资料
扒尽手游的底裤——Cocos2dx与LuaJIT完全解密