1.cocosjs Դ??
2.关于Cocos2dx-js游戏的jsc文件解密
3.Cocos2dx-JS3.0升级中的build.xml去哪儿了
4.为什么cocoscreator不选择兼容c#,而是只有js?

cocosjs Դ??

       要先用cocos编辑器执行安装cocos的提示，安装好了里面会生成cocos.d.ts的文件，就会有提示了。

       安装 Cocos Creator API 适配插件

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

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

       首先，源箱源码我们通过CocosCreator开发工具构建并编译一个案例js工程，发现游戏中存在脚本加密选项。构建后，得到一个简单的样本APK。在APK中，我们通过Jadx-gui工具解析Java层源码，关注assets目录下二进制源代码的redis阅读源码加载情况。在入口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值，并发现一个可疑的开源码头参数v，用于解密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.，它能够满足当前Cocos2dx版本的文件加解密需求，并提供较为简单的操作方法。同时，欢迎各位分享自己的解密方法和见解，共同推动社区的发展。

Cocos2dx-JS3.0升级中的build.xml去哪儿了

       å› ä¸ºçŽ°åœ¨æœ‰äº†cocos console嘛，所以创建出来的工程都是动态的，build.xml只有在release模式的时候才会用到，用来做google closure compiler的混淆，所以我们现在由引擎自动处理，只需要在工程目录下输入 cocos compile -p web -m release就会在项目根目录下面创建publish/html5文件夹，这个文件夹是独立的publish项目，里面会有一个自动生成的build.xml，有需要修改的话可以直接修改这个

为什么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。