[开源] Chronos Seal v1.2.1 - 为 RPG Maker MV/MZ 设计的动态加密系统

Arrose

为什么要用bat

Singular_Photon

稍微翻了一下仓库，这东西本质上只是把原本的system.json给加密到根本拿不到实际内容的程度，但没去动RPGMV / MZ本身解密图像和音频的方式？

MV / MZ对图像的解密写得很呆。也不知道是开发那边粗心了没写循环还是为了尽量不影响加载速度，它只用system里面的加密密钥去对一张图片的前16个字节做了加密。加密的方式是把这个密钥XOR到上面去，顺便在整个文件的开头加塞了16个字节的垃圾数据（用来校验）。

然而绝大多数PNG的开头十六个字节是完全固定的：
89 50 4e 47 0d 0a 1a 0a - 识别PNG文件的固定头
00 00 00 0d 49 48 44 52 - 第一个数据块，文件头数据块。前四个字节是它的长度（因为整个块的内容都是固定的，总是13），后四个字节是块识别码IHDR。

顺带一提，音频加密走的是同一条路，也只加密了前16个字节，只不过OGG的头16个字节没那么固定。

在rmmz_core.js的Utils.decryptArrayBuffer里面可以看到这些解密过程。

于是乎有点心思的破解者根本无所谓能不能得到system.json，它随便找一张用RM默认的加密方法加密的png图像，把里面第17 ~ 32个字节（如果你喜欢从0开始数，就是第16 ~ 31个字节）拿出来和上述固定的PNG头做一下XOR，密钥就直接到手了。到头来好像还是没能成功保护资源文件呢。

不过只要把这个加密-解密的方式改一改（加密当然也得用对应的脚本，不能让编辑器干）其实就解决问题了。为了防止破解者看到加密算法把解密过程一起焊到decryptor.node里面就行。

CLAREXHL

Arrose 发表于 2026-9-1 11:41
为什么要用bat

写bat是因为不让你们自己跑C++

CLAREXHL

Singular_Photon 发表于 2026-9-2 13:39
稍微翻了一下仓库，这东西本质上只是把原本的system.json给加密到根本拿不到实际内容的程度，但没去动RPGMV ...

这个问题确实没考虑过 但也不是不能实现 只不过要在 C++ 层接管素材的解密 直接让解密逻辑不依赖 JS 层的 Utils.decryptArrayBuffer 但现在的话又不能再重构一遍项目了（因为再改就第三次了） 这个问题我会想想看 看看能不能放在V2.1里补上 感谢建议

CLAREXHL

Singular_Photon 发表于 2026-9-2 13:39
稍微翻了一下仓库，这东西本质上只是把原本的system.json给加密到根本拿不到实际内容的程度，但没去动RPGMV ...

简单说一下我的判断和后续计划：

V2.0 的目标是焊死 system.json，让游戏启动无法绕过它。 你指出的问题是 RM 引擎自带的素材解密机制存在结构性缺陷（只加密前16字节，PNG头固定可反推），这不是 CS 造成的问题，但确实是 CS 应该考虑的问题。

V2.1 的方向已经定了：不再依赖 RM 自带的素材加密，在 C++ 层接管素材解密流程。 具体来说就是让 StorageManager 加载素材时走 C++ 层解密，而不是继续用 Utils.decryptArrayBuffer。这样密钥管理就完全纳入 C++ 体系，JS 层不接触任何敏感数据。

至于会不会卡：解密运算只是前16字节的 XOR，量级极小，而且引擎加载素材本身已经是同步阻塞的，把执行者从 JS 换成 C++ 只会更快。性能方面我不担心。

目前 V2.0 还没正式发布（等本地测试跑通），所以 V2.1 不会马上动工（而且我也很累……）。这个缺陷我记下了，会作为 V2.1 的核心目标之一。感谢你花时间翻仓库并指出这个问题，这种级别的反馈确实能帮我把项目往前推一步。

CLAREXHL

V2.1已经在落项了 V2.0就先不要找了 （改的快要魔怔了）

CLAREXHL

Singular_Photon 发表于 2026-9-2 13:39
稍微翻了一下仓库，这东西本质上只是把原本的system.json给加密到根本拿不到实际内容的程度，但没去动RPGMV ...

已经快马加鞭完成啦
https://github.com/CLARE-XHL/Chronos-Seal/releases/tag/V2.1

CLAREXHL

关于 Chronos Seal 引擎支持策略调整与 MV 防护方案变更的说明

各位 RM 开发者朋友们好，我是 CLARE。

经过连续几天的深度测试与反复推演，我必须在这里向大家通报一个极其艰难的决定，也是一个经过深思熟虑、忍痛割爱的技术妥协。

一、 现实的技术壁垒：为什么 MV 无法使用 C++ 原生层？

在过去的这段时间里，我们投入了大量精力，尝试在 GitHub Actions（windows-2022 / VS 2022）上构建 C++ 原生层（decryptor.node）。然而，我们在 RPG Maker MV 上遇到了无法逾越的底层代差障碍：

MV 的 NW.js 底层（v0.29.0，Node 9.11.1）不仅最高只支持实验性的 N-API v2，而且其构建工具链严重依赖已停止维护的 Python 2.7 和老旧的 VS 2019 环境。
如果在现代的 windows-2022 CI 环境中强行编译，会遭遇无尽的 ABI 断层、链接器报错。如果为了兼容 MV，要求每一位 MV 作者去本地配置 VS 2019 和 Python 2.7 编译环境，这完全违背了 Chronos Seal “一键加密、降低门槛”的初衷。

二、 战略调整：分轨制引擎支持

因此，我们决定正式调整引擎支持策略：

· RPG Maker MZ（火力全开）：继续推进 C++ 原生层的云端编译。MZ 底层的现代 Node 环境完美支持 N-API，我们将为其提供终极的底层加密防护。
· RPG Maker MV（轻量防护）：放弃在 MV 上强上 C++ 原生层，降回 JS（纯 JavaScript）层加密，确保 100% 的兼容性与零部署门槛。

三、 MV 降回 JS 层，我们还有什么优势？能做什么？

我知道，大家可能会觉得退守 JS 层意味着安全性的大幅下降。但请放心，Chronos Seal 的 MV 版绝不是市面上那些粗制滥造的传统 JS 加密。我们依然具备以下四大独特优势：

1. 跨层降维打击：利用 NW.js 原生 Node 环境
   我们不使用纯前端的 CryptoJS，而是直接利用 MV 底层 NW.js 自带的 Node.js crypto 模块（底层即 OpenSSL）。这意味着在解密大图片、大音频时，我们拥有接近 C++ 原生的速度，告别传统 JS 解密导致的严重卡顿。
2. 动态密钥派生：拒绝一钥全破
   我们在 JS 层同样引入了基于“文件路径哈希 + 全局盐值”的动态派生机制。即便破解者从混淆代码中扒出了全局盐值，他也只能解密当前这一个文件，无法批量解密整个游戏包。
3. 极致体验：LRU 内存缓存池
   我们引入了内存 LRU 缓存池，限制缓存数量（如150个），高频调用的素材直接从内存读取，不仅丝滑无比，还能有效防止游戏因内存溢出而闪退。
4. 一键交付：复用未来的 GUI 架构
   未来的 Chronos Seal GUI 将同时支持 MV 和 MZ。MV 作者只需要在 GUI 里点一下“加密”，本地脚本就会自动处理，只需要安装 Node.js，不需要敲命令行，一秒生成加密包。

四、 写在最后

没能把 C++ 带进 MV，我个人感到非常遗憾。但作为一款工具，“能跑起来、不卡顿、无门槛”，永远比“绝对安全但没人用得起”更有实际意义。

我们不会放弃 MV 庞大的生态。相反，我们会把 MZ 上积累的工程经验，用来打磨 MV 的轻量化防护方案。感谢大家一直以来的关注与支持，Chronos Seal 将继续在你们的身后，默默守护每一份原创。

—— CLARE (CrCLARE 工作室)