深入解析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的形式；然后结合反编译器进行反编译修改等等；

三、Lua保护的加强

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

使用脚本的保护的算法的选择？

对于虚拟解释器中的符号怎么进一步的消除掉？

怎么让开发者尽可能的接入方便？

对于保护的强度上我们应该怎么进一步的考虑?

3.1算法的选择性

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

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

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

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

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

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

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

在对Lua源码混淆处理的时候，可以对luac以及luajit对应的反编译工具进行对坑，由于部分攻击者不是很懂反编译的原理，加强使得攻击者不能反编译；

由于Lua自身语法的灵活性，可以对于Lua本身的格式进行自定义化，同时修改对应的解释器部分，这样攻击者就不得不分析自定义的格式以及对应的解释器部分，加大分析的难度。

综上所述，如下图所示：

四、总结

在游戏开发领域，Lua与C++、C#的组合带来了十分强大的功能，但也难免存在被破解的风险。

安全攻击常常以代码为目标，达到破解软件的目的。在导致泄露的网络安全“短板”中，代码安全是最本质、最核心的问题。

不可否认的是，在数字经济时代，对于科技企业而言，代码既是著作权的一部分，也是核心商业机密之一。核心代码一旦泄露,导致软件的核心技术外流，这对于企业几乎是致命的打击。

黑客在砸壳、逆向之后，“裸奔”的代码就面临全部暴露的风险，增加加密算法十分有必要。

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!