[原创]某短视频mssdk之get_token协议分析

抓包解密后协议数据：0a9d050a08216e6f747365742112065869616f6d691a044d4920362208216e6f74736574212a07416e64726f6964320231313a09313038302a3139323040c0074a1c525133412e3231313030312e3030312072656c656173652d6b65797350b0f187ee0c5a03656e5f6216416d65726963612f4c6f735f416e67656c65732c2d38685c708001788080968e1d80018080b8fa9b0388018080b8fa9b0390018080c092d9019a0108216e6f7473657421a20108216e6f7473657421aa011039643038313731303863316539373666b20108216e6f7473657421ba0108216e6f7473657421c2012c587365734548534b71726b716573596b33353354586f306941684a59436749722f43734e69396354546b593dc80184f187ee0cd2012433376239616562612d613234322d343738392d623137302d656339646163383531343966d80180c0aa95e516e20108216e6f7473657421e801fd887af001fd887afa0108216e6f747365742182020e3137322e31392e3135342e3136378a020e3137322e31392e3135342e323534920208216e6f74736574219a0208216e6f7473657421a002ec04a8026ab20208216e6f7473657421ba0208216e6f7473657421c202165b2231302e382e382e38222c22302e302e302e30225dc802fd887ad002fd887ad80202e20208216e6f7473657421e802b4f587ee0cf002e6d4d855fa025f2f646174612f6170702f7e7e4b365a664a48727a6f3439344f66666b654a583449513d3d2f636f6d2e7a68696c69616f6170702e6d75736963616c6c792d343035426138732d646c46387442305777336d4c32673d3d2f626173652e61706b80033c8803fd887a920308216e6f74736574219803fd887aa003fd887aaa0308216e6f7473657421b20308216e6f7473657421ba0308216e6f7473657421c003fd887a1219415665734e4274323148453769504e574673314f313673374e1a07616e64726f6964221d7630352e30302e30352d616c7068612e31302d6f762d616e64726f696428c09480503204313233333a0633332e322e354213373431323534333039393438303635353336354a103030303030303030303030303030303058fd887a7a08216e6f74736574218001fd887a反序列化：
解密后返回值：0a19417a78564c494949376a696e67725a6b56456b4e2d6e384762109003反序列化：

get_token协议上报的数据主要是一些设备信息和设备id，以及sdk信息。其中 内层字段 21明显是 android_id，外层字段8是业务设备id，device_register协议返回。内层字段26测试发现是 boot_id内层字段24卸载重装不变，并且换设备后不一样，需要进一步分析：使用frida hook 0xdea6c（base64_encode），打印出调用栈，定位到地址：发现数据的来源是 地址 0F7898 处函数调用的返回值，并且跟进分析，发现该函数只是将 java的数组转换成c++的数据。再往上就是 0xF7878 处的函数调用，跟进分析，发现该函数主要是调用java的方法。frida hook 输出方法名：
输出：原来获取的是 MediaDrmId。
1、抓包http 协议数据，反序列化：
第 6 个字段内容才是实际的加密数据hook memcpy函数，当长度一样时，打印出调用栈，得到关键加密函数：关键加密函数位于 0x11101c，传入序列化后的协议，返回加密后的数据：这是一个vm函数，opcode位于 0x161DF0，反汇编虚拟指令：上述主要两步：

1、0x270处调用  0xe1e60 压缩数据2、0x308处调用  0x1110e4 加密数据
第一步的压缩是zlib压缩，主要看数据的加密流程。

0x1110e4 函数中，在地址 0x1126e4 是一个aes加密操作，待加密的数据指针保存在 [SP,#0x88]中，是一个string对象从前面找到AES加密的数据来源：
这里通过string的构造函数，新建了一个待加密的string对象，并把地址保存到 [SP,#0x88]，数据来源是 [SP,#0xA0]， 数据长度是 [SP,#0xAC]
继续向前找 [SP,#0xA0] 处数据变动的地方：这里调用 0x113854 做数据加密，然后调用 0x1375ac ，在加密后的数据前面多加一个字节内容，最后对一个字节做运算后覆盖前面一个字节的计算方式：
first_byte = data[0]a = 3 | first_byteb = 3 & first_bytedata = ((a - b) & 0xff) + data
核心加密函数位于 0x113854：参数2决定是加密还是解密， w1 = 1 时，执行加密操作，关键基本块位于  loc_113934， 以8字节位单位执行加密操作。关键加密函数是  0x1140DC。这是一个自定义的 xx_tea算法，关键加密部分如下：还原算法：其中循环长度的计算方式：
还原出 0x113854 的加密算法：
通过frida调试发现， 0x113854 的加密数据，比压缩后的数据，前面多了不固定长度字节内容，可能是 1 -  4 个字节。需要继续跟踪其数据来源

1、第一个字节来源：2、后面 1 - 3 字节来源：
实际取的长度计算方式：


回复或点赞可查看完整内容

---
来源: 看雪论坛
原文链接: https://bbs.kanxue.com/thread-287008.htm

占个头排，希望可以给个精华

大佬，牛逼

感谢大佬分享

感谢大佬分享

report有看过吗

感谢大佬

mb_uwpxtoew


report有看过吗

report协议太长了没法图片粘贴出来，主要就是加了很多设备和系统信息、网络、代理等信息

大佬大佬！

大佬牛，学习了~

太强了