发现比起混淆， emscripten 或 webassenbly 才是保护代码的好办法

说到保护 js 代码，一般都是做混淆
但是最近尝试反向一些网页游戏的代码，然后发现现在越来越多的游戏都是直接上的 emscripten 或者 webassenbly。
和反向混淆比起来，那真的是痛苦到无以复加


首先说 emscripten 吧，用了 emscripten 的游戏很多都会选择把最终游戏代码塞到一个 js 文件里，一个 js 文件 5MB 打底，稍微大一点的 10MB 打底的单个 js 代码文件。
这么做最大的好处就是：F12 开启工具启动调试，下个 xhr 断点，然后能做的就是等待开发工具卡死，然后几分钟后提示无响应。见过各种网站那么多防止开启调试工具的手段，这才是最有效的方法，让调试工具直接崩溃。
鉴于有人可能会反驳电脑性能不行，E5-2620 V3 + 64G 内存的机子依旧无法调试。


然后启动调试工具才只是过了第一道关卡，第二道代码部分就更难受了。满眼都是靠着定义的内存块来储存除了数据，比如下面这种画风。相当于模拟了一块相当大的内存，所有数据都是在内存块里进行操作，传递数据都是用指针。
```javascript
Module.HEAP = z;
Module.HEAP8 = p;
Module.HEAP16 = r;
Module.HEAP32 = n;
Module.HEAPU8 = co;
Module.HEAPU16 = OXb;
Module.HEAPU32 = PXb;
Module.HEAPF32 = I;
Module.HEAPF64 = rg;
```
遇到这些代码能做的只有最原始的记录下内存地址来分析，然后还要经受 js 代码里的各种层层嵌套的混淆的折磨。想看看 api 的 post 数据是怎么加密的，上了瀑布图，才发现这加密代码部分被几十个混淆过的函数翻来覆去搞来搞去，几十几百个指针被倒腾来倒腾去，光是这点反向难度就已经远超混淆了
也许你会说，不就是分析内存和指针吗，但问题是浏览器的开发工具可没有方便的辅助内存分析和指针的工具。



最后说说 webassenbly，这个更加不用提了。
编译成 wasm，一个 wasm 解压出 20M，30M 的字节码。嗯……看的太痛苦了，尝试还原为 c 代码，花了十几分钟反编译，反编译出 200M 的 c 代码，emmmmmmm …………
问题是可阅读性依旧没任何变化
而且体积倒也不重要，但问题是怎么去调试这编译好的 wasm 文件。开发工具可没有针对 wasm 做优化，进了 wasm 代码块就全都是满眼的字节码，和看汇编没区别
但问题是汇编我好歹还有 OD 这方便的工具来调试，但这 webassenbly 我拿什么来调试。而且编译出这个 wasm 的 c 之类的源代码很可能也是经过混淆的。可以说 webassenbly 将反向 js 难度提更高了。


所以，从我这几条经验来看，真的建议开发者在遇到较大代码量时，可以考虑上 emscripten 或者 webassenbly 来保护自己的代码。
虽说前端没有破不了的防护，但这两样东西真的是靠很简单的方法就能达到相当好的保护目的能。而且尤其是当你代码混淆+这些之后，对攻击者来说，那酸爽，简直了。