lua保护的前世今生

一、背景

lua作为小巧的解释性语言，由于其轻量级，易维护性，且可以根据自身的特性来模拟面向对象，因此嵌入到越来越多的应用中，特别是游戏中，为游戏开发以及热更等带来了很大的便捷性，比如Cocos引擎的主流游戏，以及U3D游戏中的热更框架xlua等，都会用到lua语言；

同时由于lua语言自身的这些特性，lua代码本身是不安全的,很多时候攻击者可以获取lua源码进行阅读，分析，盗用以及篡改等，然后进一步的重打包等，给游戏本身带来了很大的安全隐患。接下来我们一起了解一下目前lua是怎么保护以及我们应该怎么进一步的保护lua代码？

二、lua现有的保护

对于这种脚本解释性语言，从代码保护的角度跟它自身所表现的形式是密不可分的，对于lua而言，目前市面上手游包中可以看到的主要是lua源码，luac，luajit三种的表现形式，接下来会详细的介绍每一种形式以及自身现有的保护以及所暴漏出来的优缺点；

2.1lua源码

目前市面上用到lua源码本身在游戏中呈现的并不是很多，但是在一些热更下发中会比较多；因此从源码保护的思路会很容易的想到针对lua源码本身进行混淆保护的方案；目前市面上针对lua源码进行混淆的厂家主要有以下这几家:

1. XFuscator：
2. Luraph:
3. Syanpse Xen:
4. Ironbrew:
5. Verdict: 

对于这种基于源码的混淆，优点是是lua经过处理以后更加的复杂化了，增大了攻击者进行分析的成本和难度；由于攻防升级，对于上面的混淆也有相对的反混淆处理方式。同时混淆除了自己混淆本身所表现出来的兼容性问题以外，对于开发者也有以下这几个问题：

1.同一段代码的混淆在不同时间进行混淆，所得到的混淆效果是不同的：

由于混淆器为了增大混淆的程度和难度，里面会有随机的代码要进行热更，热更的时候会进行比较，这样没办法进行热更处理；

2.针对lua语法混淆的兼容性问题：

由于lua语法的灵活性，因此去混淆处理的兼容性问题比较多；

3.开发者接入问题：

对于开发者而言进行接入以及出现问题跟第三方进行沟通解决的成本比较大；

2.2luac的形式

  luac是作为自己的语言的字节码格式，与其他脚本语言python等虚拟机中所表现的出来是一样的，等lua加载到内存中以后，虚拟机会加载对应的字节码，由于lua主要有5.1、5.2、5.3三个版本，因此也会有对应的三个格式的luac版本,目前在手游中主流是5.2的版本；

虽然说luac不会以源码的形式出现，但是由于lua字节码的执行以及格式可以根据在lua源码中进行探知到，比如luadec反编译工具，因此luac形式还是不安全的。目前市面上对于这种保护主要有三个形式：

2.2.1：luac的加密

从lua的虚拟机源码处可以得知在luaL_loadbuffer函数会加载lua，因此有安全意识的厂家会对lua进行加密。修改这个源码，在真正的执行前进行解密；

但是由于虚拟机的执行过程是开源的，并且由于cocos工程编译处理需要静态链接对应的引擎库，这样对应的引擎so文件是有符号的，因此对于攻击者来说，在luaL_loadbuffer函数处可以进行内存的DUMP得到正常的字节码，然后使用反编译工具进行处理，进行进一步的修改；

2.2.2：修改lua虚拟机中opcode的顺序

对于lua这种解释性语言，无论是虚拟机还是对应反编译工具都是有一个固定的opcode的顺序，有意识的安全厂商会通过修改对应的opcode的顺序进行保护，如下图所示：左边是正常opcode的顺序，右边是进行随机化以后的opcode的；

这样从新编译处理完以后的luac可以看到如下图所示：对应的opcode是不一样的；

opcode不一样以及对应的解释顺序是如下：

目前对于这种自定义修改opcode的处理方式，目前攻击者可以根据通过目标虚拟机加载lua文件跟正常虚拟机编译的luac进行对比“吐出”对应的映射表，然后进一步的借助于反编译工具进行反编译处理进一步的处理；

或者由于lua自身的opcode不是很多，如上图所示可以很轻松的定位到正常的执行顺序；因此这种处理方式也不是很安全的；

2.2.3：对于lua的虚拟机执行过程进行保护

可以看到有的游戏厂商对lua虚拟机进行安全编译处理，也就是复杂化整个虚拟机的解释流程，这种做法其实“治标不治本”；

类似如下图所示：左右是相同功能的一个函数，只是右边是经过安全编译器处理的：

对于上面这种处理方式存在的两个问题：

一是由于lua本身是开源的，经过安全编译处理完以后，对应的符号还是存在；攻击者很容易的定位；

二是对于攻击者而言其实不用太关心中间的虚拟化解释执行过程，因此从整个保护的角度来讲，实质性作用不大。

2.2.4小结：

目前的以luac为主要表现形式的游戏厂商主要是对于上面三种保护的综合使用，但是经过分析可以看到从根本上没有起到一个好的作用，只能阻止部分初级的攻击者，对于真正的攻击点的保护没有抓住。

2.3luajit的形式

由于考虑到lua的执行效率问题，luajit诞生了，从名字上可以看出，luajit是Lua的即时编译器生成的,一个用手写汇编实现的Lua解释器和一个可以直接生成机器代码的JIT编译器；根据dynasm动态生成buildvm_xxx.h的文件，进一步的解释执行；

目前很多的游戏厂家，为了进一步的保护游戏中的脚本，将lua处理为luajit的格式，对于luajit而言，也有对应的反编译工具，ljd或者luajit-lang-toolkit或者luajit-decomp，因此进而一些游戏厂商在经过luajit形式以后会进行加密处理；

借助于cocos自带的加密，大部分的厂商会通过如下设置自己私有的key和sign值；

以及调用对应的XXTEA的加密算法，可以看到经过加密以后得到如下的luajit的编码形式：

面对上面这种加密的处理方式，解密也非常的简单：

一是可以使用HOOK在关键的函数处进行内存DUMP；

二是也可以通过反编译代码，如下图所示为某知名游戏对应的key和sign值，然后调用XXTEA进行解密可以得到标准的luajit的形式；然后结合反编译器进行反编译修改等等；

如何加强？采用luajit的分块加密思想

三、lua保护的加强

通过上面对于lua、luac、以及luajit的保护以及逆向的角度来看，要想真正的去保护lua游戏，可以从以下几个角度出发：

1. 使用脚本的保护的算法的选择？
2. 对于虚拟解释器中的符号怎么进一步的消除掉？
3. 怎么让开发者尽可能的接入方便？
4. 对于保护的强度上我们应该怎么进一步的考虑?

3.1算法的选择性

目前很多的游戏厂商通过Quick-Cocos2dx或者cocos自带的算法,以XXTEA这种为代表进行加密处理，包括对于脚本以及zip包等等加密，这样使得攻击者也能够轻意的去利用这些算法完成解密等操作；因此算法的设计越”私有化“越好，这样可以在第一个层面上做到防止攻击者进行静态的还原脚本；

3.2消除虚拟解释器中的符号

通过上面可以看到无论是自定义opcode解释器还是使用安全编译器处理lua虚拟机，这其中存在一个问题，由于静态链接的问题，符号表是暴漏的，符号表的存在为攻击者提供了丰富的分析线索 ，因此可以对lua的虚拟机解释引擎进行加壳处理，不仅仅能够保护上面的私有化解密算法，同时符号的消除使得攻击者很难得进一步去分析。做到了第二个层面上的保护，同时有了壳以后会对游戏周围的可疑环境进行检测，比如上面提到的HOOK等；

3.3让开发者尽可能的接入方便

比如上面提到的对于lua在混淆处理的时候，尽可能的考虑到开发者的功能业务，是游戏的逻辑业务还是热更？否则像上面提到的基于源码的混淆，每次的随机化会导致事倍功半；

3.4保护的强度上应该怎么进一步的考虑

从上面的分析过程可以看到这里面我们从以下这几个角度进行强度上的加强：

1. 在对lua源码混淆处理的时候，可以对luac以及luajit对应的反编译工具进行对坑，由于部分攻击者不是很懂反编译的原理，加强使得攻击者不能反编译；
2. 由于lua自身语法的灵活性，可以对于lua本身的格式进行自定义化，同时修改对应的解释器部分，这样攻击者就不得不分析自定义的格式以及对应的解释器部分，加大分析的难度；

综上所述，如下图所示：