今天来分析一下某短视频系列的 sig3 加密参数,主要目的是探索学习app接口的加解密机制。仅供学习,禁止用作其他用途。未经允许禁止任何形式的转载,保留追究法律责任的权利。
逻辑分析
app样本:5Zac55Wq5YWN6LS555+t5Ymn
正常出结果,这块就没什么好讲的了,网上有很多份,唯一要注意的就是要先初始化一下

出结果后,固定入参 ”coder7777“,结果每次都不一样,猜测是有时间戳或者随机数,我们来测试一下,首先固定时间戳,此时发现入参固定,时间戳固定,结果一致,结果为42530000d2f6651b0a0a09085baf1cd100b40776171b1503,更改参数和时间戳也看不出什么了,咱们接着往下走。

so去花
跟着大佬学习肯定不会错,我这里也是看着龙哥的文章去的花,具体过程就不分析了,文章里面或者其他资料都很多,跟着照做就可以实现了.
先trace一份代码出来,首先 根据结果”42530000d2f6651b0a0a09085baf1cd100b40776171b1503“查找,看看是哪里生成的,咱们在trace里面搜索一下 0x1b(不要搜索0x03这些结果比较多)。搜索发现这里会比较像:

unidbg在这里断一下,看看x21

看样子结果是我们想要的,然后打开ida看下流程,快捷键”x“和打断点配合,最终确认如下:

上面就是v460 生成的地方,我们在这个地方打上断点:

我们python实现一下异或操作 注意共执行23轮,然后第二十四位不变:

也没问题,结果正是 42530000d2f6651b0a0a09085baf1cd100b40776171b1503
2.现在我们就要分析 41510100d5f0601f0100000054a111dd13a61666000d0003 的来源了,这里我们先测试下:
只修改明文:
13-16位和最后一位变化
只修改时间戳:
5-8处字节发生变化 17-19和最后一个字节发生变化。
两者均修改
5-8处字节发生变化,13~20处字节发生变化,和最后一个字节变化
crc32算法
由以上可知,13-16位和明文”coder7777“有关,13-16位是 dd11a154, 咱们trace里面搜索一下:
在0x1620处,我们在这里打个断点:

mx0是密文,mx1=0x30是长度,根据网上资料可以,这里用的是crc32算法,我们来测试一下:

得到结果 ”dd11a154’ 且没有魔改
aes-cbc加密
这里再看下“b7332938d71fbd84260aabaf3ecd0e6e164c729106057925b51710d697f5e06ced13be5d336bf29ad77fbad8cb814cad”是怎么来的。还是根据网上资料,初步认为是aes-cbc,咱们只需要验证是不是即可。
上文的b73329xxxxx所在的位置是 0x404e44c0,咱们这里trace追踪一下

这里看到调用的地方是在ilbc里面,0x1d62c是结束调用的地方,咱们在 0x1d62c 前面的位置打个断点

可以看到是在 0x404d31b0 这个位置,我们在trace一下:

可以看到是在0x25b30,ida分析一下,这里大概就是aes算法的地方了,再具体的就没必要去分析了,网上的资料很多,例如如何知道是aes,且是cbc模式,这里就不细说了。
咱们hook一下入参:

这里一直入参为 33c4d4f0f3316a554af23888c78af4b44050d6c952572c743e047af26c1d8c3e
结果为 b7332938d71fbd84260aabaf3ecd0e6e164c729106057925b51710d697f5e06ced13be5d336bf29ad77fbad8cb814cad
加密方式为 aes-cbc.
咱们直接上dfa:
运行10次以上,得到一个原文和多个错误密文,然后使用phoenixAES算出第10轮秘钥

算出后再用 Stark 算出主密钥

这里算出密钥后,验证一下:

结果正确,说明咱们aes密钥找对了
hmac-sha256
最后一步了,找出 33c4d4f0f3316a554af23888c78af4b44050d6c952572c743e047af26c1d8c3e 生成的位置,由hook入参可知,33c4xxx存在 0x404d8340,咱们trace一下

是在0x1ce50,此时已经生成结果,对上一个函数进行hook
[培训]Windows内核深度攻防:从Hook技术到Rootkit实战!
最后于 2025-10-10 16:43
被coder777编辑
,原因: 修改一下格式