探索 加密参数的常用逆向方式
1️⃣ 根据源码逻辑还原加密算法
思路：
- 直接分析前端源码（JavaScript、WebAssembly、混淆过的 JS、App 的 dex 或 binary），找出加密/签名函数的逻辑。
- 用自己的代码重新实现该算法，生成加密参数。
优点：
- 不依赖原始运行环境。
- 生成的参数可以独立使用，便于自动化。
缺点：
- 前端加密函数通常混淆过、反调试、防调试措施多。
- 一些动态依赖环境（如随机数、时间戳、浏览器指纹）难以完全复现。
- 对算法理解要求高，需要花时间分析。
适用场景：
- 加密逻辑简单，依赖环境少。
- 想在自定义脚本或服务端生成参数。
2️⃣ 补环境跑源码（你用得最多的方法）
思路：
- 直接在完整的前端或 App 环境中运行原始加密函数。
- “补环境”指补齐源码运行所需的变量、全局对象或函数依赖，比如模拟
window、document、navigator，或者提供必要的随机数/时间戳。 - 运行源码得到加密参数，然后把参数拿去请求接口。
优点：
- 不用完全理解加密算法，只要保证代码能跑就行。
- 适应动态复杂加密逻辑，比如依赖浏览器环境、随机数、WebAssembly。
缺点：
- 环境搭建需要一点技巧（Node.js 模拟浏览器 API、mock 全局变量）。
- 运行效率可能低于纯逻辑复现，尤其是大量请求时。
- 如果加密逻辑更新，需要调整环境模拟。
适用场景：
- 加密函数复杂、依赖前端运行环境。
- 需要快速获取参数进行爬取或自动化请求。
3️⃣ RPC / 远程调用
思路：
- 通过 RPC 或远程接口调用原始应用（浏览器、App）提供的加密接口。
- 不逆向、不复现逻辑，直接让原始环境输出加密参数。
优点：
- 最接近原始环境，参数最可靠。
- 不需要分析源码或补环境。
缺点：
- 搭建 RPC 通道复杂（需要 App 或浏览器支持）。
- 并发量受限，效率低。
- 可能被安全机制监控或限制。
适用场景：
- 加密逻辑高度动态或加密算法保护很严。
- 对并发量要求不高。
总结对比
| 方法 | 技术门槛 | 效率 | 稳定性 | 依赖环境 | 适用场景 |
|---|---|---|---|---|---|
| 源码逻辑复现 | 高 | 高 | 中 | 少 | 简单算法或后端复现 |
| 补环境跑源码 | 中 | 中-高 | 高 | 需模拟前端环境 | 复杂算法，快速生成参数 |
| RPC 调用 | 低-中 | 低 | 高 | 原始前端/应用 | 无法复现算法，低并发 |
✅ 为什么你用“补环境跑源码”最多？
- 对前端复杂算法最适应，兼顾效率和稳定性。
- 不必完全理解加密逻辑，省力。
- 可以批量生成参数，比 RPC 高效，比纯复现灵活。