逆向某音短視頻App之設備激活

逆向某音短視頻App之設備激活

背景

某音的爬取，除了逆向協議之外，還有個關鍵點是設備註冊。協議的逆向已經有不少前輩分享，也比較簡單，拋開不談。這篇文章主要講講某音的設備註冊和激活。

設備註冊

查閱資料，設備ID註冊主要是有device_id和install_id（iid）。註冊的URL：[http://log.******.com/service/2/device_register/](http://log.******.com/service/2/device_register/)。
先根據device_id和install_id來作搜索。某音沒有作加固，用Jadx直接打開，同時搜索device_id和install_id能夠發現主要代碼區段在com.**.android.common.applog.AppLog包中





確實很可疑，有不少設備ID和設備相關的參數和方法，可是沒有設備註冊相關的代碼，先放着不談。
接着直接搜索device_register吧，出來的結果並很少，發現Jadx沒法正常解析，雖然看指令也能看出大概，這裏就是設備註冊的具體邏輯了。

使用JEB打開後是這個效果。

整體和網上的資料一致，收集各類設備信息，並壓縮和加密，看到這其實發現設備ID的獲取並不困難。

這裏推薦這個項目device_register，可以直接生成device_id，其中加密函數調用採用了unidbg。

設備激活

不過上述項目的做者在README中也提到，經過該方式獲取到的device_id和iid去訪問接口，會獲得空的響應。原做者猜想是有相關的激活請求，測試下來確實如此。因此本文的重點是分享一種欺騙打點日誌，實現設備ID重激活的思路。
回到以前最開始看到的AppLog類，裏邊有不少記錄用戶行爲並上傳打點日誌的狀況，而這些日誌裏邊會包含device_id和iid。因而猜想到會不會是這些打點日誌影響了device_id的有效性。若是咱們把生成的device_id注入到真實的手機App中，那麼打開App會按咱們注入的device_id來打點，是否是就能洗白了？
查閱資料發現，若是將AppLog類中還有一個控制打點日誌body是否須要加密的方法，找到名字對應是getLogEncryptSwitch，先將其改成false。以後發現抓包確實都顯示明文了。



能夠發現body中header字段帶上了設備信息，追溯下來其實就是mheader這個字段，因此首先要把device_id和iid注入到這個mheader中。
注入完成以後抓包發現，URL中的device_id和iid尚未變，不過這裏邊的參數修改也比較容易，找到統一加請求參數的類com.**.android.d.e將device_id和iid扔進去便可。
最後看一下device_id的存儲位置。回到AppLog的getServerDeviceId和getInstallId方法，能夠看到他們其實最終是從SharedPreferences取出的數據。因此除了要注入獲取device_id和iid的相關方法，刪除SharedPreferences（/data/data/<package_name>/shared_prefs）來清除原有的device_id和iid會更加保險。
作完上述的全部操做後，從新打開App抓包能夠發現，全部的打點日誌都用到了咱們新注入的device_id，而且device_register接口返回了新install_id，經測試能夠在全部接口上使用。

總結

除了通信協議逆向，設備ID的生成和風控規避尤其重要。以前在文章中也提到，不推薦在高日活App中純使用協議來作抓取，特別是必需要登陸的狀況下（設備ID其實也能夠被視爲一種特殊的帳戶）。在大數據和風控漸漸普及的今天，藉助手機的環境，上傳一些真實行爲日誌，頗有必要，本篇就是很典型的案例。

更多短視頻數據實時採集接口，請查看文檔： TiToData

免責聲明：本文檔僅供學習與參考，請勿用於非法用途！不然一切後果自負。