逆向某音短視訊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其實也可以被視為一種特殊的賬戶）。在大資料和風控漸漸普及的今天，藉助手機的環境，上傳一些真實行為日誌，很有必要，本篇就是很典型的案例。