目标样本版本12.2.2(最新版地址可能会发生偏移以及变化)
jadx打开样本 开始定位sign的生成逻辑
采用搜索
x-api-eid-token的方法来定位
发现在此处进行引用,从函数功能可以分析出,这是在组包,并返回组装完的字符串
按经验来说,组装成字符串之后就要加密了,我们按x 查找函数上一层引用
发现上一层函数也在组包,返回的也是str类型
继续网上寻找,发现同上
继续向上寻找:
最终找到加密位置
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
发现加密的是一个接口
我们要找实现这个类型的方法
implements ISignatureHandler
搜索不到
所以我们直接搜索 ISignatureHandler
发现在这个类里有一定线索
在初始化时传入了
查找调用此函数的位置的方法
在initapp中传入了,我们往上跟入
进入方法查看
原来是使用new创建的 所以下次搜索可以使用
1 |
|
来搜索定位
定位到关键函数,接下来进行hook 并主动调用:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
发现疑似是hash函数
hook dlsym函数,得知函数加载的so
libjdbitmapkit.so
定位到要分析的函数,由于位数疑似md5,所以使用龙哥的findhash插件,进行寻找
熟悉的朋友应该认出了,这个就是md5运算部分,我们寻找上层引用
再次寻找上层引用
发现调用位置就在我们目标分析的函数里(如果没跟到的小伙伴可以打印堆栈)
我们进行hook来分析入参
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
|
发现入参是一段base64,解密后是乱码
在md5前,明文进行了额外处理:
v39是我们要分析的密文,
继续往上跟踪v39生成的位置
经过hook可知
密文由sub_18c9c计算而来
其中两个参数是rand随机生成的
在这里决定了sign由哪个函数进行加密
今天我们分析case2里面的加密函数,也是最简单的,后面我会分析剩下两个算法的计算方法
算法肉眼可见的可以复现,所以我们进行hook入参和出参进行分析
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 |
|
不是所有的call都能触发这个分支,得多call几次
我们可以看到明文数据了
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 |
|
修改脚本 拿到arg1的key
afcb2afb1f349bed06555aef7fd47cecbec115c6083eafa51f608df10bdd350bab2a21cb1ffb6cb7df2b9dea43cf07ccaaf12ffd1b378cf126678edb57840d1ebbcb2184c52ca2ee265595e144cf35c4aff728cb08ef5ee11f658f9a088435f66bf03ef931275eb9df4382dc7bd335f66bf031cb0c2991f2284586e873840dcc6b82eefa1c2da0a1f7134ba430c5401ea2d12bfc08ed76b6ef1d4bdb47de5013adb0e688f7ed9ff728bfb4cc43cb41cc63fc31c437ef5eeb1e63b0c57dce7c368efc31c5c5c56f93df55b6eb42d4400dbddf20baddf358a122668ede309c790b95c12184c520a2e42b6596dc309c3517a2de15cb1f2aaef814419be772df7a1e....省略
使用c语言进行复现,发现结果一致,接下来把结果from hex 再base64
把base64进行md5加密 即可得到京东的sign
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
|
至此,我们已经完成了最容易的一个分支的京东sign的计算