一、前言

最近萌發了一個做app的念頭，大致什麼樣的app先暫時不說，後面會詳細介紹這個app的開發流程和架構，不過先要解決一些技術前提問題，技術問題就是需要分析解密當前短視訊四小龍：某音，某山，某拍，某手這四家短視訊的資料請求加密協議，只有破解了加密協議，才能自定義資料請求拉回資料。不多說了，本文先來第一站搞定某音和某山這兩個資料請求的加密協議，為什麼說是這兩個呢？因為我們在後面分析會發現這兩個app其實用的是一套加密協議，畢竟這兩個app都是某頭條內部孵化的專案。所以只要搞定一個即可。我們決定搞定某音吧，畢竟我比較看好和喜愛看某音。

二、逆向分析

不多說了，趕緊來分析吧，不過本文不再利用粗暴的靜態方式去破解了，應廣大同學要求，就介紹IDA動態除錯so來進行破解，這樣也能給大家帶來IDA的使用技巧。畢竟我寫文章技術都是為了你們。這種分析請求資料的突破口一般都是抓包，這不用多說了。不過都是用了https請求，所以需要手動在裝置中安裝Fiddler證書，才能抓到正確的資料資訊。

開啟某音之後，看到資料刷得很快，發現一個feed的介面是返回的首頁的資料，在分析它的請求引數中有三個欄位是minCursor,maxCursor,count。其實這三個欄位就是後面進行資料分頁請求的關鍵，到後面再詳細說。這裡看到還沒有什麼問題，往下看更多請求引數，會發現兩個欄位。

這時候會發現其它引數都和本地裝置有關或者直接寫死的，唯獨這兩個引數資訊是始終變化的。所以猜想這兩個欄位是用於請求協議資料加密和服務端進行校驗的。那麼如果我們想單獨構造資訊去請求，這兩個欄位的資訊一定要正確，不然請求不到正確的資料的。好了，這裡簡單了，使用Jadx開啟某音app即可，直接全域性搜尋欄位的資訊as=。

看到這裡是構造了as和cp兩個欄位的值，直接點選進入即可。

這裡大致的邏輯也比較簡單，利用UserInfo.getUserInfo函式獲取字串，然後對半開給as和cp兩個欄位，右移操作就是除以2的意思。這裡不分析程式碼來看看引數怎麼來的，直接用Xposed hook這個函式列印引數看結果，粗暴快捷，以後其實這都是快速解決問題的一種方式，hook大法是最無敵的。

先來看一下這個加密方法的引數資訊，看到是native的，也就是說加密操作是在so中做的，後面需要除錯的也是這個so了。也不管了，hook這個方法然後列印資訊看引數構造。

直接執行模組，列印日誌看資訊。

看到三個引數列印的值，發現大致三個引數的意義是：當前時間戳，請求url，請求引數的陣列資訊。好了，我們現在可以新建一個Android工程，然後構造這三個引數資訊，呼叫它的so函式。為了找到這個so名稱，全域性搜尋System.loadLibrary即可。

這樣就找到了這個so名稱了，到libs目錄下把這個so拷貝出來到我們自己構建的demo工程中，這裡先不著急除錯去分析native的加密函式功能，還是老規矩，拿來主義，直接上層構造一個一樣的包名的native函式，呼叫它的so獲取結果即可。

然後就開始構造引數資訊了，這裡為了簡單，先把那些公共的引數資訊寫死，比如裝置的sid，aid，版本號等資訊。

這裡我們利用公眾引數資訊，構造請求欄位陣列資訊，然後還有單獨的幾個欄位值不能參與操作，可以通過之前的列印日誌分析出來。當然時間戳也是伺服器格式，和本地是少三位的，直接除以1000即可。下面為了簡單直接把公眾引數寫死，當然後續優化就是把這些引數值進行動態獲取填充即可。

構造好引數之後，然後就開始呼叫native函式，然後獲取返回結果即可。

到這裡，我們構造的工作就完成了，下面就開始直接執行吧，不過可惜的是，沒有這麼順利，直接執行閃退了。

這裡應該進行載入so出現問題了，那麼回過頭看看是不是有些環境沒初始化，UserInfo類中是不是還有一些初始化方法沒呼叫。

這裡看到的確有兩個方法有點可疑，全域性檢視這兩個方法的呼叫地方。

看到全域性中就一個地方呼叫了setAppId方法，而且值就是寫死的為2，另一個方法initUser就有點麻煩了，不過還是萬能的hook大法，直接hook這個方法列印引數資訊即可。

執行模組，檢視列印的日誌資訊。

看到了，引數資訊一致都是這個字串資訊，直接拷貝出來賦值呼叫即可。

三、IDA除錯SO

再次執行，發現還是報錯，而且詭異的是日誌沒列印，也就說setAppId和initUser函式沒有呼叫就退出了，那麼就會想到是不是so中的JNI_OnLoad函式中做了一些判斷邏輯呢？用IDA開啟這個so檔案找到JNI_OnLoad函式，發現果然內部有很多判斷，然後直接呼叫exit函式退出了。其實這裡直接靜態分析有一個快捷的方法，但是為了給大家介紹動態除錯so技巧，就多走點彎路吧，後面再說一下粗暴簡單的技巧。除錯進入JNI_OnLoad函式處，下個斷點。

因為我們之前靜態分析了這個函式內部有很多個exit函式，為了好定位是哪個地方exit了，所以在每個exit函式之前下個斷點，來判定退出邏輯，這裡下斷點有技巧，因為是if語句，所以在arm指令中肯定就是CMP指令之後的BEQ跳轉，所以在每個CMP指令下個斷點即可，這裡發現了9個地方，所以下的斷點也很多，慢慢分析。到了第三處判斷髮現R3暫存器的值不是0了，而是1，所以為了繼續能夠往下走，就修改R3暫存器的值為0，儲存即可。就繼續往下走，到下一個斷點，這裡有問題了，我們如果直接F9到第四處CMP的話，發現直接退出除錯了，說明在3和4處判斷中間有問題了，最終發現是這個跳轉指令出現的問題，這裡需要多次單步除錯F7鍵，定位出現問題的地方。進入這個跳轉地址，然後發現內部還有BL指令，繼續深入檢視。

看到了，這裡發現問題的原因了，有一個GlobalContext類，這個類應該是Java層的，native層應該用反射機制獲取全域性的Context變數，我們直接去Jadx中搜索這個類。

那麼問題就清楚了，因為我們的demo工程中壓根沒這個類，所以native中獲取全域性context變數就失敗了，所以就exit失敗退出了，解決辦法也簡單，直接在demo工程中構造這個類，然後在Application中初始化context即可。

構造的時候一定要注意包名一致，然後在demo中的Application類進行設定context即可。

然後再次執行專案，可惜還是不行，所以還得進行除錯JNI_OnLoad函數了，繼續往下走，發現重要資訊了。

這裡有一個類似於MD5的值，繼續往下走。

看到R0暫存器中的值，發現是demo應用的簽名信息，繼續往下走BLX看看。

這裡看到大致清楚了，是獲取應用簽名信息，也就是簽名校驗了。

在這一處判斷exit函式中，應該是通過反射獲取Java層的context值，然後獲取應用的簽名信息和已經儲存的原始某音簽名信息做對比，如果不對就退出了。那麼過簽名校驗也很方便，直接利用我之前的kstools原理，把hook程式碼拷貝到工程中，攔截獲取簽名信息，然後返回正確的簽名信息即可。

hook程式碼一定要在Application的第一行程式碼呼叫，不然沒有效果的。這樣操作完成之後，其實已經出資料了，不過為了能夠進入加密函式進行除錯分析具體的加密演算法，我們繼續除錯JNI_OnLoad函式。

繼續往下走，會發現在第五個exit判斷之後，有一個函數出問題了，就是這個BL，進入內部檢視。

哈哈，發現了這個字串資訊，弄過除錯的同學大致都猜到了，這個是反除錯操作，繼續往下走。

這裡可以百分百確定是讀取status檔案中的TracerPid欄位值來進行反除錯檢測了，給下面的兩個CMP指令下個斷點。

發現R3暫存器中的確不是0，所以為了過反除錯，直接修改R3暫存器值為0即可。

這樣就過了反除錯檢測了，單步往下走到下一個exit的判斷斷點，最終還有一個地方需要處理就是第七個CMP指令。

直接修改R3暫存器中的值為0即可，就這樣我們成功的過了JNI_OnLoad中的所有判斷exit的地方了。

然後給加密函式getUserInfo下個斷點。

直接點選進入即可。

四、加密結果輸出

成功到達了加密函式斷點處，這裡已經沒有任何判斷邏輯了，就是一個單純的加密函式，不過這裡不進行除錯分析了，感興趣的同學可以自己操作。

我們成功獲取了as和cp值，然後構造到請求url中，也成功拿到了返回資料。這裡多了一步解析json資料而已，原始的json資料是這樣的。

之所以要解析，也是為了後面的專案準備的，到時候我會公開專案的開發程序。不管怎麼樣，到這裡我們就成功獲取某音的加密資訊了。主要通過動態除錯JNI_OnLoad函式來解決so呼叫閃退問題，在文章開頭的時候說到了，其實本文可以直接用簡單粗暴的方式解決，全域性搜尋字串資訊，這裡包括Jadx中查詢和IDA中檢視，因為字串資訊能給我們帶來的資訊非常多，有時候靠猜一下就可以定位到破解口了。

憑著這些關鍵字串資訊就能斷定so中做了哪些操作。記住這些敏感的字串資訊，對日後的逆向非常關鍵。

五、某山小視訊加密分析

上面解決了某音的加密問題，下面再來看一下某山小視訊的加密資訊，突破口依然是使用Fiddler進行抓包檢視資料。

通過抓包會發現和某音的資料結構欄位幾乎異曲同工，果然是自家兄弟，繼續檢視加密欄位。

不想多說了，既然加密的欄位都是一樣的，那麼我們直接不多說用Jadx開啟某山小視訊，看看有沒有那個native類UserInfo資訊。

哈哈，看來不用多一次分析了，完全一樣，那麼直接用同一個so，同一個加密即可，在demo工程中執行檢視日誌。

初始化都是一樣的，直接執行。

看到了，資料也回來了，看看原始json資料。