# 某某查App 请求头Authorization 逆向

抓包

data参数如图，没什么好说的 手机号和密码的 Md5
image-20230621175205861

请求头参数如下：

image-20230621175124521

看到这么多参数我眼都花了，经过一个个参数删减（拦截修改请求）测试，最终需要逆向的参数只有Authorization

分析

既然要分析参数那肯定要对 app 进行一些 hook，看看这个参数是从哪来的，怎么生成的

遇到这种情况可以直接用Java 层常见加密通杀方案过一遍，说不定就直接解决了

结果当然是没有解决，不然我也没必要写了

下面开始正常流程分析

1. 脱壳拿到源码

先看是什么加固方式

image-20230716192234483

爱加密加固，直接脱壳即可，过程不在详细说

2. 静态分析

直接搜索Authorization

image-20230716192730751

image-20230716192752597

我们直接进入 a0函数

image-20230716192819424

使用 Frida Hook b0的两个入参

得到如下结果：

第一个参数：imei-not-exist

第二个参数：1686888384131 （时间戳）

进入 b0 函数

image-20230716193116362

实际上是把一个字符串经过自写加密函数，得到最终的Authorization

进入JMEncryptBoxByRandom.encryptToBase64看看到底是什么

image-20230716193515988

嗯，就是把字符串转换为字节数组然后经过一个encryptByRandomType2函数，随机打乱 字节数组，然后再 base64 即可

注意看这个encryptByRandomType2

image-20230716193557977

native类型 说明加密逻辑在 So 层。

就不去 so 层看了，太麻烦，我们直接 hook最开始的 a0 函数即可

1
2
3
4
5
6
7
8
9
10
11
12
13
function getAuthorization() {
    // 执行 a0 得到结果
    var G3 = Java.use('com.tianyancha.base.utils.g3');
    var res = G3.a0();
    console.log('a0 的结果是 : ' + res);
    return res
}


rpc.exports = {
    getauthorization: getAuthorization
}

大功告成。