求推荐前端混淆算法/库/工具

[bronyakaka]

需要提高前端 js 代码的破解难度，进行混淆，目前用的是 star 很多的开源项目： https://github.com/javascript-obfuscator/javascript-obfuscator

想问下目前是否有更安全的混淆方式？或者别的前端防破解的方式，比如 wasm

[MuscleOf2016]

再高级复杂的要付费了。专门做加固加密的公司，有产品

[dssxzuxc]

wasm 最安全
没事别玩 js 混淆了，人类很难阅读高度混淆的 js 代码，但是 AI 可以轻松还原语义，js 层面的混淆已经可以说毫无用处了，仅仅是让所有用户打开网站卡得半死而已。js 不会让全球变暖，但是 javascript-obfuscator 会。

[bronyakaka]

@dssxzuxc 但是 wasm 二进制体积很大啊 像 go 打出来的起步就几 mb

[dssxzuxc]

@bronyakaka #3
https://go.dev/wiki/WebAssembly
看了下 go 的 wiki ，起步确实是 2m ，应该是 go 运行时打进去了。
下面有推荐一些减少体积的办法，手动优化几百 k ，TinyGo 可以优化到 10k 。
或者看看 rust
https://github.com/wasm-bindgen/wasm-bindgen

[bronyakaka]

@dssxzuxc #4 说到 wasm ，如果别人把 wasm 文件下载下来，本地用 node 调用，他是不是都不需要管 wasm 内部实现，只需要处理参数就行，也相当于破解吧，这个有办法吗

[dssxzuxc]

是的，并不需要知道它实现了什么，只要找到调用入口就行了。这个逻辑在 js 也是一样。
混淆其实分为两种，混淆调用实现，混淆调用入口。js 层面的混淆同时做了这两件事，破解者要还原逻辑只要耐心点是一定能成功的，本质上是增加了破解成本。但是目前可以通过反混淆工具+AI 轻易还原，至少对我个人来说是没有成本的。虽然混淆后代码是多样的，但是混淆的方案是已知的可预测可学习的，这点是 AI 的强项。
wasm 在这里是增加了阅读调用实现的代价，从高度混淆的 js 转成更难处理的 wasm 文件，但是调用入口无法隐藏，有些时候并不需要知道里面实现了什么逻辑，只需要 hook 调用就行了。
还可以从另一个方向入手，魔改 javascript-obfuscator ，自己实现的 js 混淆 AI 不好还原，因为它的训练材料里没这玩意。这个可以跟 wasm 方案合起来，逆向成本足以让大多数人止步了。
再进一步，实现一个虚拟机，应该是目前最安全的。想给逆向增加多少成本，自己就得投入更多成本，没有上限。

[bronyakaka]

@dssxzuxc #6 问了下 ai ，说

1 、攻击者最容易入手的地方就是 JS 和 WASM 的“胶水代码”，目标是让这个接口变得难以理解和模拟。不要使用 wasm.do_something(param1, param2) 这种清晰的调用方式。取而代之，让 JS 将参数写入 WASM 的线性内存（ WebAssembly.Memory ）中的一个复杂数据结构里，然后只给 WASM 传递一个指向该结构的指针（一个整数）。WASM 函数执行完毕后，再将结果写入内存，JS 从内存中读取。
2 、 让 WASM 感知并依赖于执行环境 (环境指纹)
这是对抗模拟调用的核心思想。WASM 模块需要验证自己是否运行在预期的网页环境中。

是不是指纹是一个关键

[bronyakaka]

@dssxzuxc #6 不过既然都用指纹了 那我直接不用 wasm ，而是在服务端做不就行了
似乎 wasm 不能提高多少安全

[dssxzuxc]

@bronyakaka #7 在实践中，一般会将加密方法放在 wasm 中，然后在 wasm 环境判断当前客户端是否可信，不可信就返回虚假的结果。当然这个理论无法实现，因为所有客户端必然不可信，而且 wasm 几乎获取不到什么关键信息能用来区分是否是恶意调用。这只能给逆向的玩家们增加一点难度，或者说时间成本。如果只能通过特定参数、算法、环境因素等等才能获取到正确结果，那逆向的思路就换成了模拟出这些前置要求，防是防不住的。