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

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

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

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

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

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

对于游戏B，虽然Key值不像游戏A那样明文显示，但通过搜索附近的字符串，我们发现可疑的Key值与常规的Cocos Game字符串共存。尝试使用此Key值解密游戏文件，同样取得了成功。对比游戏A和游戏B的关键代码，我们发现密匙都在applicationDidFinishLaunching函数内部体现。此函数在Cocos2d-x应用入口中，当应用环境加载完成时回调。理解CocosCreator构建项目的过程后，我们知道游戏应用环境加载完毕后，该函数内部将Key值传入解密函数中，解密函数将jsc文件转换为js文件，并拷贝到内存中，游戏开始调用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.44，它能够满足当前Cocos2dx版本的文件加解密需求，并提供较为简单的操作方法。同时，欢迎各位分享自己的解密方法和见解，共同推动社区的发展。

二、cocos2dx+lua合适还是cocos2dx+js合适

1、在讨论Cocos2d-x与Lua或JavaScript的结合时，重要的是理解工具的适用场景与个人团队的偏好。Cocos2d-x团队确实同时全力支持JavaScript和Lua绑定，不存在亲儿子问题。语言之争由来已久，程序员的选择往往基于他们对语言的热爱与偏好。作为工具开发者，不应有优劣之分，而应以用户利益为核心。

2、基于公司内部经验，我们倾向于使用JavaScript binding。对于快速、规模较小的游戏项目，Lua因其简洁性与易用性，是理想选择。然而，对于周期较长、需要持续维护和更新的项目，JavaScript binding提供更强大的功能与灵活性，更适合。

3、Lua作为一种高效、轻量级的脚本语言，广泛应用于游戏开发，尤其在魔兽世界插件开发中表现突出。Cocos2d-x团队对于Lua的支持可见一斑，从网龙贡献支持到廖大的持续贡献，乃至专门团队的建立，表明Lua在Cocos2d-x生态系统中的重要地位。

4、JavaScript，作为前端开发的主流语言，与Cocos2d-x结合后，提供了一种跨平台开发的强大能力。虽然Lua在特定场景下表现出色，但在一些细节上，JavaScript绑定在Cocos2d-x内部项目中的应用更为深入。随着公司内部对Cocos2d-x JavaScript Binding的深度优化与定制，我们解决了实际开发中的问题，并逐步完善API，为用户提供更流畅的开发体验。

5、考虑到安全性、效率与嵌入第三方SDK等方面，Cocos2d-x JavaScript Binding与Cocos2d-HTML5的结合，不仅满足了跨平台需求，也提供了与Web App交互的能力，实现了“一次编写，多平台运行”的理念。

6、我们深知社区与开源合作的重要性。通过持续的社区贡献与技术支持，我们不仅推动了Cocos2d-x的发展，也鼓励开发者共同前进，共享知识与经验。选择合适的工具与方案，同时积极参与社区建设，是实现项目成功与个人成长的关键。

7、对于Cocos2d-x JS Binding的使用经验，我们发现，大部分开发与调试工作可在浏览器环境中完成，而当需要在手机上测试时，只需将JavaScript代码移植到对应平台的工程中即可。这种工作流程大大提高了开发效率，尤其对策划团队而言，在网页上进行调整更为便捷。

三、egret 和cocos2d-x-js哪个目前更稳定更好用

如果大型游戏，强烈建议不要使用cocos2d-js

我们目前的几个项目都是cocos2d-js开发的，我打算把这几个项目转egret。有如下几个理由：

1、cocos ide有BUG：断点会崩溃、代码提示很差、内存太高、虚拟机的菜单栏会影响事件（迭代了很多版本，这菜单栏BUG都没修复）

2、studio的工作流在几个引擎中是最差的，而且有BUG。经常和实际表现不一致。而且内存占用大，会崩溃。不能继承（这个问题最严重，不能继承按钮，那么按下缩放等高级功能就很蛋疼）。

架构太差。写点小功能没事，如果想写大型游戏，这套架构会让你抓狂！比如最简单的按钮事件，我必须在事件方法里面加个触摸类型判断。一个很简单的点击，就

多出很多这种相似的代码！4、UI有好几套，然而每一套都有BUG。CCUI的设计也是很糟糕的！同时也是崩溃的罪魁祸首。

很多BUG会让你欲哭无泪，比如坐标会出现undefined。再比如热更新的BUG，XCODE编出的包默认是js而不是jsc，当这个包发布商店就会

出现不能热更新的问题，同时也进不去游戏，卡在了热更新界面。（这个问题导致我们流失了3个月的用户，知道苹果商店通过审核位置），再比如

java/objectc和js的交互，这个都有问题！再比如：ios第三方输入法会导致崩溃！

6、工作流问题，IDE的断点的观察变量很不友好、studio导出的配置很大、studio扩展性很差。在IDE 1.2版本出来之前，我们团队甚至无法断点，只能打印日志来debug。

7、工作效率问题，代码提示先不谈。我实现一个简单的列表都能折腾很久，那ccui的list真是太不好用！除此之外，裁剪、遮罩这些只需要一行的代码，在cocos下面需要无数行！

引擎升级问题：cocos大概一个月1个升级，egret是2周。然而cocos升级会带来大量的新BUG，而且兼容性很差。导致我们现在还用3.0版

本。最蛋疼的是，官方的3.6版本又不能断点了！3.0升级到3.6还会导致布局混乱、九宫失效、崩溃闪退（绝对不是代码问题这个解释了）！基本上

cocos每加个新功能都会带来无数新BUG，老BUG修复量也少，我论坛反馈的问题经常需要迭代2到3个版本才修复，下个版本修复兼职是不可能。而

egret不仅迭代快，BUG修复也勤快！也很少有一些导致产品质量的验证BUG。

9、官方人员态度问题：我在cocos论坛发的BUG反馈，过了7天才有人来回复。地址（从3.0到3.1和3.2的BUG，官方帮忙看下），再看下egret我发的BUG反馈，当时是下班时间，然而第二天一早就回复我了。地址（Egret社区-BUG列表）

10、API问题：cocos经历了3个大版本，官方API文档也有的API，实际尽然是没有的，官方回复是还没加入js绑定。

11、跨平台问题：cocos2d-js经常是HTML5和JSB表现不一致。导致我们现在只能专注JSB而放弃HTML5版本。egret很少有这个问题。

性能问题：先抛开runtime。如果你用了ccui，那么我100%保证你的cocos2d-js的性能会被egret秒杀。再来说下native下面

的性能对比，cocos的人说egret是js写的逻辑，而他们是绑定。那么问题来了，在现在，js的逻辑产生的性能压力一点都不是问题（参考

node.js，能用js写服务器了都）。主要的性能压力其实是在渲染上面，而他们2个都是opengl作为渲染的。如果用了ccui，那么还是被

egret秒杀。那ccui带来的drawCall真是太！！再来谈runtime，egret现在很多浏览器都集成了runtime（可以opengl

渲染代替canvas渲染），而cocos-js只是说在合作，已经慢了一步。

13、产品路线图问题：cocos的几个产品一心在弄3D，egret都已经自己搞了一个IDE了。开发基本的生活cocos都没保障好，就去想和u3d打架！

14、内部问题：cocos估计内部很不和谐，ide据说是1个人在开发，studio是30个人（30个人整出这东西），而且studio是用的.NET搞的，跨平台最呵呵的技术！QT、AIR那些那么多高效率，扩展性强的技术不用，选了个.NET。。。。

---------------------------------------------------------------------------------------------------------------------------------

外话：说了那么多cocos的不是，我也曾试着爱过它，我甚至开发了一个和egret

wing一样的UI编辑器，写了个和Flash/Flex一样的API（egret用的这套，这种架构很好用，简单明了）。其中UI编辑器还加上了

unity3d那种绑定脚本的功能。然而因为cocos底层的一些令人发狂的BUG，我最终是放弃了。有egret这个车子在，我还造什么轮子？我打算把

手里头的这套cocos的东西开源。然后去整egret去！

---------------------------------------------------------------------------------------------------------------------------------

个是百度搜索第一的对比，里面说cocos2d的工具比egret多，我不否认，但是能用的基本没有。而egret的工具很稳定。就拿最简单的骨骼动

画，cocos连龙骨都不支持，studio里面的骨骼设计也是坑的不行，egret的骨骼设计工具从界面和实用性都已经完爆studio了！

再来说上面的地址里面的成功产品：捕鱼达人、DOTA传奇、我叫MT那都是cocos2dx写的，和js版本一点关系都没有！请问你有见过网页版的刀塔传奇么？

上面的开发语言对比，大项目来说，ts真的是完爆js！js那不小心就会出错真心不适合大项目，不然微软不会造这个轮子。

上面的参考资料对比，cocos2d-js的文档连参数的注释都没，和c++文档作参考也不行，很多参数是不一致的！而egret在开发工具里面就继承了中文的帮助。

从目前状况看，今年绝对是egret产品井喷的一年，不信走着瞧！cocos真是把我坑惨了！

---------------------------------------------------------------------------------------------------------------------------------

次申明，请拿cocos2d-js或者JSB的大作出来，不用拿2dx的东西。说到2dx，你们再去了解下，榜单上，有几个人是没改过引擎源码的，有几个

游戏能随着cocos引擎升级而升级。用studio的又有几个。并不想和王哲斯逼，只是希望你们能正视BUG，提高体验。如果好，我们团队会考虑

cocos技术的，否则只能用egret和unity3d了。我说cocos这么多不是，也是希望他成长，能给开发者带来更多利益，带来更多方便，而不是

各种无厘头的问题，各种蹩脚的手段去开发。还有，我说的这几点，@王哲

你接招，如果我不说出这些BUG，这些问题，那么估计还不一定改。egret同样有个人叫王泽，然而他的理念完全当我们开发者是用户，提高开发体验，这个