一、目標
這個樣本和之前的小視頻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 的時候被調用了。那么打印堆棧就是最好的解決方案了。
營己良有極 過足非所欽
