聲明
由于傳播、利用此文所提供的信息而造成的任何直接或者間接的后果及損失，均由使用者本人負(fù)責(zé)，雷神眾測(cè)以及文章作者不為此承擔(dān)任何責(zé)任。
雷神眾測(cè)擁有對(duì)此文章的修改和解釋權(quán)。如欲轉(zhuǎn)載或傳播此文章，必須保證此文章的完整性，包括版權(quán)聲明等全部?jī)?nèi)容。未經(jīng)雷神眾測(cè)允許，不得任意修改或者增減此文章內(nèi)容，不得以任何方式將其用于商業(yè)目的。
No.1
抓包
App抓包已經(jīng)是一個(gè)老生常談的話題了，但不得不說(shuō)抓包才是真正的開(kāi)始，這里推薦兩個(gè)個(gè)人常用的抓包方法：
1、模擬器+Proxifier
如果App可以在模擬器里正常使用，首選該方法，方便快捷！
Proxifier抓模擬器進(jìn)程的包，即可讓模擬器上的流量上代理，然后過(guò)Burp Suite即可。以夜神為例：
首先開(kāi)啟Burp Suite代理（127.0.0.1：8080），然后在Proxifier添加代理服務(wù)器（127.0.0.1：8080），再添加一條通行規(guī)則：
啟動(dòng)模擬器，可觀察到流量情況（導(dǎo)入證書(shū)）：
抓微信小程序：
2、Frida+SSL Bypass
上述方法遇到失敗的情況，就需要掏出 Frida (https://github.com/frida) 神器了，通過(guò)Hook掉關(guān)鍵校驗(yàn)點(diǎn)（需逆向分析）來(lái)達(dá)到抓包的目的，不過(guò)已經(jīng)有很多完善好的bypass腳本，無(wú)需再去逆向直接拿來(lái)用就行（大部分情況），也推薦兩個(gè)：
(1)frida-codeshare的熱門(mén)腳本：universal-Android-ssl-pinning-bypass-with-frida(https://codeshare.frida.re/@pcipolloni/universal-android-ssl-pinning-bypass-with-frida/)
(2)瘦蛟舞大佬的DroidSSLUnpinning
(https://github.com/WooyunDota/DroidSSLUnpinning)
覆蓋場(chǎng)景非常全面，個(gè)人比較推薦，比f(wàn)rida倉(cāng)庫(kù)那個(gè)效果好。
/*
hook list:
1.SSLcontext
2.okhttp
3.webview
4.XUtils
5.httpclientandroidlib
6.JSSE
7.network_security_config (android 7.0+)
8.Apache Http client (support partly)
9.OpenSSLSocketImpl
10.TrustKit
11.Cronet
*/
舉個(gè)案例
只導(dǎo)入Burpsuite證書(shū)，設(shè)置代理，打開(kāi)App，提示證書(shū)不可信，無(wú)法抓到流量：
不要使用WIFI處的高級(jí)代理（App會(huì)檢測(cè)當(dāng)前網(wǎng)絡(luò)環(huán)境），開(kāi)啟ProxyDroid，也會(huì)出現(xiàn)同樣的問(wèn)題。
開(kāi)啟proxydroid，frida注入ssl-pinning腳本：
成功在burpsuite抓到流量。
其他
JustTrustMe：了解Xposed的同學(xué)應(yīng)該都知道這個(gè)，正常安裝、啟用插件即可。
No.2
接口挖掘
除了抓包可以看到一些請(qǐng)求外，還可以主動(dòng)通過(guò)代碼文件尋找隱蔽接口，主要用到的工具是grep。
前提是拿到無(wú)殼/已脫殼dex文件，無(wú)殼App的dex文件直接在反編譯工具（如jadx）打開(kāi)就可以讀JAVA源碼，或者使用更方便的grep來(lái)查找字符串：
查找所有HTTP服務(wù)地址（擴(kuò)展其他服務(wù)、ftp等）：
提取所有IP地址：
可以做一個(gè)去重，然后整理到資產(chǎn)表里，進(jìn)行下一步工作。Tips：分析App之前adb logcat開(kāi)啟日志輸出，操作完之后對(duì)日志做一次grep過(guò)濾，或者其他感興趣字符串比如password、token等等，也會(huì)有意外收獲。
No.3
雙端差異
目標(biāo)業(yè)務(wù)既有Web端，也有App，往往在App一側(cè)會(huì)“忽視”參數(shù)加密的問(wèn)題，或者是套用Web的前端加密算法過(guò)來(lái)，列舉幾個(gè)案例：
1、同一登錄接口，Web端做了復(fù)雜加密，爆破等操作遇到困難，然而抓包App登錄請(qǐng)求發(fā)現(xiàn)未加密，或者是用戶(hù)名未加密。同一系統(tǒng)不同“端”加密：
2、同樣是登錄接口，Web端有圖形驗(yàn)證碼校驗(yàn)，App登錄無(wú)需圖形驗(yàn)證碼，用App的包爆破之。同一系統(tǒng)的不同“端”登錄：
關(guān)于前端加密的處理方式有很多，比如burpsuite的jsEncrypter插件等，如果是App自己實(shí)現(xiàn)了一套加密方法，就需要跟進(jìn)代碼去分析。
No.4
歷史版本
由于App版本更新迭代的緣故，或許某個(gè)版本沒(méi)加殼、報(bào)文未加密、使用老版本加密算法等等問(wèn)題，可通過(guò)找歷史版本App進(jìn)行分析。
豌豆莢歷史版本：
No.5
其他
從Web出發(fā)，通過(guò)對(duì)App的流量、接口分析，回歸到Web測(cè)試，或許會(huì)得到不錯(cuò)的效果。
