这是一个创建于 1100 天前的主题，其中的信息可能已经有所发展或是发生改变。
打包工具：electron-builder ，前端框架 vue ，使用了不少 3rd 的 node modules
目前需要能对 main proc 和 render proc 的 js 代码进行加密保护。
目前看到比较靠谱的方案是 bytenode ，有没有实践过的同学来给个最小例子？
或者还有没有侵入性较小更好的源码保护方案呢？
目前需要能对 main proc 和 render proc 的 js 代码进行加密保护。
目前看到比较靠谱的方案是 bytenode ，有没有实践过的同学来给个最小例子？
或者还有没有侵入性较小更好的源码保护方案呢？
 |
1
lizhenda 2021-11-20 14:26:57 +08:00
核心逻辑写到 c++ ？
|
 |
3
buffzty 2021-11-20 15:34:05 +08:00
你随便混淆加壳 只要有价值 很快就破解
|
 |
4
dcsuibian 2021-11-20 15:51:52 +08:00  3
一直很好奇，什么样的应用有价值到需要加密混淆呢？
|
 |
5
flood 2021-11-20 15:52:06 +08:00
可以换 nwjs 使用 bin
|
 |
6
mengyx 2021-11-20 16:59:52 +08:00 via Android
我遇到过将 js 编译为 v8 bytecode 的
|
 |
7
tomczhen 2021-11-20 17:15:37 +08:00 via Android
只要代码一文不值就不会有人来破解。:doge：
|
 |
8
abear 2021-11-20 17:17:29 +08:00
编译 v8 bytecode ，，，大不了用 wasm
|
 |
9
iamzuoxinyu 2021-11-20 17:29:32 +08:00
snapshot ？不过会影响热更新。
|
 |
10
rekulas 2021-11-20 18:56:19 +08:00
最核心写道 wasm 吧 也不复杂
|
 |
11
kidonng 2021-11-20 19:13:07 +08:00 via Android
唯一有效的方法：需要保护的代码放在服务端。
|
 |
12
lauix 2021-11-20 19:41:48 +08:00
自从被破解了一次，就使用了 v8 bytecode 。非常安全
|
 |
13
12101111 2021-11-20 20:13:58 +08:00 1
我破解过一些 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 难逆向，而且性能可能更高一些。 |
 |
14
jones2000 2021-11-20 22:47:37 +08:00
就一个 h5 页面加一个壳，有什么好破解的。 都是些业务创新的产品， 很少有技术创新的产品。
|
 |
15
2i2Re2PLMaDnghL 2021-11-21 08:50:50 +08:00 1
侵入性最小的源码保护方案：登记软件著作权
|
|
16
2i2Re2PLMaDnghL 2021-11-21 08:52:54 +08:00
顺便，请确认下 3rd node modules 的授权许可，有可能发生任何类型的保护措施均违反许可证的情况。
|
 |
17
uqf0663 2021-11-21 09:19:15 +08:00
解开 asar 的难度不大，但是 vue 的 dist 怎么变回源码？
|
 |
18
GeekGao 2021-11-21 22:59:44 +08:00
@2i2Re2PLMaDnghL 没用。不一定是所有人都想破解代码做商业分发的。所以根本没发取证，更不用谈如何诉诸法律了。
|
|
19
GeekGao 2021-11-21 23:02:44 +08:00
如果是防止被人二次分发，那么核心逻辑被编译成机器码然后加虚拟机壳是比较安全的。其次就是混淆你 JS 的代码，增加破解难度。
如果是为了安全，防止被破解绕过某些代码执行过程，这就基本没办法了。商业价值越高，被破解的概率越高。 |
|
20
2i2Re2PLMaDnghL 2021-11-22 09:09:55 +08:00
@GeekGao 你的论据不够说明『没用』，只能说「不保证有用」，以及「保护面相对单一」。
但这确实是「侵入性最小」的方案，无论它实际能发挥多大的用。 |
 |
21
pythonee 2021-11-22 11:29:50 +08:00
是不是可以看看 Gmail 在 js 保护方面是如何做的（外行瞎说的：）
|
|
22
GeekGao 2021-11-23 23:34:58 +08:00
@2i2Re2PLMaDnghL 强调用词的精确性没问题，但是大概率得不到保护。
论据：几年前，中国某知名一线互联网企业盗用 ffmpg 为商业闭源项目，社区应对方案：PR 稿+社区耻辱名单 |
Select Language