某浇油app的请求参数分析

前言

最近在学app，有我觉得值得记录的我就写写

 

这次的案例就是某社交app，包名：Y29{deleteme}tL{deleteme}mJha{deleteme}Whl，难度程度我觉得算简单，但是容易有误区。

 

环境准备

• 一台已root的真机，我选用的n6p
• postern抓包工具，详细的配置就不说了，网上搜
• 一台装有frida，jadx，尿壶的电脑
• 上述说的app，版本好，11.4

 

由于我的手机系统是安卓8，所以我就下载的frida-server 12.8.0，对应的python库也是12.8.0，安装：

pip3 install frida==12.8.0

frida-tools==5.3.0

 

 

分析

 

事先说明下，这个app需要登录，所以如果想跟着搞一波的，你可能得注册一个账号。我是很早就因为某原因就注册了的（真不是各位哥哥姐姐想的那啥，当时就是在某公司做某项目才注册的，至今记得同事小姐姐看到我手机上装了有这种软件后那种嫌弃的表情，真不是为了那啥的.......）

 

电脑打开尿壶，手机配置好postern开始抓包

发现，有多个接口

 

 

 

 

 

只有这个接口才是真的数据接口，然后看到是post请求，带了4个请求参数

 

 

 

 

 

 

返回数据就是我们要的小姐姐了，呸，（手动撤回），返回数据就是我们要的就是数据了。

 

然后多次翻页，多次刷新，发现这四个参数基本固定存在，有部分接口的4个参数对应的值不太一样而已。

 

先看第一个，userID不说了，就是我的用户id，后面就是些参数，然后有个接口会带有经纬度的参数，当然这里的是没有的

 

 

 

再看第二个，感觉【_】左边的就是时间戳了，右边的估计就是加密字段，而且相同的接口每次请求都不一样，那盲猜是带了有时间戳作为加密。

 

 

说实话哈，可能有经验的老哥哥看到后面的数字，其实很敏感的，直接拿去算下长度：

 

 

 

32位，盲猜一波这个算法很可能是md5，这个搞得多的老哥可能会有这种意识

 

 

再看第三个，这个参数就有点长了，但是仔细看，就是带了很多的设备参数，有些敏感的我就打码了，这个参数基本不变，每个请求接口都是固定的（那肯定啊，你设备参数还能变不成对吧？）

 

 

 

再看最后一个，我打码的地方是固定的，因为带有了这个app的特征。前面那个依旧是时间戳子弹，后面的就是一些加密字段了。

 

一般这种参数，按常规的app防护手段，都会用设备参数在本地加密后去服务端注册，等待风控检测，风控过了之后会返回一个值，说实话我看着这个stk就很像这种东西，这里先不表，后面再说

 

 

 

OK，总结下，四个参数里，要搞定的其实就是第二个_t和第四个stk，下面开始分析参数生成

 

 

参数定位

打开jadx，先搜一波：

 

 

 

 

 

直接点第一个进去，卧槽？这么简单，4个参数都在

 

 

 

再看后面的：

 

 

 

 

 

根据我的分析发现，基本确定就是我刚才进的第一个了，那就先看_t吧，先看上面的，这不就是第三个参数里的字段吗哈哈哈哈，这里可以不用管，反正基本是固定的，再看我已经标注出来的，1和2的位置

 

反正意思就是_t有两种，如果获取到了第一个参数，就加进去加密，否则则直接加密。

 

 

然后再看最后一个参数stk，基本是一个写法。

 

 

好的，位置是找到了，开始写hook代码

 

 

hook调试

手机连上电脑，adb shell进入手机终端，然后启动frida，怎么选用手机对应的frida版本在之前的文章有，这里就不细说了

好执行后，只要不报错就是启动成了

 

 

先看看_t参数怎么来的

 

 

继续看看jadx的逻辑，读逻辑知道，是用的j.a做的加密

 

 

点进j.a看看，卧槽，这不就是md5吗，但是感觉是他自己稍微做了魔改的，那无所谓的，反正能用就行了

 

 

 

开始hook 这个j.a之前，hook脚本编写，这里我用的pycharm，说实话个人还是用不惯vscode，还是习惯pycharm

 

 

终端执行，选用的attch模式进入，好的，没报错，说明附加上了

 

现在app还是打开状态，此时先把尿壶里的抓包记录清理一下：

 

 

 

接着就是做各种的刷新和翻页的操作，看终端会不会有输出，感觉这个函数是被掉了两次的

 

 

再看尿壶这边的抓包记录：

这是第一个

 

 

 

明显感觉这个返回值跟实际请求的_t后面部分对上了

 

 

 

 

再看第二个：

 

 

 

完毕，既然这里就是加密的，那看看加密前后到底发生了啥，仔细看可以发现，其实，每请求一个借口的时候，其实掉了两次j.a加密，

 

 

 

 

那基本确定他其实走的上面这个逻辑，那肯定啊，因为能获取到p，

 

 

 

整理一下，也就是这样的逻辑：

 

 

 

 

但还差这最后那一段，乍一看不知道怎么拆

 

 

 

先看源码，

 

 

 

因为a2就是p的值加密后的，所以直接用加密后的p做切割：

 

 

 

 

 

 

再用1645630067确认是不是时间戳，果然是

 

 

 

ok，_t参数搞定。

 

再看stk参数怎么来的：

 

 c.a()点进去，这里synchronized就是做线程保护的，防止数据被影响，

 

 再看.b

 

 

接着跟

 

 

 

 

 

 跟到这里的时候，继续点：

 

 

继续跟进去，看到这个，卧槽，完蛋，native

 

 

 

看来得打开ida搞so层了，不过在打开so之前，我还是做了java层hook验证，有overlaod

 

 

 

 

这里，我有种感觉哈，我感觉得都hook下

 

 

 

 

接着手机拿着各个地方都去点了一下，终端有结果了：发现并不是我们要的数据

 

 

 

 

 

 

那就spawn模式吧

 

 

 

 

值是有了，结果发现app启动之后，居然需要重新登陆了，我启动多次都这样，每次启动全都需要重新登录，而且登录的时候开始有了某验的验证。。。。卧槽，有风控检测？？？？

 

 

头皮发麻呀，

 

然后，我试着去hook这个方法：

 

反正就是hook不到，提示不存在这个类

 

 

有点迷茫了

 

我看到这个报错，突然想起了hookde 另一种，Java.choose，继续刚才那个类的hook，就不用java.use('xxx').$new了

 

 

 

重新换回attach模式，执行，一下就有了，卧槽，可以

 

 

我继续看抓包工具的结果，然后，特么的无意间看到这个接口：这个stk是登录之后返回的.......

 

 

 

作为验证，我拿着这个时间戳去解析，这时间还真的是我刚才登录的时间。。。。

 

 

说实话我真没想到直接就是接口就返回了，而且他的登录接口也没啥东西，是我多虑了，哈哈哈哈哈哈。

那行，over了

 

 

算法还原

按照正常流程，就开始用python仿照下面这个写个算法，然后代码执行，能拿数据就完了

 

 

但是这里，我就暂时不给还原的代码，都很简单，就照着写就完了（其实我根本没去还原，嘻嘻嘻）

 

 

结语

 

唉，虚惊一场，是我想多了，还得是那句，先走基本流程在抓包工具里搜一下看是不是直接返回的再说，其实我也有搜的，搜的时候看到结果太多了，随便展开几个都是在request里，我就以为是在本地生成的我就没细看了

 

 

 

这个app很简单，按正常流程，包括写加密算法还原，应该一二十分钟就能搞定的，只是我想多了，哈哈哈哈哈哈

 

ok，本次分享完毕，下一篇不出意外应该也是个app的案例