某小说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

营己良有极过足非所钦