一、逆向分析

在之前的兩篇文章中，我們已經介紹了短視訊四小龍的某音，某山，某拍的資料請求加密協議，不瞭解的同學可以點選檢視：；那麼今天繼續最後一個短視訊那就是某手，不多說了，還是老規矩直接抓包找入口：

看到請求引數分為兩部分，一個是在url後面拼接的引數，一部分在body中的。不過這個沒多大影響，分析引數資訊之後發現在body欄位中有一個sig，這個就是簽名信息了。所以需要找到這個值的獲取方法即可。這裡我們使用Jadx開啟某手應用，不過這裡可能要注意，某手的包比較大，而且分了四個dex檔案，所以開啟可能點卡，可以先解壓出四個dex檔案，依次開啟即可。在classes.dex中全域性搜尋可以看到：

這裡看到他內部網路請求使用了retrofit框架，這個框架其實核心原理還是okhttp，只是用註解封裝了。那麼到這裡就發現其實註解功能在逆向中分析起來是比較費勁的。所以我們就換個思路，直接全域性搜尋那個簽名欄位："sig"，可惜的是在classes.dex中並沒有搜到，在去第二個dex中搜：

看到了，搜到了直接點選進入即可：

這裡看到呼叫了一個方法來獲取sig欄位資訊，直接檢視這個類：

這個是介面型別，那麼檢視他的實現類是哪個？這個變數在構造方法中進行賦值的，看看型別：

到這裡遇到問題了，應該是拆分了dex，所以搜尋這個類的全域性呼叫會沒有結果，這樣就跟蹤有點麻煩了，不過這裡依然採用hook大法，直接hook這個類的構造方法，列印這個引數的類名稱即可：

執行程式碼，看日誌資訊：

找到這個類了是：com.yxcorp.gifshow.retrofit.c，全域性搜這個類，這時候要注意，如果在一個dex中找不到，就去下一個dex中搜索即可：

這個類果然是獲取請求引數資訊的，有一些公告引數資訊，和基礎資訊，繼續往下看：

看到了獲取sig欄位的方法方實現，其實很簡單，直接將傳入的兩個map引數結構的key和value進行拼接，然後進行排序，最後呼叫CPU.getClock方法獲取加密資訊即可。繼續看看這個加密方法：

果然還是把加密功能放到了native中做的，引數比較好理解：全域性的context，排序好的引數位元組陣列，系統版本號，那麼接下來用IDA簡單分析他的native程式碼，直接開啟libcore.so檔案即可：

不過可惜的是，會發現沒找到這個native函式，但是找到和這個函式可能有關係的，其實這個是他做了一次混淆，後面會出文章單獨介紹這種混淆技術。點進去看看：

直接點選X鍵，檢視這個函式的呼叫地方：

往上檢視函式名：

這時候發現了，看到了這個函數了，我們點選F5檢視他的大致C程式碼：

遇到這個警告，這個也是他進行了混淆，不過沒關係，可以右鍵create function即可：

當然這裡可以直接使用快捷鍵P即可，然後就可以順利檢視他的C程式碼了：

不過，這裡不做太多介紹分析了，因為和之前文章一樣，我們的目的直接呼叫這個so來獲取加密結果即可。不過靜態分析so還是要有的，主要大致看一下他有沒有什麼防護策略，不過這裡大致看了，應該沒有。

二、獲取請求資料

直接去demo工程繼續呼叫，依然在demo工程中新建一個CPU類：

記得報名和型別都必須保持一致即可，然後就開始構造引數呼叫這個方法了，這裡首先來分析那個傳入的兩個map結構引數資訊，這裡依然還是用hook開啟，來列印日誌分析：

執行，看看列印的結果日誌：

再去比對Fiddler中抓包資訊的請求引數：

可以很容易發現，第一個引數map是公眾引數也就是在url後面的，第二個是基礎引數在body中的。那麼就簡單了，直接構造這兩個map結構即可：

這裡為了方便，依然將引數寫死，後續會進行優化動態獲取即可。然後直接呼叫加密方法，進行網路請求：

執行demo，看看加密資訊以及是否能正確請求到資料：

驚奇的發現，盡然成功獲取到資料了，說明他native中的加密函式真的沒有什麼防護策略，這個和之前的某音某拍差距了，我們把這json資料拷貝出來格式化看看結果：

後面我們只需要簡單的解析這個json資料即可。

三、繼續填坑

可惜的是，到這裡算是結束了嗎？原以為結束了，因為這裡測試我一直用的都是4.4的系統，結果無意中用了5.1的系統測試發現，盡然拿不到資料，原因就是獲取簽名信息失敗了，也就是那個native方法getClock獲取失敗，那麼就噁心了，還得重新回頭去看這個函式：

這裡我們可以直接靜態分析so檔案，繼續檢視getClock函式，到這裡會發現5.1的手機的cpu_cnt值是null，這個值在哪裡賦值的呢？繼續往下檢視即可，看到了是個類似於檢查cpu屬性的函式checkCpuProperty：

而我們知道5.0系統之後cpu架構改變很大的，繼續檢視這個函式功能：

看到核心點了，這裡用a4變數做判斷了，看看這個a4是啥：

是這個函式的最後一個值傳遞進來的。繼續往回看，這個引數是怎麼傳進來的：

這裡為了演示方便，就把getClock的沒用程式碼刪了，主要看這個引數是怎麼傳遞進來的，發現是getClock的最後一個引數，那麼也就是Java層呼叫這個方法傳遞的最後一個引數，繼續回去看這個方法的呼叫：

這裡看到，最後一個引數的確是系統版本，那麼就真相大白了：為何4.4的系統可以拿到資料，而5.1的裝置拿不到，因為在底層so中對系統做了判斷，大致應該是判斷cpu資訊啥的。那麼為了能夠讓我們始終都能拿到資料，可以非常簡單的操作，就是這裡的方法最後一個引數直接寫死就是4.4對應的api值19，這樣永遠都可以拿到資料了，那麼有同學會覺得奇怪了，這麼做是不是有點投機取巧？會影響後面的資料讀取嗎？其實從這裡看到應該是應用當初做的一套版本相容，而我們知道現在4.4系統的佔有率還是很高的，應用短期內不可能把這個相容去掉，而只要相容不去掉，我們客戶端就模擬4.4的系統從而順利的拿到資料了，何樂而不為呢？

嚴重宣告

本文的意圖只有一個就是通過分析app學習更多的逆向技術，如果有人利用本文知識和技術進行非法操作進行牟利，帶來的任何法律責任都將由操作者本人承擔，和本文作者無任何關係，最終還是希望大家能夠秉著學習的心態閱讀此文。鑑於安全問題，樣本和原始碼都去編碼美麗小密圈自取！

四、總結

大家看完本文之後，會發現其實某手對協議並沒有做太強的加密防護策略，我們很容易就獲取到了，只是因為他進行了拆包，所以在跟蹤程式碼的時候比較棘手，不過幸好我們有無敵的hook大法，無需痛苦的跟蹤程式碼。那麼到這裡我們就成功的分析完了短視訊四小龍：某音，某山，某拍，某手這四家app的資料請求加密協議了，後面就要開始我們的真正專案了，那麼到底是什麼專案呢？盡情期待。

《Android應用安全防護和逆向分析》

點選立即購買：京東  天貓  

更多內容：點選這裡

關注微信公眾號，最新技術乾貨實時推送