ARTICLE · 1180318
携程app逆向那些事(ai agent能力偏弱时)
前言：
本篇文章文风较为随意，主要讲下当时初步接触大厂app逆向的一些事
由于较多的借助 AI，故标题不说什么古法逆向了
当时自己用frida hook，自己想办法研究和追一个参数，就是deviceId
当时是通过不同设备能查出来，发现设备被封禁的，当然都是通过抓包
对了，说到这个抓包 （正文开始...）
当时寻常抓包手段是一点都抓不到想要的包，这个还是通过 fundex 还是什么来着，把 dex 给 dump 出来，然后反编译成 java 代码之后才发现是走的自有 sotp 协议（也好像是通过一些帖子《自己要逆向一个玩意之前都会先查查有没有相关信息》知道的携程走的自研协议）
当时还把反编译出来的自认为比较关键的 java 文件发给 GPT 和 Gemini 给研究下到底咋走的，了解好全貌后就试着让 AI 给我构造为 python版本了
随后便是抓包的问题
当时好像还是通过一个帖子，发现人家抓的二进制的方式抓到了网络流量，然后自己就找了一个能抓底层网络流量的软件（下这个软件时又折腾了一番，别的地方下不来）
抓到包之后，先是自己用 shark 分析了分析，从一脸懵逼到 0.99 脸懵逼....
不过最后还是慢慢的翻到了那条搜索请求记录，用 AI 给的解析代码将hex串解回正文后，终于是发现了那条查询请求，，后边就是让 AI 给我组装，然后由于不是单纯的发一次请求，等待一次响应 就行了，这个发送请求后得持续的接收，直到完毕，，，
当时显然是有点惊讶的，因为在我看来，那些数据包是分片的，而把这些情况说明之后，AI 给的代码直接给完整的接收到并且显示在我的 PyCharm 显示台（输出控制台）上了
于此之后，便有了调试的根基，在发送多次包之后，遇见了anti 挑战，通过更换 ip 连续查询直到更换 ip 再也没法得到正常响应之后，就开始把目光转向别的设备了，在别的设别安装好携程以及抓包用的软件，继续抓，抓到后继续用shark分析，一条条找，找到那条搜索请求记录之后，通过分析以及更换参数验证的方式，发现了 deviceId 这个参数，只要更换，就可以正常查，用原来的小米手机抓包得来的 deviceId 则不行
再之后就开始了漫长的定位之旅....
定位到之后就开始了漫长的hook 以及 hook 请求包之旅.... （中间省略一堆当时遇到的疑难杂症...）
搞定 deviceId 之后，发现还有请求失败的问题，
于是查呀查....最终发现是个签名的问题
于是揪着这个签名找啊找，找到 so 之后 unidbg 又补啊补....最终补了出来
最后整个查价任务算是ok了
除了这两个，算是全程自己主导搞的， AI 作为百科全书般的辅助
后边的 payload source 纯 Python 算法版本，则是 AI 主导
美团 mtgsig 我更是都没咋动手，app 下好，任务下完，没多久，纯算法ok了。。。
