从x-tt-trace-id来看逆向苦力

宇宙大厂在web和安卓的反扒上是当之无愧的宇宙级，更新速度更是宇宙第一

再接触在它pc版时候我从来没想过签名还能这么玩！安卓这块先是引入cronet解决可以抓包的问题，随后签名放入了so，又调整了混淆！一个字：NB！

以下内容来自对安卓19.2.0的抓包，只谈x-tt-trace-id生成的思路流水账，它只是整个伪造请求的一小部分

背景

最近需要用到大厂的搜索，要求获取用户完整信息（包括地区、生日、学校等）

在重新搞定了web签名和滑动条后发现self接口的bug修复了，本来是可以直接请求到这几个数据的😂

随后去了app，但发现上述的几个数据不是特别稳定，设备注册后刚开始大概率有，但一段时候后大概率还是没有🐶

开始以为注册后没有做激活和applog，但在进行了尝试后发现并不是，那么就只能干苦力活了：比对伪造的请求和抓包请求

比对

比对之后添加和修改了一批参数，但发现情况并没有得到明显的好转，最后聚焦到x-tt-trace-id上，其格式如下

00-32位hex-32位hex的前16位-01

分成了4段，最重要的32位hex咋一看很像是一个md5，刚开始我们就是随机生成了一个32位hex

在抓包过程中逐渐发现它竟然是有规律的递增值，而且中间有几位不变

将x-tt-trace-id里的32位hex进行拆分，会得到一个很有意思的结果

(0-7自增)+(8-22固定值)+(23-27看着像随机值)+(28-31固定值)

那么(0-7自增)大概率和时间戳有关系了

时间戳

这个很简单，把这8位hex转为十进制，和可能存在时间戳的地方做差值

随后你就会发现使用activity_now_client时会得到一个稳定的值

所以这前8位就是用activity_now_client减去一个你得到的固定值了

固定值

接下来是15位固定值，hex搜了一圈没有，转成10进制去搜了一圈还是没有

那么它是怎么来的呢，再经过一段时间漫无目的的静态分析和插桩后，我决定从设备注册开始

随后发现设备注册时后14位居然不一样，多注册几次更是发现每次都不一样，这14位在注册时是随机数

在设备注册完成之后这14位又固定了，并且和注册前的一摸一样！多试几次依然这样

那么可怀疑的地方就小了很多，比如openudid，又是一通乱找加回忆：

openudid之类的在请求前就已经固定了。只能是注册返回的参数了，而iid每次都会变，只有did是每次注册都不变的

将did转为16进制果然完美符合后13位，那么8和9位是干什么的呢？

大胆猜测：8位是宇宙大厂对时间戳的占位符，9位是did的占位符，或者这两个都是某一项的占位符，不过这些还太过久远，把这两位当成不会变的固定值即可

最后四位

如果熟悉套路，可以把它转成16进制，瞬间你就会发现这是啥

总结

就说到这啦，关键还是思路，有些值确实找不到从哪来的，也不是set-cookie，不妨观察下规律，如果不影响结果直接上随机数就好

宇宙大厂NB！（破音！更新速度唯我独尊！（是年终有kpi吗，明年打算怎么优化呢😊直接干掉某些导出吗