app逆向篇之实战案例-某音乐app

提示！本文章仅供学习交流，严禁用于任何商业和非法用途，如有侵权，可联系本文作者删除！

前言

最近初学app逆向，该文章仅用来记录学习分析的过程，如有不对的地方，希望各位大佬能不吝指点

下载地址：apk下载

案例分析：

安装好app之后的第一件事当然是打开app，然后开始抓包，具体如何抓包这里就不多说了，直接看抓包结果，如下：

这个就是抓列的表页数据，直接将请求拿下来本地跑一下，如下：

可以看是能直接拿到数据的，接下就是对请求参数的删减，先确定一下请求头中哪些参数是必须的，测试后发现该接口对请求参数不严格，所以大家象征性的模拟下请求头的参数就行了，之后看下请求携带的参数，下面的参数就先提前给大家备注了，如下：

userid   0          #未登录状态这个是0，写死即可
area_code   1      #写死
appid   1005       #写死
dopicfull   1      #写死
page    1          #列表页页码
token              #登录之后会有，这里置空
privilegefilter 0   #写死
requestid   6c95b8809382f60a7c326a0a8e580ff9_0   #多次测试会发现 "_" 后面的 "0" 代表着请求次数，这个可以写死
signature   3344d8f3b8db824a2d8e90cbf2b72fe9     #生成的加密参数
pagesize    30                                   #当前返回页最大数据条数
clienttime  1678353239                           #10位数时间戳
sec_aggre   1                                    # 写死
iscorrection    1                                #写死
uuid    71620acaced02a7d5fd6cfe785db0ba2         #根据设备生成的uuid
keyword 可能                                   #歌曲名称
mid 12804932379081176379687317521415026304       #根据uuid生成的mid
dfid    2ly9I64QC64Q2MLYrD1KrM6a                 #可以直接写成 "-",这个在研究网页版的时候可以知道其逻辑
clientver   11549                                #写死
platform    AndroidFilter                       #写死
tag em                                          #写死

接下来除了写死的部分不做分析，其余的参数一一来分析一下，首先是requestid，可以看到这个参数的格式是：
xxxx_0，直接在jadx里面搜索一下，如下：

可以看到只有16个结果，然后我圈出来的部分跟其结构很相似，随便找一个点进去，然后进入下图圈出来的方法中，如下：

跳转过去之后如下：

根据这里的逻辑可以看出，它有两种情况每一种是当b2有值的时候就返回b2，b2没有值的时候就会生成a2，返回a2的值，这里直接使用firda来Hook下，生成一下b2，如下：

可以看到这里直接就拿到值了，至于这个值怎么来的还是不太清楚，然后回到前面X方法这里，仔细看一下这段逻辑就可以大致的猜出其逻辑了，一开始b2应该是一个空值，之后获取到a2，然后将a2通过一个方法保存起来，之后每次就可以通过b.a().b(126, “”)方法来获取到该值，经过测试之后是可以确认这个逻辑的，所以该值如何来的就看下a2是如何生成的，前面可以知道生成a2的逻辑如下：

String a2 = d.a(KGCommonApplication.getContext())

直接看一下d.a方法的逻辑，如下：

 public static String a(Context context) {ba baVar = new ba();return baVar.a(br.l(context) + System.currentTimeMillis());
}

接下来就不一一讲解了，继续看下去可以知道baVar.a是一个md5，br.l(context)可以通过Hook来看下返回结果，
System.currentTimeMillis()是获取当前时间戳，接下来通过frida来实现一下这个过程，如下：

71620acaced02a7d5fd6cfe785db0ba2这一串字符有没有很熟悉，如果够仔细的话，可以知道这个值就是前面请求时携带的uid参数，所以到这里requestid的生成逻辑就很明确了，用python实现后来对比下结果，首先将Hook生成的包含时间戳的结果记录下，如下：

在看来看看python生成的结果，如下：

接下来分析Signature，还是一样搜索一下，如下：

发现结果很多，然后我选择了一个迂回点方式，搜索url中的参数，搜索结果如下：

可以发现圈出来的地方和请求的列表url有着相识的地方，抱着试一试的心态，之后点击跳转来到如下位置:

接下来干什么就不用多说了吧，还是使用frida来Hook，Hook啥不必多说了吧，算了，还是多说一点，看一下上图中的b4，可以发现是一个Map，这里先说一下到v.a方法的逻辑：

1.将请求时携带的参数都放进这个map中，也就是得到了这个被b4
2.将b4传进v.a方法中进行处理，b4不为空的前提下，将其所有的参数和值拼接成一个字符串
3.将拼接成的字符串传入v.c方法中

之后进入v.c方法中可以看到如下：

这部分的分析方式和前面讲的requestid的分析方式一致，先获取一下b2，然后看一下ba.c方法，简单记录一下:

b2="OIlwieks28dk2k092lksi2UIkp"  固定值
ba.c方法就是个md5
所以具体逻辑就是:
md5(b2+sr+b2)

到这里Signature的生成逻辑就分析结束了，只需要搞定v.a方法是如何将参数拼接成字符串的就行了，具体如何操作就不说了，整个过程全都可以用python直接还原出来，最后测试下结果：

欢迎关注公众号：【时光python之旅】 (在这里你能学到我的所见、所闻、所思、所学)