一、目標
李老板：奮飛呀，我遇到一個超級牛掰的App，它請求的時候有個data參數(shù)加密，用盡了你介紹的所有的方法，都找不到它是如何加密的。
奮飛：子曾經(jīng)曰過，老板的嘴，騙人的鬼。有這么牛掰的App，那么我們這幫兄弟早就失業(yè)了。
某神奇App v10.1.0
點 社區(qū)-> 隨便打開一篇有評論的文章
今天的目標就是這個 data
二、步驟
搜索特征字符串
目標是data，所以我們第一個搜索 "data"
一共有130多個結(jié)果，開始一個一個點開分析了，逆向木有那么酷，有很大一部分是苦力活。
比如這種 baidu 、 meizu 、tencent 、google 開頭的類，大概率是第三方sdk用的?？梢耘懦簟?/p>
命中的原則就是， "data" 和 "timestamp" 在一起。
遺憾的是木有找到，也許是結(jié)果太多，眼花了，看漏了吧。
不死心，我們再嘗試搜一下 "timestamp" 只要它和 "data"在一起，也算命中。
這次只有40個結(jié)果，一個一個認真的找過去，還是沒找到。這下死心了，說明特征串搜索失敗。
Hook Base64
這個data數(shù)據(jù)看上去超級像Base64，所以我們第一步是Hook Base64
var Base64Class = Java.use("android.util.Base64");
Base64Class.encodeToString.overload("[B", "int").implementation = function(a,b){
var rc = this.encodeToString(a,b);
console.log(">>> Base64 " + rc);
return rc;
}
frida跑起來，spawn 啟動不了，要么說沒有這個包名，用app名稱也提示找不到。
算了，attach倒是成功了。
不過在意料之中，木有任何輸出，李老板畢竟也和我們混了這么多期，肯定他也是試過Hook Base64的。
Hook java.lang.StringBuilder 字符串定位
在java層組裝字符串，大概率是逃不過StringBuilder，我們觀察一下data數(shù)據(jù)的特征。
他們沒有一樣的開頭，但是他們有一樣的身體，字符串里面都含有 +
var strCls = Java.use("java.lang.StringBuilder");
strCls.toString.implementation = function(){
var result = this.toString();
if(result.toString().indexOf("+") >= 0
&& result.toString().length > 150)
{
console.log(" >>> string " +result.toString());
// var stack = threadinstance.currentThread().getStackTrace();
// console.log("Rc Full call stack:" + Where(stack));
}
return result;
}
我們要匹配 + 并且字符串長度大于 150，我掰指頭數(shù)了，data數(shù)據(jù)的長度大概是190多。
frida跑起來，Attach上，依然沒有任何輸出，有點不對勁，我們把 hook StringBuilder的所有輸出打印下，結(jié)果還是沒有任何輸出。
可能Attach模式有問題，必須得 spawn 模式了。
Xcube
被我們冷落了許久的Xcube可以派上用場了，Xcube可以不使用 frida spawn模式啟動，但提供spawn模式一樣的效果，具體使用方法參見 http://91fans.com.cn/post/antifridaoper/。
配置好xcube.yaml 跑起來。
見鬼了，李老板這次沒說錯，居然還是沒有任何輸出。Xcube也不好使了。
換手機
真的，很多時候網(wǎng)友問我，為啥我 hook不上，為啥我啟動不了，為啥我抓不了包。
這個真是玄學(xué)，換個手機也許就好了。
我手頭有好幾個測試機，分別裝了不同的抓包軟件，不同版本的Android系統(tǒng)。
終于在一臺 google pixel 2xl 上 成功的用 frida spawn模式啟動 了app，并且打印出了字符串信息。
當(dāng)然打出了一堆base64數(shù)據(jù)，但是沒有我們想要的數(shù)據(jù)。
hook_libart
java層hook不到數(shù)據(jù)，那么我們就去Native層
if (addrGetStringUTFChars != null) {
Interceptor.attach(addrGetStringUTFChars, {
onEnter: function (args) {},
onLeave: function (retval) {
if (retval != null) {
var string = Memory.readCString(retval);
if(string != null) {
if(string.toString().indexOf("+") >= 0
&& string.toString().length > 150)
{
console.log("[GetStringUTFChars] result:" + string);
}
}
}
}
});
}
if (addrNewStringUTF != null) {
Interceptor.attach(addrNewStringUTF, {
onEnter: function (args) {
if (args[1] != null) {
var string = Memory.readCString(args[1]);
if(string != null) {
if(string.toString().indexOf("+") >= 0
&& string.toString().length > 150)
{
console.log("[NewStringUTF] bytes:" + string);
}
}
}
},
onLeave: function (retval) {}
});
}
再跑一下，依然沒有我們想要的數(shù)據(jù)。
小小的總結(jié)一下
App中的字符串，要么出現(xiàn)在java層，要么出現(xiàn)在Native層。我們都Hook上了，居然還是沒有找到。
只剩下一種可能了，這個字符串木有在App中被處理。
比如說，App中嵌入了一個瀏覽器，運行了一個H5頁面，頁面中js去做的加密和http請求.....
這樣的話，我們就hook不到了。
調(diào)試網(wǎng)頁中的js
從抓包結(jié)果里面我們找到了文章的Get請求
然后可以直接用Chrome打開，
刷新一下，就找到了我們心心念念的 data
還是被李老板騙了，網(wǎng)頁js做的加密，你App里能找到就見鬼了。
既然確定這個 comments-and-reply-encrypt 請求是js發(fā)出的，就好辦了，
搜索一下，發(fā)現(xiàn)它來自于 ArticleDetail.js
雙擊 搜索到的結(jié)果，在 Network 窗口定位這個 js， 然后右鍵 Open in Sources panel 進入到源碼窗口。
源碼有點亂，我們點 {} 圖標格式化一下。
然后在ArticleDetail.js源碼中搜索 comments-and-reply-encrypt
定位到了 getCommentEncrypt
繼續(xù)搜索 getCommentEncrypt ,定位到了一個加密函數(shù) encryptSm4ECB
這么牛掰的名字，大概率是我們心愛的 data 加密了。
函數(shù)還是很清晰的，返回了 data和timestamp。
給它下個斷點，然后重新刷新一下頁面。 成功觸發(fā)了斷點。
搞定，收工。
三、總結(jié)
字符串一定是有跡可循，apk中不出現(xiàn)，運行時也一定會出現(xiàn)。
現(xiàn)在開發(fā)App的手段多種多樣，傳統(tǒng)手藝也不能丟，這個樣本就是鼓搗了半天，萬萬沒想到就是個網(wǎng)頁。
排除所有不可能的因素之后，無論剩下的多么難以置信，那就是真相。
