内容摘要：打开浏览器开发者工具，切到Network面板，刷新页面。你看到几十个请求飞过去，其中有个XHR返回了一串加密字符串。你想知道它是怎么生成的——这就是web逆向的起点。 web逆向的核心就一件事：搞清楚

打开浏览器开发者工具，切到Network面板，刷新页面。你看到几十个请求飞过去，其中有个XHR返回了一串加密字符串。你想知道它是怎么生成的——这就是web逆向的起点。

web逆向的核心就一件事：搞清楚前端代码在干什么，然后用自己的方式复现它。听起来简单，做起来是另一回事。

从混淆说起

大部分网站不会让你舒舒服服读代码。你打开一个JS文件，变量名全是_0x4a2b、_0x3f1c这种，字符串被拆成数组，通过一个旋转函数动态取值。这是最基础的obfuscator处理。更狠的会上控制流平坦化，把简单的if-else拆成switch-case加状态机，让你根本看不出执行顺序。

我遇到过最离谱的一个站点，核心加密函数被拆成十几个小函数，散布在三个不同的JS文件里，互相通过全局变量通信。调用栈打出来跟迷宫似的。

对付混淆，工具能帮一部分忙。AST解析器可以把代码还原成语法树，配合babel做常量折叠、死代码消除。但工具不是万能的，很多混淆方案专门针对自动化还原做了对抗。手撸代码仍然是常态。

断点是你的朋友

找到加密入口最直接的办法：在发起请求的地方下XHR断点。Chrome DevTools支持按URL关键词拦截请求，断下来之后看调用栈，一层层往上翻，通常能定位到参数拼接的位置。

另一个常用手段是DOM事件断点。比如登录按钮的点击事件，断下来之后单步跟进，看它怎么处理密码字段。有些站点会在提交前调用一个encrypt()函数，你顺着跟进去就行。

但现实往往更复杂。加密逻辑可能藏在Web Worker里，可能通过eval动态执行，也可能在wasm模块中。Web Worker的情况还好，切换调试上下文就能跟。wasm就麻烦了，你得反编译.wasm文件，读出来的东西跟汇编差不多。

补环境这件事

当你把加密函数抠出来想放到Node.js里跑，大概率会报错。因为代码里引用了window、document、navigator这些浏览器环境才有的对象。

补环境就是手动构造这些对象，让代码在Node里能跑通。听起来不难，实际上很磨人。有些代码会检测navigator.userAgent，有些会调用canvas.getContext('2d')做指纹，还有些会检查window.chrome是否存在。

我的习惯是先跑一遍，看报什么错就补什么。用Proxy拦截未定义的属性访问，把调用路径打印出来，比盲目猜测高效得多。当然，遇到检测逻辑特别刁钻的站点，补环境的时间可能比分析加密算法本身还长。

验证与落地

算法还原之后，拿几组已知输入输出对一下。一致了，再放到实际请求里测试。有时候本地算出来是对的，但发到服务器就是不行——检查一下请求头顺序、Content-Type、时间戳精度，这些细节都可能是坑。

最后说一句：web逆向是个手艺活，没有银弹。每个站点的防护思路不同，你积累的是经验直觉，不是万能脚本。