前言
最近在學app，有我覺得值得記錄的我就寫寫
這次的案例就是某社交app，包名：Y29{deleteme}tL{deleteme}mJha{deleteme}Whl，難度程度我覺得算簡單，但是容易有誤區。
環境準備
- 一臺已root的真機，我選用的n6p
- postern抓包工具，詳細的配置就不說了，網上搜
- 一臺裝有frida，jadx，尿壺的電腦
- 上述說的app，版本好，11.4
由於我的手機系統是安卓8，所以我就下載的frida-server 12.8.0，對應的python庫也是12.8.0，安裝：
pip3 install frida==12.8.0
frida-tools==5.3.0
分析
事先說明下，這個app需要登錄，所以如果想跟着搞一波的，你可能得註冊一個賬號。我是很早就因爲某原因就註冊了的（真不是各位哥哥姐姐想的那啥，當時就是在某公司做某項目才註冊的，至今記得同事小姐姐看到我手機上裝了有這種軟件後那種嫌棄的表情，真不是爲了那啥的.......）
電腦打開尿壺，手機配置好postern開始抓包
發現，有多個接口
只有這個接口才是真的數據接口，然後看到是post請求，帶了4個請求參數
返回數據就是我們要的小姐姐了，呸，（手動撤回），返回數據就是我們要的就是數據了。
然後多次翻頁，多次刷新，發現這四個參數基本固定存在，有部分接口的4個參數對應的值不太一樣而已。
先看第一個，userID不說了，就是我的用戶id，後面就是些參數，然後有個接口會帶有經緯度的參數，當然這裏的是沒有的
再看第二個，感覺【_】左邊的就是時間戳了，右邊的估計就是加密字段，而且相同的接口每次請求都不一樣，那盲猜是帶了有時間戳作爲加密。
說實話哈，可能有經驗的老哥哥看到後面的數字，其實很敏感的，直接拿去算下長度：
32位，盲猜一波這個算法很可能是md5，這個搞得多的老哥可能會有這種意識
再看第三個，這個參數就有點長了，但是仔細看，就是帶了很多的設備參數，有些敏感的我就打碼了，這個參數基本不變，每個請求接口都是固定的（那肯定啊，你設備參數還能變不成對吧？）
再看最後一個，我打碼的地方是固定的，因爲帶有了這個app的特徵。前面那個依舊是時間戳子彈，後面的就是一些加密字段了。
一般這種參數，按常規的app防護手段，都會用設備參數在本地加密後去服務端註冊，等待風控檢測，風控過了之後會返回一個值，說實話我看着這個stk就很像這種東西，這裏先不表，後面再說
OK，總結下，四個參數裏，要搞定的其實就是第二個_t和第四個stk，下面開始分析參數生成
參數定位
打開jadx，先搜一波：
直接點第一個進去，臥槽？這麼簡單，4個參數都在
再看後面的：
根據我的分析發現，基本確定就是我剛纔進的第一個了，那就先看_t吧，先看上面的，這不就是第三個參數裏的字段嗎哈哈哈哈，這裏可以不用管，反正基本是固定的，再看我已經標註出來的，1和2的位置
反正意思就是_t有兩種，如果獲取到了第一個參數，就加進去加密，否則則直接加密。
然後再看最後一個參數stk，基本是一個寫法。
好的，位置是找到了，開始寫hook代碼
hook調試
手機連上電腦，adb shell進入手機終端，然後啓動frida，怎麼選用手機對應的frida版本在之前的文章有，這裏就不細說了
好執行後，只要不報錯就是啓動成了
先看看_t參數怎麼來的
繼續看看jadx的邏輯，讀邏輯知道，是用的j.a做的加密
點進j.a看看，臥槽，這不就是md5嗎，但是感覺是他自己稍微做了魔改的，那無所謂的，反正能用就行了
開始hook 這個j.a之前，hook腳本編寫，這裏我用的pycharm，說實話個人還是用不慣vscode，還是習慣pycharm
終端執行，選用的attch模式進入，好的，沒報錯，說明附加上了
現在app還是打開狀態，此時先把尿壺裏的抓包記錄清理一下：
接着就是做各種的刷新和翻頁的操作，看終端會不會有輸出，感覺這個函數是被掉了兩次的
再看尿壺這邊的抓包記錄：
這是第一個
明顯感覺這個返回值跟實際請求的_t後面部分對上了
再看第二個：
完畢，既然這裏就是加密的，那看看加密前後到底發生了啥，仔細看可以發現，其實，每請求一個藉口的時候，其實掉了兩次j.a加密，
那基本確定他其實走的上面這個邏輯，那肯定啊，因爲能獲取到p，
整理一下，也就是這樣的邏輯：
但還差這最後那一段，乍一看不知道怎麼拆
先看源碼，
因爲a2就是p的值加密後的，所以直接用加密後的p做切割：
再用1645630067確認是不是時間戳，果然是
ok，_t參數搞定。
再看stk參數怎麼來的：
c.a()點進去，這裏synchronized就是做線程保護的，防止數據被影響，
再看.b
接着跟
跟到這裏的時候，繼續點：
繼續跟進去，看到這個，臥槽，完蛋，native
看來得打開ida搞so層了，不過在打開so之前，我還是做了java層hook驗證，有overlaod
這裏，我有種感覺哈，我感覺得都hook下
接着手機拿着各個地方都去點了一下，終端有結果了：發現並不是我們要的數據
那就spawn模式吧
值是有了，結果發現app啓動之後，居然需要重新登陸了，我啓動多次都這樣，每次啓動全都需要重新登錄，而且登錄的時候開始有了某驗的驗證。。。。臥槽，有風控檢測？？？？
頭皮發麻呀，
然後，我試着去hook這個方法：
反正就是hook不到，提示不存在這個類
有點迷茫了
我看到這個報錯，突然想起了hookde 另一種，Java.choose，繼續剛纔那個類的hook，就不用java.use('xxx').$new了
重新換回attach模式，執行，一下就有了，臥槽，可以
我繼續看抓包工具的結果，然後，特麼的無意間看到這個接口：這個stk是登錄之後返回的.......
作爲驗證，我拿着這個時間戳去解析，這時間還真的是我剛纔登錄的時間。。。。
說實話我真沒想到直接就是接口就返回了，而且他的登錄接口也沒啥東西，是我多慮了，哈哈哈哈哈哈。
那行，over了
算法還原
按照正常流程，就開始用python仿照下面這個寫個算法，然後代碼執行，能拿數據就完了
但是這裏，我就暫時不給還原的代碼，都很簡單，就照着寫就完了（其實我根本沒去還原，嘻嘻嘻）
結語
唉，虛驚一場，是我想多了，還得是那句，先走基本流程在抓包工具裏搜一下看是不是直接返回的再說，其實我也有搜的，搜的時候看到結果太多了，隨便展開幾個都是在request裏，我就以爲是在本地生成的我就沒細看了
這個app很簡單，按正常流程，包括寫加密算法還原，應該一二十分鐘就能搞定的，只是我想多了，哈哈哈哈哈哈
ok，本次分享完畢，下一篇不出意外應該也是個app的案例