关于逆向项目的一些想法
继上一次爬虫架构设计的博客记录，回顾写一写当时做逆向项目的一些经历和感受。 肯定没有当时那样的心情了，但还是想把一些想法记录下来，算是对这个项目的一个总结和反思。
为什么想写这篇
Section titled “为什么想写这篇”最近看到不少分享逆向的文章，感觉挺有意思，也想记录一下自己在做这类项目时的一些想法和体会。 这个项目还是比较典型的逆向项目，涉及到代码分析、参数破解、请求模拟、数据处理等多个环节。 也是AI协助下的一种风口和未来趋势，虽然AI不能完全替代人工判断，但确实能加速很多分析和调试的过程。
某游戏大厂的虚拟物品交易平台。 需要从这个平台上获取一些数据，但官方没有提供公开的API接口。 所以只能通过逆向分析前端代码和网络请求，来找到合适的接口和参数，再模拟请求获取数据。 接口返回的数据分成两部分：一部分是基本的列表数据，另一部分是需要额外请求才能拿到的详细数据。 js的代码是经过混淆的，参数生成也比较复杂，涉及到一些加密和动态生成的逻辑。
标注：这篇博客不粘贴代码，只使用文字的方式来描述分析和思考的过程，避免泄露任何敏感信息（🐶狗头保命）。
先聊聊开始前的准备和事项
Section titled “先聊聊开始前的准备和事项”使用的浏览器 Network，看 XHR 、 Fetch、resource，进行断点调试，分析。 再分析请求参数、Headers、Cookie、响应结构。尝试请求接口，看看能不能拿到数据。 分析 JavaScript 代码，找到请求相关的函数，看看参数是怎么生成的，是否有加密、混淆、动态生成等。
关键点：
- 请求的大致流程
- 解密放在哪个环节
- 需要哪些参数，参数是怎么生成的，有没有解密方法
可以先对请求附近的函数入手，虽然被加密，整体逻辑还是可以拎得清楚的。 探查逻辑后，对关键函数进行断点。全局搜索可疑函数。最先知道的应该是解密函数， 找到它的调用关系，看看它的输入输出是什么。也可以在请求的过程中，在控制台打印一些参数，调用方法，看看它们的变化。
总计耗时三天，第一天主要是分析请求，参数，熟悉请求流程和代码，第二天主要是分析代码和找到解密方法，第三天主要是把请求流程跑通。
第一天不用急着找解密逻辑，先把请求流程摸清楚，得先了解项目，为什么要加密，加密的目的是什么？
- 只是为了防止被爬
- 还是保护数据
- 还是为了压缩数据大小以方便传输
如果是第三种，只是为了方便传输，那么解密方法可能就是一个简单的压缩算法，或者是一个常见的加密算法，可能在网上就能找到相关的解密方法。 需要注意的就是前后会有一些步骤，是否需要配合渲染流程，进行一些前置处理，或者是后续的处理。
逆向不只是找接口
Section titled “逆向不只是找接口”很多时候，逆向项目的第一步确实是抓包。
但这只是开始。
真正麻烦的地方往往在后面：
- 参数是不是动态生成的
- Token 是否有时效
- Cookie 是否会失效
- 请求频率是否有限制
- 数据结构是否会变化
- 失败任务能不能恢复
先跑通一次流程，后续的流程会很快
项目里最考验人的地方
Section titled “项目里最考验人的地方”我觉得逆向项目里最考验人的，不是某一次成功请求。
而是你能不能把它从“脚本”做成一个能运行的系统。
比如：
- 失败要能重试
- 账号要能管理
- Cookie 要能维护
- 请求要控制频率
- 数据要能落库
- 异常要能被发现
- 任务要能继续跑
这些东西看起来不如破解一个参数酷，但它们才决定项目能不能真正用起来。
GPT 能帮忙，但不能替你判断
Section titled “GPT 能帮忙，但不能替你判断”现在做这类项目，AI 工具确实能帮很多忙。
它可以帮你分析代码片段，解释混淆逻辑，整理调试思路，甚至帮你把 JavaScript 逻辑改写成 Python。 甚至可以将加密的数据给AI看一下，确定加密的类型，或者帮你分析加密算法的逻辑。
但它也有局限。
它不知道真实请求环境，不知道站点当时的状态，也不知道你的 Cookie、代理、网络和账号到底发生了什么。
所以最后还是要自己判断。
AI 可以加速排查，但不能代替现场判断。同理，AI 也会犯错。
逆向项目很容易让人沉迷在某个技术细节里，非常容易上瘾。
但值得沉淀的，不是某一次参数破解成功，而是过程中形成的分析方法和工程意识。
技术会变，接口会变，规则也会变。
但观察问题、拆解问题、验证问题的能力，会一直留下来。
