某APP安全檢測 (360脫殼+演算法分析+資料中轉注入)

https://www.t00ls.net/articles-45803.html

   最近對某一APP進行安全檢測，整個過程花費幾天時間，最耗時的就是寫中轉指令碼實現資料的自動加密解密過程，而且過程中遇到許多小問題，折騰了許久。

1.        360脫殼
    因為APP是被加固了，要想擷取更多有價值的資訊或者是想更快的對資料包的密碼編譯演算法進行分析最好的辦法就是查看源碼關鍵的加密函數，所有第一步就是對APP進行脫殼。
貌似網上有對360加固的脫殼程式，但是還是習慣用之前的方式脫殼：android-sdk-windows中的模擬器和ddms.
(1), 查看加固方式
查看APP加固方式，可以看到是360加固


(2) 建立模擬器
使用安卓SDK建立一個原生的模擬器：

然後啟動我們建立的那個名字為360的模擬器（這個啟動要很長時間。。）
在設定中的開發著模式中更改系統啟動方式:


更改runtime為ART方式，然後重啟模擬器。



(3) 脫殼
模擬器重啟後使用adb調試工具安裝已加固的APP到模擬器： adb install xxx.apk
然後運行安卓的監控程式ddms

所有的app的連接埠和日誌資訊都會顯示在這裡。


然後運行我們剛剛安裝的app,日誌就會顯示harvey:dex file name-->/data/data/APP包名字/.jiagu/xxx.dex

會自動把加固的dex 解密並dump到 .jiagu 目錄，我們直接 使用adb把整個jiagu目錄全部複製一份到我們電腦上： adb pull /data/data/com.baidu.com.app/.jiagu d:/aa/
有很多dex檔案我們就可以反編譯dex了。


2.        密碼編譯演算法分析
使用jd-gui對dex進行反編譯查看關鍵加密代碼。

一般在進行對密碼編譯演算法進行判斷時，通常最簡便的方法是直接搜尋索引鍵：login、password、AES、DES、Sign、token、RSA等關鍵字。

可以看到其中一部分加密是AES加密，加密的位移量IV明文的在字串中。其中還有其他的演算法RAS的演算法：使用伺服器的公開金鑰加密部分資料到伺服器。

代碼雖然被被混淆了，但是基本的方法大概還是能看懂。

3.        動態資料分析
APP採用的HTTPS通訊，要想捕獲HTTPS的流量，需要在模擬器上安裝BP或者FD的認證。
(1)        解密HTTPS資料
解密HTTPS的資料需要用到xposed架構和JustTrustMe外掛程式。


現在BP監聽所有IP或者內網IP的地址


開啟測試的模擬器測試是否抓到資料包。運行APP查看抓包的資料：
發送的資料全加密：

返回資料全加密：


可以看到每個請求時發送的三段密文，三個密碼編譯演算法組合驗證資料。

(2)        動態分析通訊資料
之前靜態分析密碼編譯演算法只知道大概的演算法，沒有具體驗證加密資訊，這裡通過動態分析可以明確密碼編譯演算法和key。
使用inspeckage外掛程式對APP的相關函數方法進行hook（具體什麼功能我也說不清楚，能看到很多有用的資訊）。
大概的功能有：
功能一：擷取APP基本資料
【1】許可權：請求許可權（Requested Permissions）、自訂許可權（APP Permissions）
【2】組件：匯出和非匯出的組件（Activity、Service、Broadcast Receiver、Content Provider）
【3】共用庫（Shared Libraries）
【4】標誌位：Debuggable，Allow Backup
【5】其他：UID，GIDs，Package等

功能二：即時查看應用程式的行為
【1】Shared Preferences（日誌和檔案）
【2】Serialization（序列化）
【3】Crypto（加密）、Hash
【4】SQLite資料庫
【5】HTTP、WebView、IPC等
【6】Hooks（自訂HOOK）

功能三：其他動作

【1】開啟任意Activity組件（匯出和非匯出）
【2】調用Provider組件（匯出和非匯出）
【3】開啟、停止、重啟應用程式

大概用法：
運行inspeckage開啟要監視的APP。

點擊啟動APP，電腦用戶端運行： adb forward tcp:8008 tcp:8008
瀏覽器開啟本地127.0.0.1：8008

點擊ON開始監聽，

可以看到部分加密的資料是AES加動態key和固定的IV進行加密。資料包中還有2種加密都體現在這裡。

4.        加密解密指令碼
要實現對資料包的篡改就必須對原密文解密然後再修改資料在加密發送伺服器
知道了演算法現在就通過python指令碼對資料進行加密解密。
AES的AES/CBC/PKCS5Padding加密：

AES/CBC/PKCS5Padding解密用一個線上的吧： http://www.seacha.com/tools/aes.html

這個演算法解密不需要指令碼，直接解密一次明文，然後是重複修改明文再通過加密指令碼發送修改後的資料。伺服器返回的資料是密文也是需要指令碼來進行解密。還有其他2段的密碼編譯演算法就不舉例了。

5.        資料中轉注入
因為整個APP通訊除了使用HTTPS加密傳輸，而且每個資料包的請求都是動態key+iv的加密，並且還要隨時更改資料包中的其他2段加密才能正常正常發送伺服器才能解析。
如果要測試越權或者注入之類的漏洞，並且要通過注入擷取資料的話，手工的話得累死人，所有要實現資料的中轉。
整體流程：首先本地請求明文資料到代理服務器—》代理服務器對請求包各種加密校正—》發送伺服器---》解密伺服器響應—》發送用戶端。
因為各種密碼編譯演算法都是python指令碼支援的，所以中轉使用python的BaseHTTPRequestHandler來實現，發送http請求用urllib2來實現。
大概代碼：



這個當時被這個負載平衡IP鬱悶了很久，在APP上登入一切正常，但是中轉指令碼走的資料一直提述未登入，找了好久好久的問題，最後發現每隔一段時間走的IP不一樣（IP地址不知道是什麼規則，不是網上的那個F5的規則），
而且就差一個字元不一樣，一直沒有發現，導致耽誤很久。然後就是IP和前面的cookie之前必須有個空格，MD之前感覺各種都對的，返回總是提示未逾時，害得我一個一個字元找問題。。。。
中轉的指令碼使用代理是為了方便我資料直接走BP，因為BP走的資料可以與伺服器直接HTTPS通訊。我的python指令碼不想再去搞什麼HTTPS認證了，直接發送給BP，BP發送到伺服器。
然後跑注入漏洞直接： python sqlmap.py -u “ http://192.168.0.10/id=1” 就Ok了。

最後附上一張測試的測試的效果圖：