概述
隨著智能終端的不斷髮展，應用數量和app應用種類不斷擴大的同時，各類應用安全問題也不斷湧現，例如惡意代碼注入、發送虛假座標、刷屏、刷票、用戶敏感信息洩露。app在設計開發階段，需要根據業務場景考慮多種安全策略。比如在數據傳輸方面，很多app為保證數據的機密性和完整性，會對發送的請求數據做加密和簽名處理。那麼，作為一名白帽子，又如何繞過這些安全策略呢？今天我們自己搭建壞境測試下。
環境搭建
為了便於演示和測試，我們需要自己搭建一個測試環境，主要分為客戶端和服務端的搭建。
app客戶端
首先，我們需發一個app的demo，在點擊按鈕後會發送一個加密請求到服務端，如下圖所示：
在MainActivity中，監聽到Button按鈕點擊後，使用子線程執行http請求。返回信息回調給主進程的webview組件。http請求函數sendRequestWithHttpClient()如下圖所示。這裡先將原始 xml字符串 使用aes對稱加密，作為post數據。再將加密結果hash運算後與時間戳等因子生成簽名 signature ，signature和因子放在url中供後臺服務器校驗使用。
服務端
服務端獲取因子和post數據後會重新hash校驗，校驗通過再使用對稱解密獲取數據，（這裡我將解密後的xml數據重新加密發送給客服端）：
請求
安裝demo後，使用burpsuit抓取客戶端發送的請求，可以看到post的是AES加密的數據，url中是因子和signature，如下：
下圖是request body和url中參數的邏輯圖形。body是由明文數據aes加密得到，參數l由body hash運算生成，參數s由時間戳和token等因子生成。若改變body或相關參數，服務端將驗籤失效。
解密繞過
其實很早之前我寫過一篇xposed hook加密函數的方法，請參考 https://mp.weixin.qq.com/s/zCGkfrDfCNjBA9qht4MiiQ
所以我們這次使用frida的工具嘗試下。
frida
這裡我們使用frida去hook app中的加密函數，讓其直接post明文數據。
1.首先，需要下載對應版本的fridaserver，建議放在/data/local/tmp目錄下，給與權限後執行。（在此之前建議關閉selinux防火牆，使用命令 setenforce 0 ）
2.端口轉發
adb forward tcp:27042 tcp:27042
adb forward tcp:27043 tcp:27043
使用 frida-ps -R 出現進程列表則表示沒有問題。
3.frida提供了豐富的js api接口，供我們對需要調試的進程進行hook。我們查看需要hook的函數（可以修改該函數接受的參數、函數輸出值、覆蓋重新定義該函數）：
函數的參數為String類型的明文和String類型的key，我們hook類AESTool中的函數Encrypt()，讓其直接輸出明文，繞過其加密過程,如下圖所示：
將該js注入到進程中：
點擊app發送請求的按鈕，可以看到加密的函數已經被繞過， request body明文顯示。 但是由於request body被改動，服務端驗籤將會失敗。在安全測試的時候，不能改動請求參數那便如鹹魚一樣，xss、sql、越權等漏洞彷彿與你隔著一層難以逾越的鴻溝。所以，我們需要重新構造請求給服務端，最簡單的辦法就是編寫burpsuit的插件。
burp插件
我們可以利用burpsuit提供的接口實現插件的開發。新建項目，將burpsuit提供的api導入後，新建BurpExtender.java類，重寫processHttpMessage()方法。我們將app客戶端使用的加密和簽名使用的類也導入，根據客戶端的加密和簽名邏輯，重新構造請求，並將構造的請求打印在後臺:
使用fat jar exporter將項目導出jar文件， burpsiut中添加插件並勾選插件 ，重新抓包，查看插件打印的輸出，可以看到 所又經過burp的請求將被插件重新以app客戶端的邏輯構造 ：
關閉插件 ，單獨發送該請求驗證burp插件構造的請求是否可以通過，成功：
這樣測試人員便可以隨意修改抓取的數據。同理，服務端返回的數據是加密的，同樣可以在插件中解密，不做贅述。
總結
Frida提供的api有很多，這裡只是簡單的介紹，還值得我們去深入瞭解。app安全策略還有很多，比如https證書檢驗、root環境檢測等等，同樣的道理，很多業務場景需要我們去發揮想象去做一些有趣的事情。
閱讀更多 混在軟件圈 的文章
