1.关于Cocos2dx-js游戏的球源球游jsc文件解密
2.js编写的小游戏有哪些
3.为什么cocoscreator不选择兼容c#,而是只有js?
关于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进行深入研究，重画k线源码发现导出函数名清晰，没有添加额外的安全手段。通过搜索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文件，并拷贝到内存中，变异macd指标源码游戏开始调用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版本的文件加解密需求，并提供较为简单的操作方法。同时，欢迎各位分享自己的解密方法和见解，共同推动社区的发展。
js编写的小游戏有哪些
有是有，但并不是很多，而且都是超短线源码贪吃蛇之类的，非常小的游戏，即便是页游也一样。
能运行在浏览器端的语言，确实只有JS，但在开发阶段，却并不一定要使用JS写。而是用其他语言写，直接使用JS写游戏，实在太自虐了。
JS本身的缺点非常严重，如果只是写DOM的话，其实并没什么感觉，因为代码量太少。
但如果写类似游戏这种复杂逻辑，代码量一变大，瞬间就令人崩溃了。弱类型，回调地狱问题，即便将来版本更新到ES，也不可能完全解决。
如果你看过一个游戏项目的JS源码，你会发现一个非常恐怖的现象。在代码的最底部，有几百个，甚至几千个大括号。。源码上传空间哪里。。所有大型程序的JS源码，拉到最底部，大概都是长这个样子的：
} } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } }.Listen(.0.0.1) } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } } }
大括号的数量还必须绝对精准，少一个，或者多一个，都无法正常运行。。。这就是平时所说的回调地狱。由于JS项目总是函数里面套函数，层层相套，这叫做回调函数。层数一多，就算你是N年的老手，也照样懵比。。。。
所有的游戏项目，都比网页特效的代码量要多的多。。。比如写一个斗地主，就需要4，5万行的JS代码。。。。。最底部的大括号数量，轻松上千。。。。
弱类型的缺陷更严重，但由于解释起来篇幅会很长，所以这里就不提了。
所以为了避开JS本身太多的语法缺陷，一般游戏项目，都是使用其他语言编写，最后再通过一些手段，编译成JS。。。就如同你用一般编程语言编写，最终运行的时候，只有1和0的道理一样。。。在制作页游的时候，一般都是用强类型语言编写，最后开发完成之后，把那些强类型语言编写的代码，通过一些手段“转换”成JS代码。
“转换”成JS代码的方法有很多，其中在游戏行业比较主流的，一共有三种：
1，ActionScript语言，简称AS语言。也就是当年FLASH使用的那个语言。。。当年也曾辉煌过，后来随着FLASH的没落而逐渐没落。。。但有很多H5游戏引擎，也同样使用AS语言。比如LayaAir引擎等。
2,TypeScript语言，简称TS语言。由微软出品，微软和谷歌共同维护的一门完全符合ECMA标准的语言，可以视作JS的超集。超集这个概念怎么理解呢？就是“所有的JS语言，同时也是TS语言，而TS比今天的JS，更像未来的JS”。就比如目前的JS版本只出到了ES6或ES7。那么ES是啥样？现在并没人见过，连ECMA组织也不知道。。。但有一点可以确定的是，它和TypeScript长的很像。而TS是包含JS的。换言之，JS本身也可以视作是TS的一部分。只是TS里的内容要远比JS多的多。这语言主要有两种用法，一是像AS语言一样结合游戏引擎，比如cocos creator，白鹭等引擎都支持。还有一种用法就是。。。结合Three.JS之类的库，完全按照JS本身的用法去使用。
3，C#语言。虽然JS得名字里面带个Java。但和它长的最像的语言，却并不是JAVA，而是C#。简单说就是：“JS的名字和JAVA有多像，语法就和C#有多像”。所以C#也比较容易转换成JS。但这并不是重点，重点是有一个超级牛的游戏引擎，是使用C#作为开发语言的。就是大名鼎鼎的Unity3D。Unity3D可以直接把C#编写的游戏项目，虚拟现实项目等，编译发布到WebGL。
为什么cocoscreator不选择兼容c#,而是只有js?
CocosCreator选择JavaScript而非C#作为脚本语言，基于其Web技术和开发背景。作为基于Web的工具，CocosCreator与JavaScript的结合非常合理。其JavaScript分支已经存在，重新开发另一种语言没有必要。而Unity选择C#，是因为Mono运行时作为引擎核心底层与应用层脚本间的粘合剂。Mono支持包括C#在内的多种语言，如Python，这决定于Mono的兼容性。然而，浏览器无法直接运行C#，而类似NW.JS这样的Web容器虽能调用C++原生代码，但这样操作并未带来实质性的价值。
关于JavaScript问题，Unity引擎中的JavaScript实际上是一个子集，其本质与C#、Boo等语言相似，都是Mono支持的语言。这说明Unity中的JavaScript与浏览器中运行的JavaScript完全不同。若希望在浏览器中直接运行C#，这在语言本身和运行原理上均无法实现，因为C#需要编译为中间语言（IL），再由CLR转换为机器码，与Web环境不兼容。
综上所述，平台特性和语言特性决定了CocosCreator最合适的语言是JavaScript。选择JavaScript与CocosCreator的Web技术背景紧密相关，且现有JavaScript分支的存在，使得无需重新开发语言。Unity与C#的搭配基于其对Mono的依赖，而Mono作为跨平台的运行时，支持多种语言，包括JavaScript。