一是可以使用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#的组合带来了十分强大的功能，但也难免存在被破解的风险。
安全攻击常常以代码为目标，达到破解软件的目的。在导致泄露的网络安全“短板”中，代码安全是最本质、最核心的问题。
不可否认的是，在数字经济时代，对于科技企业而言，代码既是著作权的一部分，也是核心商业机密之一。核心代码一旦泄露,导致软件的核心技术外流，这对于企业几乎是致命的打击。
黑客在砸壳、逆向之后，“裸奔”的代码就面临全部暴露的风险，增加加密算法十分有必要。
