|
|
|---|---|
|
|
|
|
|
|
|
|
24字节是AES后的最后一个字节
|
|
|
|
|
|
博主 关于tt的jwt刷新机制有研究吗？
|
|
|
|
|
|
+0x00：时间戳与某个常量异或。 v157是有效数据长度，v1053是总长度，v1182是pad的长度
最后于 2025-4-14 00:55
被wx_starfall编辑
，原因：
|
|
|
|
|
|
|
|
|
|
|
|
大佬能在说下嘛，没听太懂 |
|
|
这样吗！！我还写了个针对medusa解密的程序，能解好几个版本。根据我之前的定义感觉没啥问题啊。 |
|
|
|
|
|
那部分应该是个通用函数，在medusa上没啥问题，但是其他地方不一定，你把medusa的算法还原出来就能看到啦 |
|
|
medusa的pcode挺长的，忘了多少了，有1w2吧，最长的是bodyhash的，大概2w7,8的样子 |
|
|
您说太长是指xm大于248所以这个地方一定是0x01吗，没太听懂，我和楼主也差不多。解密加密也都正常 |
|
|
看明白了 |
|
|
太久没搞我也忘记了，大概是这样，aes的输入数据，是原始数据里取得一些值，好像始终都是提取0x1f字节，这时候，aes pad只有一字节，就是你看到的01 还有魔改aes结果的最后一字节。那么如果原始数据不足提取不了0x1f字节呢，这时候就不是01和最后一字节了，而是好几个字节。具体的实现我也忘了。。。 |
|
|
最近新出了个X-Persus，Medusa长度变短了，可能会出现你说的这个情况，原有的数据不足以提取出0x1F长度数据，还没验证过 
|
|
|
最后于 2025-10-22 17:11
被陈某人编辑
，原因： 删
|
|
|
|
