这是一个创建于 127 天前的主题，其中的信息可能已经有所发展或是发生改变。
需要提高前端 js 代码的破解难度，进行混淆，目前用的是 star 很多的开源项目： https://github.com/Javascript-obfuscator/Javascript-obfuscator
想问下目前是否有更全的混淆方式？或者别的前端防破解的方式，比如 wasm
 | 1 MuscleOf2016 127 天前 再高级复杂的要付费了。专门做加固加密的公司，有产品 |
 | 2 Ketteiron 127 天前 wasm 最安全 没事别玩 js 混淆了，人类很难阅读高度混淆的 js 代码，但是 AI 可以轻松还原语义，js 层面的混淆已经可以说毫无用处了，仅仅是让所有用户打开网站卡得半死而已。js 不会让全球变暖，但是 Javascript-obfuscator 会。 |
 | 3 bronyakaka OP @dssxzuxc 但是 wasm 二进制体积很大啊  像 go 打出来的起步就几 mb |
| 4 Ketteiron 126 天前 @bronyakaka #3 https://go.dev/wiki/WebAssembly 看了下 go 的 wiki ，起步确实是 2m ，应该是 go 运行时打进去了。 下面有推荐一些减少体积的办法，手动优化几百 k ，TinyGo 可以优化到 10k 。 或者看看 rust https://github.com/wasm-bindgen/wasm-bindgen |
| 5 bronyakaka OP @dssxzuxc #4 说到 wasm ，如果别人把 wasm 文件下载下来，本地用 node 调用，他是不是都不需要管 wasm 内部实现，只需要处理参数就行，也相当于破解吧，这个有办法吗 |
| 6 Ketteiron 125 天前 是的，并不需要知道它实现了什么，只要找到调用入口就行了。这个逻辑在 js 也是一样。 混淆其实分为两种，混淆调用实现，混淆调用入口。js 层面的混淆同时做了这两件事，破解者要还原逻辑只要耐心点是一定能成功的，本质上是增加了破解成本。但是目前可以通过反混淆工具+AI 轻易还原，至少对我个人来说是没有成本的。虽然混淆后代码是多样的，但是混淆的方案是已知的可预测可学习的，这点是 AI 的强项。 wasm 在这里是增加了阅读调用实现的代价，从高度混淆的 js 转成更难处理的 wasm 文件，但是调用入口无法隐藏，有些时候并不需要知道里面实现了什么逻辑，只需要 hook 调用就行了。 还可以从另一个方向入手，魔改 Javascript-obfuscator ，自己实现的 js 混淆 AI 不好还原，因为它的训练材料里没这玩意。这个可以跟 wasm 方案合起来，逆向成本足以让大多数人止步了。 再进一步，实现一个虚拟机，应该是目前最安全的。想给逆向增加多少成本，自己就得投入更多成本，没有上限。 |
| 7 bronyakaka OP @dssxzuxc #6 问了下 ai ，说 1 、攻击者最容易入手的地方就是 JS 和 WASM 的“胶水代码”，目标是让这个接口变得难以理解和模拟。不要使用 wasm.do_something(param1, param2) 这种清晰的调用方式。取而代之，让 JS 将参数写入 WASM 的线性内存（ WebAssembly.Memory ）中的一个复杂数据结构里，然后只给 WASM 传递一个指向该结构的指针（一个整数）。WASM 函数执行完毕后，再将结果写入内存，JS 从内存中读取。 2 、 让 WASM 感知并依赖于执行环境 (环境指纹) 这是对抗模拟调用的核心思想。WASM 模块需要验证自己是否运行在预期的网页环境中。 是不是指纹是一个关键 |
| 8 bronyakaka OP @dssxzuxc #6 不过既然都用指纹了 那我直接不用 wasm ，而是在服务端做不就行了 似乎 wasm 不能提高多少安全 |
| 9 Ketteiron 125 天前 @bronyakaka #7 在实践中，一般会将加密方法放在 wasm 中，然后在 wasm 环境判断当前客户端是否可信，不可信就返回虚假的结果。当然这个理论无法实现，因为所有客户端必然不可信，而且 wasm 几乎获取不到什么关键信息能用来区分是否是恶意调用。这只能给逆向的玩家们增加一点难度，或者说时间成本。如果只能通过特定参数、算法、环境因素等等才能获取到正确结果，那逆向的思路就换成了模拟出这些前置要求，防是防不住的。 |
Select Language