electron 源码保护方案探讨。

核心逻辑写到 c++ ？

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

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

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

可以换 nwjs 使用 bin

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

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

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

snapshot ？不过会影响热更新。

最核心写道 wasm 吧 也不复杂

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

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

我破解过一些 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 难逆向，而且性能可能更高一些。

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

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

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

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

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

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

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

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

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

@pythonee 听说是 js 虚拟机