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了。

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