最近有人給我展示了一款app，說抓不到它的請(qǐng)求邦危，連上代理一看真的沒有洋侨，所以本文結(jié)束。
一倦蚪、初步試驗(yàn)
連上代理后希坚，app并沒有明顯的提示與彈窗，并且還能夠正常訪問網(wǎng)絡(luò)陵且、獲取數(shù)據(jù)裁僧，說明app本身設(shè)置了代理。
反編譯一下慕购，嗯聊疲？出錯(cuò)了。沪悲。获洲。原來是加了新版的殼。
脫掉殼后可训，發(fā)現(xiàn)使用了OKHTTP的網(wǎng)絡(luò)庫昌妹。對(duì)于一些常用的網(wǎng)絡(luò)庫，其實(shí)提供了設(shè)置代理的接口握截，只需要將其設(shè)置成無代理的模式，它就不會(huì)應(yīng)用系統(tǒng)默認(rèn)的代理了烂叔。去代碼里翻騰一下谨胞，看到很明的設(shè)置了Proxy.NO_PROXY。
這里可以去hook proxy方法蒜鸡，然后取消掉這個(gè)設(shè)置PROXY的過程胯努，讓方法直接返回。也可以繞過這個(gè)逢防，通過VPN的方式叶沛，這里太懶了，直接采用第二種方法忘朝，省事不寫代碼灰署。通過VPN轉(zhuǎn)發(fā)到代理工具，已經(jīng)能抓到包了，又快又省事溉箕。
二晦墙、測(cè)試分析
很明顯的，一共有4處加密的地方肴茄，header中有3個(gè)參數(shù)xx-verify晌畅、xx-sid、xx-traceid寡痰，body中有一個(gè)參數(shù)client_secret抗楔。
通過觀察發(fā)現(xiàn)，xx-verify是64位的拦坠，而xx-sid谓谦、xx-traceid和client_secret相類似，都是32位0-9a-f的形式贪婉，猜測(cè)是md5反粥。
1、client_secret
先來看client_secret疲迂，是很經(jīng)典的md5-salt才顿。這里在map中插入一個(gè)private_key字段，然后排序拼接計(jì)算md5尤蒿。
2郑气、xx-sid、xx-traceid
這兩個(gè)比較簡(jiǎn)單腰池，uuid+時(shí)間戳尾组。
3、xx-verify
xx-verify相對(duì)來說復(fù)雜一點(diǎn)示弓，先通過URLDecoder加工一下讳侨，然后通過native的enMana方法來加密。根據(jù)URLDecoder奏属，猜測(cè)可能跟請(qǐng)求的url有關(guān)跨跨。
enMana方法在libsservice.so文件中。
拖進(jìn)IDA發(fā)現(xiàn)so沒有任何加密措施囱皿，這極大的方便了靜態(tài)分析勇婴。
找到ServerService_enMana導(dǎo)出函數(shù)，修改一下參數(shù)類型嘱腥，簡(jiǎn)化一下視圖后耕渴，可以非常明顯的看到使用了hmac_sha256算法，并且還初始化了一個(gè)秘鑰在getRMN函數(shù)中齿兔。
同樣修改一下getRMN的參數(shù)類型橱脸，發(fā)現(xiàn)是去SharedPreferences中取了一個(gè)叫rmn的字段础米。所以回到j(luò)ava層，去看看rmn的賦值慰技。跟蹤下來知道這個(gè)值是從服務(wù)端獲取的椭盏。
為了快速的驗(yàn)證，這里hook一下enMana函數(shù)的輸入和輸出吻商√图眨可以hook java層，也可以hook native層艾帐。因?yàn)閑nMana這個(gè)是導(dǎo)出函數(shù)乌叶，所以hook起來也很方便。例如使用frida柒爸，這個(gè)不是靜態(tài)函數(shù)准浴，所以我們只關(guān)心第三個(gè)參數(shù)即可：
通過hook得知加密的字符串就是URLDecode后的請(qǐng)求url，key是從SharedPreferences取捎稚，然后使用hmac_sha256加密乐横。這里因?yàn)椴皇莄m，所以魔改加密算法的可能性不大今野。
拖到一個(gè)在線的加密網(wǎng)站中驗(yàn)證一番葡公，結(jié)果完全一樣。
抓包結(jié)果：
加密結(jié)果：
至此就分析完了条霜。
三催什、總結(jié)
1、分析過程中可以更靈活一些宰睡，邊猜邊驗(yàn)證蒲凶。
2、要熟練掌握各種hook的操作拆内，Java&&Native旋圆。
3、在看別人的代碼時(shí)候矛纹，可以借鑒其中的保護(hù)思路臂聋，來提高自己app的安全性。
