electron 源码保护方案探讨。

[Yeen]

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

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

[lizhenda]

核心逻辑写到 c++ ？

[Yeen]

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

[buffzty]

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

[dcsuibian]

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

[flood]

可以换 nwjs 使用 bin

[mengyx]

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

[tomczhen]

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

[abear]

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

[iamzuoxinyu]

snapshot ？不过会影响热更新。

[rekulas]

最核心写道 wasm 吧 也不复杂

[kidonng]

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

[lauix]

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

[12101111]

我破解过一些 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]

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

[2i2Re2PLMaDnghL]

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

[2i2Re2PLMaDnghL]

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

[uqf0663]

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

[GeekGao]

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

[GeekGao]

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

[2i2Re2PLMaDnghL]

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