一、目标
这个样本和之前的小视频App的套路有点类似。签名的名称和算法估计都是一样的。所以搞明白这个，估计也能搞明白最新版的小视频App。
那看小说和看小视频的区别在哪？
小说越看越困，小视频越看越清醒。足以证明AI比你还要了解你自己。
今天我们的目标就是某小说App v1.0.0.2
二、步骤
搜索 __sig3
才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 的时候被调用了。那么打印堆栈就是最好的解决方案了。
营己良有极 过足非所钦
