某小说App __sig3签名分析

一、目标

这个样本和之前的小视频App的套路有点类似。签名的名称和算法估计都是一样的。所以搞明白这个,估计也能搞明白最新版的小视频App。

那看小说和看小视频的区别在哪?

小说越看越困,小视频越看越清醒。足以证明AI比你还要了解你自己。

今天我们的目标就是某小说App v1.0.0.2

二、步骤

搜索 __sig3

main.png

才5个结果,仔细找找,发现了这个 atlasSign 函数,

再搜索下 atlasSign 函数,虽然这次调用的地方很对,但是我们一眼就发现了一个老朋友

com.kxxxxxou.android.security.KSecurity

首先它的名字起的太有个性了,其次是上次在分析小视频App的时候也是他做的签名。

Hook atlasSign

var KSecurityCls = Java.use("com.kxxxxxou.android.security.KSecurity");
KSecurityCls.atlasSign.implementation = function(a){
    var rc = this.atlasSign(a);
    console.log(TAG + "atlasSign a = " + a);
    console.log(TAG + "atlasSign >>> rc = " + rc);
    return rc;

}

跑一下,结果是有了,但是hook输出的是48位的数据,并不是我们抓包到的70多个字节的乱七八糟的数据。

下面有两个方案:

1、坚信我们是对的,做__sig3签名一定调用了atlasSign,只是可能把这个48位的签名再做了某种变化。这样的话,我们打印下堆栈就行了;

2、看抓包的结果还是很像Base64,虽然没有== 之类的Base64必须特征,但是凭这么多期的经验,还是可以hook一把Base64试试。

打堆栈

fenfeixs: java.lang.Thread.getStackTrace(Thread.java:1720)
fenfeixs: com.kxxxxxou.android.security.KSecurity.atlasSign(Native Method)
fenfeixs: k.w.e.a1.t.a(SourceFile:34)
fenfeixs: k.w.e.a1.t.a(Native Method)
fenfeixs: k.h.d.h.d.intercept(SourceFile:111)

狐狸尾巴漏出来了,这个 k.w.e.a1.t.a 应该就是我们的目标了

var ffSignCls =  Java.use("k.w.e.a1.t");
ffSignCls.a.overload('java.lang.String', 'java.lang.String', 'java.util.Map').implementation = function(a,b,c){
    var rc = this.a(a,b,c);
    console.log(TAG + "a = " + a);
    console.log(TAG + "b = " + b);
    console.log(TAG + "c = " + c.entrySet().toArray());
    console.log(TAG + ">>> rc = " + rc);

    return rc;
}

再跑一下,结果出来了,果然就是 __sig3

fenfeiksxs: >>> rc = VVftYQGnh_1jN2Q2ODU4NTVjN2U0NmU1ZGM4ZjhjOGQwYjA0MDA5OGMyNDhkN2Y2OTM5ZTkwODY

大概分析了一下,他就是把 atlasSign 的结果做了一个Base64,然后把明显的 + / = 都替换掉。

入参里面还有个 dpbs 是加密的,不过这个就比较好解决了,都在 k.w.e.a1.t.a 类里面。

三、总结

刚拿到这个样本的时候我也疑惑了一下,虽然他绕了好几个圈子,但是很方便的可以定位到atlasSign。

正以为大功告成的时候,才发现atlasSign的结果是48位,和抓包结果不符。

这时候就得相信自己了,首先atlasSign被触发了,说明大概率做 __sig3 的时候被调用了。那么打印堆栈就是最好的解决方案了。

ffshow.jpeg

营己良有极 过足非所钦

你可能感兴趣的:(某小说App __sig3签名分析)