1.关于Cocos2dx-js游戏的游游戏源码jsc文件解密
2.前端开发Lua篇——LuaJIT

关于Cocos2dx-js游戏的jsc文件解密

       上期关于Cocos2dx-js游戏的jsc文件解密教程引发了一些疑问，本文将解答一些常见问题。戏源

       首先，交易我们通过CocosCreator开发工具构建并编译一个案例js工程，游游戏源码发现游戏中存在脚本加密选项。戏源构建后，交易源码菜鸟得到一个简单的游游戏源码样本APK。在APK中，戏源我们通过Jadx-gui工具解析Java层源码，交易关注assets目录下二进制源代码的游游戏源码加载情况。在入口Cocos2dxActivity的戏源onLoadNativeLibraries函数中，我们找到了加载libcocos2djs.so文件的交易步骤，该文件位于AndroidManifest.xml中。游游戏源码

       初步分析显示，戏源java如何替换源码加载Assets目录资源的交易操作不在Java层进行。接着，我们参考“jsc反编译工具编写探索之路”一文，将注意力转移到libcocos2djs.so文件上。在Cocos2dx源码中，我们发现其使用的是xxtea加密和解密算法，与Cocos2dx-lua的加密解密过程类似。

       在游戏实例分析部分，我们以两个游戏案例为例进行解密。对于游戏A，通过十六进制编辑器搜索libcocos2djs.so文件中的Cocos Game字符串，未发现相关信息。使用IDA分析工具对libcocos2djs.so进行深入研究，源码做直装发现导出函数名清晰，没有添加额外的安全手段。通过搜索xxtea / key相关函数，我们找到了几个相关函数。在jsb_set_xxtea_key函数中，我们尝试直接设置key值，并发现一个可疑的参数v，用于解密jsc文件。通过回溯该函数的调用路径，我们成功获取了Key值，并成功解密游戏文件。

       对于游戏B，虽然Key值不像游戏A那样明文显示，沧澜沉默源码但通过搜索附近的字符串，我们发现可疑的Key值与常规的Cocos Game字符串共存。尝试使用此Key值解密游戏文件，同样取得了成功。对比游戏A和游戏B的关键代码，我们发现密匙都在applicationDidFinishLaunching函数内部体现。此函数在Cocos2d-x应用入口中，当应用环境加载完成时回调。理解CocosCreator构建项目的过程后，我们知道游戏应用环境加载完毕后，该函数内部将Key值传入解密函数中，解密函数将jsc文件转换为js文件，并拷贝到内存中，盒马app源码游戏开始调用js文件，进入游戏界面。

       在其他关键函数的分析中，我们注意到在xxtea_decrypt函数中存在memcpy和memset操作，表明在进行内存拷贝数据。通过CocosCreator源代码jsb_global.cpp文件，我们得知传入xxtea_decrypt函数的第三个参数即为解密的Key值。因此，我们可以通过Hook libcocos2djs.so文件加载时的xxtea_decrypt函数来获取Key值。使用Frida框架编写简单的js脚本进行Hook操作，可以成功获取Key值。在获取Key值后，可以参照CocosCreator源代码实现解密逻辑，或者利用封装好的解密程序进行文件解密。

       最后，对于解密工具的选择，我们推荐使用一些已封装的加解密程序，例如jsc解密v1.，它能够满足当前Cocos2dx版本的文件加解密需求，并提供较为简单的操作方法。同时，欢迎各位分享自己的解密方法和见解，共同推动社区的发展。

前端开发Lua篇——LuaJIT

       三十六计手游采用LuaJIT实现游戏逻辑，但在特定场景下禁用了JIT模式。具体操作步骤如下：

       1. 首先，从LuaJIT官网获取与cocos2dx引擎版本一致的库文件。例如，针对cocos2dx版本号3.，需确保lua和jit的版本信息与库文件相匹配，避免因版本不一致而导致"cannot load incompatible bytecode"错误。

       2. 利用命令行工具进行编译。在mac操作系统中，直接执行"make"即可完成编译；对于win用户，需先配置VSCommandPrompt，执行参数为"/k \"C:\\Program Files (x)\\Microsoft Visual Studio .0\\Common7\\Tools\\VsDevCmd.bat\""，然后进入jit源代码目录并运行"msvcbuild.bat"进行编译。

       3. 使用"luajit -b"命令生成bytecode，此步骤生成的bytecode在runtime中通过interpreter模式运行。值得注意的是，jit bytecode生成后，行号钩子失效，可能影响基于行号的debug或profile操作，需要进行相应的调整。

       考虑到不同平台对JIT模式的处理，ios系统默认关闭JIT，而android则需通过"jit.off()"进行手动关闭。在游戏开发中，对JIT模式的使用需谨慎考虑，以避免可能的性能损耗。

       在禁用JIT模式后，游戏开发者可能会考虑使用luac而非jit的bytecode。然而，针对iOS禁用JIT、Android主动关闭JIT，以及可能面临其他平台不稳定情况，仍选择使用jit的bytecode具有以下优势：

       1. 减少体积，提高包体、内存、转化率和热更文件大小的效率。相较于luac，jit的bytecode体积减少了约%。

       2. 加速require代码时的load过程，性能提升达倍。在禁用JIT的环境下，性能特性与luac保持一致，无需对代码进行额外优化。