electron 源码保护方案探讨。

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

This topic created in 1649 days ago, the information mentioned may be changed or developed.

打包工具：electron-builder ，前端框架 vue ，使用了不少 3rd 的 node modules

目前需要能对 main proc 和 render proc 的 js 代码进行加密保护。
目前看到比较靠谱的方案是 bytenode ，有没有实践过的同学来给个最小例子？
或者还有没有侵入性较小更好的源码保护方案呢？

proc

源码

方案

保护

23 replies • 2021-11-23 23:35:25 +08:00

lizhenda

Nov 20, 2021

核心逻辑写到 c++ ？

Yeen

Nov 20, 2021

@lizhenda 这个倾入性太高了,,,...

buffzty

Nov 20, 2021

你随便混淆加壳只要有价值很快就破解

dcsuibian

Nov 20, 2021

一直很好奇，什么样的应用有价值到需要加密混淆呢？

flood

Nov 20, 2021

可以换 nwjs 使用 bin

mengyx

Nov 20, 2021 via Android

我遇到过将 js 编译为 v8 bytecode 的

tomczhen

Nov 20, 2021 via Android

只要代码一文不值就不会有人来破解。:doge：

abear

Nov 20, 2021

编译 v8 bytecode ，，，大不了用 wasm

iamzuoxinyu

Nov 20, 2021

snapshot ？不过会影响热更新。

rekulas

Nov 20, 2021

最核心写道 wasm 吧也不复杂

kidonng

Nov 20, 2021 via Android

唯一有效的方法：需要保护的代码放在服务端。

lauix

Nov 20, 2021

自从被破解了一次，就使用了 v8 bytecode 。非常安全

12101111

Nov 20, 2021

我破解过一些 electron 应用，主要是为了在我的 musl libc 的系统上用，因为我用的 musl libc/libc++运行不了给 glibc 的 electron 应用.（顺便说一下我把 electron 移植到了 musl libc 上： https://github.com/12101111/overlay/tree/master/dev-util/electron ）
从防御破解的角度来说，如果想防源码泄露，建议的技术路线是 snapshot ，加强一点就是修改 v8 的 snapshot 相关的代码，比如改编码方式，再 AES 加密。密钥不要明摆着写死在程序了，可以是从程序本身算出来的。当然这需要有能力修改 v8 并重新编译整个 electron ，鉴于编译 electron 下载源码很繁琐且编译时间很长，这个属于侵入性较高的。
简单一些的就是用 native module 把核心 js 代码混淆+加密成二进制的，然后运行时解密，同样加密的算法和解密密钥本身不要一眼就能逆出来。如果你懂 rust 的话，可以用 https://github.com/neon-bindings/neon + rust 一些加密库做，因为 Rust 编译出来的代码本身就比 C 难逆向，而且性能可能更高一些。

jones2000

Nov 20, 2021

就一个 h5 页面加一个壳，有什么好破解的。都是些业务创新的产品，很少有技术创新的产品。

2i2Re2PLMaDnghL

Nov 21, 2021

侵入性最小的源码保护方案：登记软件著作权

2i2Re2PLMaDnghL

Nov 21, 2021

顺便，请确认下 3rd node modules 的授权许可，有可能发生任何类型的保护措施均违反许可证的情况。

uqf0663

Nov 21, 2021

解开 asar 的难度不大，但是 vue 的 dist 怎么变回源码？

R4rvZ6agNVWr56V0

Nov 21, 2021

@2i2Re2PLMaDnghL 没用。不一定是所有人都想破解代码做商业分发的。所以根本没发取证，更不用谈如何诉诸法律了。

R4rvZ6agNVWr56V0

Nov 21, 2021

如果是防止被人二次分发，那么核心逻辑被编译成机器码然后加虚拟机壳是比较安全的。其次就是混淆你 JS 的代码，增加破解难度。
如果是为了安全，防止被破解绕过某些代码执行过程，这就基本没办法了。商业价值越高，被破解的概率越高。

2i2Re2PLMaDnghL

Nov 22, 2021

@GeekGao 你的论据不够说明『没用』，只能说「不保证有用」，以及「保护面相对单一」。
但这确实是「侵入性最小」的方案，无论它实际能发挥多大的用。

pythonee

Nov 22, 2021

是不是可以看看 Gmail 在 js 保护方面是如何做的（外行瞎说的：）

R4rvZ6agNVWr56V0

Nov 23, 2021

@2i2Re2PLMaDnghL 强调用词的精确性没问题，但是大概率得不到保护。
论据：几年前，中国某知名一线互联网企业盗用 ffmpg 为商业闭源项目，社区应对方案：PR 稿+社区耻辱名单

R4rvZ6agNVWr56V0

Nov 23, 2021

@pythonee 听说是 js 虚拟机