什么是 JS 逆向？常见应用场景

本节目标

JS 逆向说白了就是：网页/小程序的前端逻辑本质是 JavaScript，而 JS 是可以被查看、被执行的。所谓「逆向」，就是从「程序跑起来的行为」反推出「它内部是怎么算的」。最常见的诉求是：前端在发请求前，对参数做了加密/签名（比如 sign、token），外部程序不知道算法就发不出合法请求——逆向就是要把这段算法还原出来，在你的 Python/Node 里复现。

四类典型场景：

  1. 参数加密：请求里的 sign / token / ts 是前端算的，你外部发请求算不出 → 还原算法。
  2. 数据加密：接口返回的是密文，前端解密后再渲染 → 还原解密逻辑。
  3. 风控：滑块验证、行为指纹、频率限制 → 分析判定逻辑（务必在合规前提下）。
  4. 代码混淆：厂商用混淆工具把代码打乱不让你看懂 → 还原成可读逻辑。

合规边界（请刻在脑子里）：逆向只应用于学习、安全研究、调试你自己的系统。爬取他人数据要遵守 robots 与平台协议、相关法律。本课程只讲技术原理，请勿用于恶意用途。

总体流程（后面每节课都在填充其中一个环节）：

① 抓包：找到带加密参数的请求
  → ② 定位：在压缩 JS 里搜索关键字（sign / encrypt）
  → ③ 断点：跟调用栈，看算法在哪执行
  → ④ 还原：读代码 / 抽离函数，弄明白输入→输出
  → ⑤ 复现：用 Node/Python 重写并验证结果一致

名词解释

逆向（Reverse Engineering）：从「成品」反推「设计」的过程。比如你看到一个加密后的字符串，去反推它「是用什么密钥、什么算法、从什么明文算出来的」。它和「正向开发」相反——正向是「写代码产生结果」，逆向是「看结果反推代码」。

签名（Signature）：把「请求参数 + 密钥」通过某种算法算出的一串校验值，随请求一起发给服务器。服务器用同样的密钥重算一遍，对得上才认。它用来「证明请求是你（持有密钥的一方）发出的、且没被篡改」。前端逆向里 sign 参数就是签名。

课后练习

练习 1：下面哪个场景「不适合」用纯前端 JS 逆向解决？为什么？
（a）某网站列表接口返回密文，前端能正常显示；
（b）某 App 的数据来自原生iOS代码，前端只是个壳。

答案：（b）不适合。逆向针对的是「运行在前端的 JS 逻辑」。如果数据根本不是由前端 JS 计算的（而是原生/服务端算的），前端 JS 里就没有可还原的算法，得去逆向原生层，超出本课程范围。

练习 2：为什么「还原算法后要用 Node/Python 复现并验证结果一致」这步不能省？

答案：因为你「以为看懂了」和「真的算对」是两回事。只有用同样的输入跑出和网站完全一样的输出，才能证明你还原的算法是对的。否则上线后请求还是被拒，等于白做。

总结

我的观点：JS 逆向最容易被神化，其实它的内核非常朴素——就是「定位一段计算逻辑，然后复现它」。真正拉开差距的不是「会不会用工具」，而是「有没有流程感」：先抓包、再定位、再断点、最后还原复现，一步都不能乱。新手最爱一头扎进混淆代码里硬读，结果越读越晕。我的建议永远是：先用浏览器/Charles 把「哪个请求、哪个参数被加密」钉死，再带着目标去找那一行算法，效率至少高十倍。另外务必守住合规底线——技术是中性的，用法决定它是学习还是麻烦。