逆向某音短視頻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
免責宣告：本檔案僅供學習與參考，請勿用于非法用途！否則一切后果自負，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/241820.html
標籤：大數據