Bot.js Pro加密说明

更新: 2025/7/20 字数: 0 字 时长: 0 分钟

Bot.js Pro支持在打包时对js文件进行加密，加密是通过多种方式将源码编译、加密为非明文文件。

注意: Bot.js Pro的加密并不包括对代码的混淆，建议在使用自带加密前再用其他混淆工具对代码进行一次混淆。可配置编译脚本在打包时自动执行混淆，具体可参考Pro 9.2.9以上版本中的示例 -> 项目与打包 -> 代码混淆。

加密方式

由于Bot.js Pro目前有两个引擎 ———— 旧引擎Rhino和新引擎Node.js。Pro 8以前的代码均是使用Rhino引擎，在Pro 9则可在文件最前面增加”nodejs”来使用Node.js引擎，同时启用全新的异步API（具体参见Pro 9文档）。

每个引擎的加密实现方式有所不同，破解难度也会有所区别。在打包时可选择不同的加密等级，这里将说明不同加密方式的区别。

encryption-levels

Node.js加密

还原难度：⭐️⭐️⭐️⭐️⭐️

Node.js引擎目前只有一种加密方式，因此无论选择哪种加密等级结果没有不同。Node.js加密的还原难度较高，推荐使用新的Node.js引擎来编写你的代码，文档参见第二代API文档。

目前Node.js加密方式暂不支持mjs文件/ES Module，这些文件不会被加密，预计在9.5版本支持。

使用Node.js加密后运行错误，请先使用不加密方式打包，若加密后报错不加密正常，则可能是以下原因：

模块文件未被识别为nodejs文件，被使用Rhino引擎方式加密，导致无法运行。

比如主模块文件是main.node.js，require了另一个模块文件mod.js，但是mod.js文件既没有以.node.js结尾，也没有用"nodejs";文件头，因此在加密时被当成非nodejs文件使用快照、dex等加密方式加密。运行时自然会报错。

有两种方式解决：

• 所有nodejs文件，都以.node.js结尾，或使用”nodejs”;`文件头
• 在project.json中，配置"type": "node"，则项目下的所有文件默认是nodejs引擎（此时rhino引擎的文件需要加上"rhino;"的文件头）

node_modules下的文件未被识别为nodejs文件，被使用Rhino引擎方式加密，导致无法运行。

原理同上，推荐在project.json中，配置"type": "node"来解决这个问题。配置后项目下的所有文件默认是nodejs引擎，此时rhino引擎的文件需要加上"rhino;"的文件头。

在64位手机上加密，在32位手机上运行

Node.js加密暂不支持跨CPU架构加密，因此只能在64位手机上加密只能在64位手机上运行；在32位手机上加密，CPU架构选择armeabi-v7a，则可以在64位、32位手机上运行。

Rhino普通加密

还原难度：⭐️

这种加密仅仅是将文件用某种方式加密，运行时需要解密，比较容易被还原。

Rhino Dex加密

还原难度：⭐️⭐️⭐️

这种加密方式将js文件编译为dex文件，一方面提升运行效率，另一方面提高了破解门槛。但dex本身仍然能看出代码逻辑，推荐再使用加固或dex2c等方式进一步保护代码。

Rhino Snapshot加密

还原难度：⭐️⭐️⭐️

这种加密方式将js文件编译为字节码文件，提升了运行效率和破解门槛。但字节码文件中的字符串等仍然为明文，因此不管使用什么加密，都推荐先使用混淆工具混淆。

高强度加固的 SO 模块（不可逆性强）

还原难度：⭐️⭐️⭐️⭐️⭐️（几乎无法反编译还原）

为防止核心逻辑被逆向解析，可将关键功能使用 C++ 实现，并通过 NDK 编译为 .so 动态链接库。通过 Java 或 JS 接口调用此模块，即可将业务核心与脚本层彻底隔离，大幅提升安全性与抗破解能力。

具体实现方式可参考 # C++→SO 编译与调用（JNI）

加密时或加密后遇到错误

若加密过程遇到编译错误，可能是因为项目中包含web但js文件，这些文件也被参与加密导致。可以通过ignore文件将其排除加密范围，具体参见项目与配置。

⚠️ 特别注意：若你使用的是第一代 API，建议所有变量统一使用 var 进行声明，避免使用 const 和 let。 这是因为旧版本 API 对块级作用域支持不完善，const 和 let 可能在加密还原后引发运行时错误。