android黑科技系列——分析某直播App的協議加密原理以及調用加密方法進行協議參數構造

標籤：輸出   而在   置疑   crypto   點贊   sed   全域   hook   .net   

一、前言

隨著直播技術火爆之後，各家都出了直播app，早期直播app的各種請求協議的參數資訊都沒有做任何加密措施，但是慢慢的有人開始利用這個後門開始弄刷粉關注工具，可以讓一個新生的小花旦分分鐘變成網紅。所以介於這個問題，直播App開始對網路請求參數做了加密措施。所以就是本文分析的重點。逆向領域不僅只有脫殼操作，一些加密解密操作也是很有研究的目的。

 

二、抓包查看加密協議

本文就看一款直播app的協議加密原理，以及如何擷取加密之後的資訊，我們如何通過探針技術，去調用他的加密函數功能。首先這裡找突破點，毋庸置疑，直接抓包即可，我們進入主播頁面，點擊關注之後，看Fiddler中的抓包資料：

我們會發現，請求參數中，有些重要訊息，比如使用者的id，裝置的imei值等。不過最重要也是我們關心的就是s_sg欄位了，因為這個欄位就是請求參數資訊的一個簽名資訊。也是服務端需要進行比對的資訊。如果發現不對或者沒這個欄位，那麼就認為這次請求操作是非法的。所以我們只要得到這個欄位的正確值，才能類比訪問此次操作的網路請求。

 

三、分析加密流程

找到突破口了，就是這個欄位s_sg，用Jadx開啟app的dex檔案，開啟dex檔案之後，全域搜尋s_sg字串：

這裡看到只有一處出現了這個欄位值，我們點進去查看：

看到這個方法，很興奮，感覺就是加密協議的功能，而且欄位都能對上，我們把這個加密方法直接拷貝出來，寫一個demo之後類比加密之後的資訊，悲傷的是探索資料是對不上的，而且看看這個方法所在的類：

盡然是一個和網頁互動的類，說明應該不是這個地方進行請求加密了。這個突破口就斷了。

注意：這裡說的是dex檔案，不是apk檔案，因為Jadx開啟apk檔案會解析資源檔，如果一個app有很多資源檔，那麼Jadx開啟就會卡死，所以很多同學問我為什麼Jadx開啟apk檔案就出現卡死狀態，主要是因為解析資源檔導致的。所以為了防止卡死，直接解壓出dex檔案，然後開啟就不會卡死了。

我們繼續上面的抓包資訊，就是請求的url地址，再去Jadx全域搜尋：

找到了，點進去查看：

然後全域搜尋這個”USER_RELATION_FOLLOW”字串：

搜到結果，點進去進行查看：

這裡看到了，用了註解方式來構造請求資訊，而這裡的核心類就是InkeDefaultBuilder，全域搜尋這個類：

可惜沒搜到，因為這個app進行拆包操作，有多個dex檔案：

所以我們需要用Jadx繼續開啟他的第二個dex檔案進行搜尋：

果然，在第二個dex中找到了這個類。

注意：

這裡需要注意，對於Jadx開啟dex或者apk檔案之後，跟蹤發現找不到一些搜尋內容的時候，需要有如下猜想：

第一、是否包含多個dex檔案，可以利用Jadx去開啟其他dex檔案進行搜尋。

第二、是否存在動態載入外掛程式功能，全域搜尋DexClassLoader找到外掛程式載入位置，擷取外掛程式功能包，在用Jadx開啟外掛程式包進行搜尋。

第三、是否存在so檔案中，可以利用IDA開啟so檔案，Shift+F12展示so中所有的字串資訊視圖，然後進行搜尋。

第四、是否資訊來源於網路請求返回，比如一些字串資訊展示，有可能是伺服器返回的資訊。

繼續分析，點進去查看這個類的定義：

查看他的父類資訊：

看到有一個url加密的方法，比較好奇。我們查看這個方法：

繼續查看這個方法：

這裡發現有一個網路請求，會發現一些資訊，然後設定到一個地方。我們繼續看方法：

看到d變數的定義類型，一般我們看到不可點擊的可能這個類不在這個dex檔案中了，所以我們需要去另外一個dex檔案進行尋找，而本文案例就是來回這麼折騰尋找資訊操作的，去另外一個dex檔案中進行搜尋：

尋找到了，點進去查看：

這裡又看到是一個a變數，看看他的定義：

看到，這裡這個類又不可以點擊，說明這個類不在這個dex檔案中，去另外一個dex檔案中進行搜尋：

發現這個類的定義了，點進去進行查看：

原來是一個native的工具類，內部有很多native方法，包括了設定資訊的方法，加密解密url方法等。看看他載入的so是什麼：

原來是這三個so檔案，看到crypto和ssl，弄過加密的知道，這個是openssl加密的庫檔案，這裡猜想他在native層用了這個密碼編譯演算法了。先不管，我們用IDA開啟這個so檔案，因為我們知道libcrypto和libssl這兩個是庫檔案，所以直接開啟它自己的libsecret檔案吧，然後Shift+F12查看他的字串資訊頁面，在之前不是想看看那個加密欄位，這裡搜尋看看結果：

的確找到了，那個加密的欄位了，我們點擊進入查看：

然後點擊X鍵，查看調用地方，不過可惜的是，跳轉過去之後發現，那個彙編代碼不是一般的多。這裡先不去看了，回過頭來，看看那個加密url的函數：

點擊進去，然後按F5查看對應的C代碼：

這時候就要開始懷疑人生了，IDA卡死了。然後簡單看一下這個函數的彙編代碼，簡直蒙圈。太長了。如果靠靜態分析，我是沒這個耐心和能力了。動態調試？我覺得也夠嗆，搞不好還有反調試，各種跳轉。不知道調試到猴年馬月。

 

四、擷取加密內容

那麼到這裡，我大致分析這個直播app的請求協議有一個加密簽名的欄位s_sg，這個值是在native層中進行加密操作的，採用openssl進行加密，但是加密函數非常長，分析難度加大。但是不能就這樣放棄了。我們想要這個加密結果，用於我們自己構造參數之後擷取正確的簽名資訊值。那麼就需要轉化思維了。我們或許只要結果，加密過程對我們來說並不那麼重要。所以這裡的一個思路：自己寫一個程式調用它的so檔案中的這個加密函數。

我們做過NDK開發的都知道，預設情況native方法在so中的JNI_OnLoad函數自動註冊，但是native中的函數必須按照這種格式：Java_類名_方法名，類似這樣：

那麼我們就可以在自己的程式中，把app的那個Secret類拷貝過去，不過一定要注意包名一定不能變：

然後在代碼中直接調用native方法：

不過可惜的是，調用的結果，沒有加密欄位資訊。所以這裡我們會發現應該還缺少什麼設定。我們回過頭看看java層的代碼：

這裡有一個set方法，在之前分析已經發現了，他的調用地方：

這裡有一個SecretDataModel類，應該是從網上請求擷取到的資料，然後解析構造出這個類，看看這個類定義：

看到這裡，發現已經用了第三方的json解析包，註解直接解析欄位值。但是我們全域搜尋這個類的話，跟蹤太麻煩了，這裡就採用另外一種方式跟蹤代碼，那就是利用Xposed攔截這個類的構造方法，然後在內部列印堆棧資訊來查看方法的調用路徑，這種方法我在之前已經用過了。本文能夠更好的體現：

因為應用是多dex檔案，所以hook必須先hook他的Application類的attach方法拿到正確的類載入器，正確載入需要hook的類資訊，不然就報錯了。這個已經講了很多遍了。然後就是利用自動拋異常來列印方法的呼叫堆疊資訊，安裝運行，重啟生效看日誌：

這裡看到了，他用google的gson庫解析json資料的，看到了json資料是從下面這兩個方法中傳遞過來的，查看這個類的方法：

點進去進行查看：

為了看到返回的json資料，我們在攔截這個方法，把返回的json資料列印出來看看是啥：

運行模組，重啟生效，看日誌資訊：

看到這段json資料了，這時候，在返回去看看SecretDataModel那個調用set方法：

看到這四個參數值，第一個是Context不解釋了，第二個是serverTime欄位值，第三個是startCode欄位值，第四個是runCode欄位值。這三個欄位都是可以在上面列印的json中找到的，我們把json格式化看看：

有了這三個值和Context變數，直接調用Secret的native方法set進行設定，看看能否正確擷取到加密之後的欄位值：

運行demo程式看看日誌資訊：

看到了，設定成功了，而且擷取加密欄位也成功了。到這裡我們就成功的擷取到加密欄位s_sg值了。

 

五、擷取加密配置資訊

不過到這裡還沒有結束，因為我們發現那三個set值欄位從網路擷取，我們還需要知道是哪個url擷取到的，這裡從代碼跟蹤依然很困難，所以我們還需要利用hook來列印方法的堆棧資訊來追蹤代碼，通過上面列印的擷取json資料的堆棧資訊：

看到是這個類訪問擷取json資料的，進去看看：

而傳入的參數，在進行查看：

看到有一個getUrl方法，就是擷取訪問的url值，我們就可以這麼來進行hook操作，列印這個url訪問地址了：

運行模組，重啟生效，看日誌資訊：

下面列印了那個我們想要的json資料，上面有幾個url，我們在去Fiddler觀察這幾個url返回的資料，最後定位到這個是這個url返回的資料資訊：

 

六、梳理加密流程

到這裡我們就分析完了直播app的協議加密流程，下面來總結一下：

第一步：通過/user/account/token_v2介面擷取加密前的配置資訊

第二步：通過native方法把第一步擷取到的資訊進行設定(set方法)。

第三步：通過native方法將java層拼接參數的url值進行加密處理返回(encryUrl方法)

那麼我們可以這麼做，自己協議demo程式，在Java層拼接好參數，然後調用so的native方法，返回還有加密欄位的url，然後可以解析出這個欄位就是加密資訊了。我們就可以批量處理這種網路請求了。比如刷粉，觀看直播，點贊等操作。當然有的同學會認為這次操作其實不是真正意義上的破解密碼編譯演算法。的確不算，但是我們弄到我們想要的就好，過程其實沒那麼重要，而在這個操作過程中，我們又學習到了很多逆向技巧。

 

七、逆向技巧總結

第一、在用Jadx開啟apk卡死的時候，記得先解壓出dex檔案，在用Jadx開啟dex檔案即可。

第二、對於多dex的應用，使用Xposed進行hook的時候，需要先攔截Application類的attach方法擷取正確的類載入器。不然會報攔截失敗。

第三、當我們在使用Jadx進行全域搜尋內容，發現沒有搜尋結果的時候，可能需要從以下幾個方面考慮：

• 1、是否包含多個dex檔案，可以利用Jadx去開啟其他dex檔案進行搜尋。
• 2、是否存在動態載入外掛程式功能，全域搜尋DexClassLoader找到外掛程式載入位置，擷取外掛程式功能包，在用Jadx開啟外掛程式包進行搜尋。
• 3、是否存在so檔案中，可以利用IDA開啟so檔案，Shift+F12展示so中所有的字串資訊視圖，然後進行搜尋。
• 4、是否資訊來源於網路請求返回，比如一些字串資訊展示，有可能是伺服器返回的資訊。

第四、在我們用Jadx進行代碼跟蹤非常困難的時候，記得還可以利用Xposed攔截指定方法，列印堆棧資訊來跟蹤代碼，也是一種高效方法。

第五、當你在使用Jadx右鍵一個方法看看調用路徑，發現沒有結果的時候，那麼看看這個方法是否是該類實現的一個介面中的方法或者是抽象方法。去父類或者介面中的那個方法在右鍵看看調用路徑。

第六、在不關心過程，只關心結果的情境下，可以構造一個app來調用程式的so，擷取我們想要的結果，這種方式一定要記住，後面很多情境都會用到。可以用它來嗅探so中一些函數的功能。比如通過調用so中的一個方法，輸入規律資料，看輸出結果是否符合一定規律，通過規律來破解密碼編譯演算法。

 

八、總結

本文介紹的內容有點多，感謝該直播app開發人員提供這麼好的研究樣本，當然最後需要說一句就是：安全防護策略不夠，我們在本文可以看到我們利用調用他的so來擷取加密資訊，這個方法是可以用於很多app的，對於那些我們無需關心過程，只關心結果的內容，這種方法屢試不爽。那麼作為開發人員如何規避這種安全問題呢？很多人第一就想到了：在so的JNI_OnLoad方法中判斷簽名資訊是否正確，不正確就直接退出。這個的確可以防範。但是如果用我之前介紹的kstools工具原理，直接hook系統的PMS服務攔截擷取簽名資訊方法，返回正確的應用簽名資訊，這種防護策略就失效了。所以說：安全不息，逆向不止。兩者都在進步。

android黑科技系列——分析某直播App的協議加密原理以及調用加密方法進行協議參數構造