逆向某音短视频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

免责声明：本文档仅供学习与参考，请勿用于非法用途！不然一切后果自负。