文章总结： 本文详细分析了阿里V2滑动验证码算法的最后一部分，重点介绍了feilin文件和sg文件中动态key的生成机制，以及CaptchaVerifyParam参数中deviceToken和data的加密过程。作者通过逆向工程揭示了验证码如何利用环境信息、轨迹数据和多层加密算法来确保安全性，包括AES加密、MD5加密、VMP运算和压缩算法等。文章还提供了实用的逆向分析技巧，如使用hook功能定位加密位置，以及如何从混淆代码中提取关键信息。
综合评分： 85
文章分类： 逆向分析,WEB安全,实战经验,漏洞分析,安全工具
阿里V2滑动验证码算法分析-下篇
原创
無色逆向
無色逆向
2025年12月9日 08:26
北京
声明
本文章中所有内容仅供学习交流使用，不用于其他任何目的，严禁用于商业用途和非法用途，否则由此产生的一切后果均与作者无关！若有侵权，请联系公众号【無色逆向】删除。
前言
前文再续，书接上回
上篇文章中将四次请求的前三次分析完了
接下来将分析最后一次请求以及动态key的生成逻辑
feilin文件动态key
上篇说到 Data 参数是由收集的环境对象加密而来
环境对象中有个参数是动态的由 feilin 文件中生成
一般用以下两种方法获取
1、写ast代码提取
2、写正则补环境暴露出来
我自己用的是第二种方式
但是呢，我也把算法还原出来了
其实就是取解密后的 DeviceConfig 里的 SessionId
和两个参数进行两次异或操作后转base64
而与之异或的参数也是动态的
在每个feilin文件中的值不一样
都是从大数组解密取出来的
奇怪的是我把它异或的两个参数也写死竟然也还能校验成功
但是成功率感觉比动态获取的会下降一些，难绷，不知道校验了个啥
简单说下我这动态获取的逻辑
需要找到这个t7，不同版本不一样，搜ENDPOINTS匹配到也行
从t7里可以将动态key暴露出来
sg文件动态key
sg文件生成的 key 在第四次请求的参数 CaptchaVerifyParam 中会用到
在sg3.20版本后我是以vold 0作为关键点来暴露key
不一定要用我的方法，可能还要更容易的方法自己去找
不同大版本匹配的方法不同
这个比feilin文件key还要难匹配来搞自动获取
有大毅力者可以去手动收集每个版本对应的key
一般就是百来个，收集完应该能用个把月等再更新
CaptchaVerifyParam
CaptchaVerifyParam 对象中有两个加密参数需要分析
deviceToken 和 data
deviceToken比较简单，也用了aes加密
那么和上篇一样在 encrypt 处断点看信息
打好断点后滑动验证码
跳几次看到一大串环境加密内容如下图格式就对了
然后往前看堆栈
很明显又是一个大环境对象进行拼接加密和 Data 的加密类似
注意里面也用了feilin的key
加密完成后继续往下走
这里会组一个数组，包含刚才加密的环境
还会看到著名的梗来源
再之后将数组拼接成字符串后用md5再加密一遍
然后再组数组再拼接一次
最后base64编码一下就是最终的 deviceToken 了
data 主要是对轨迹信息进行加密
那么需要先找到对轨迹收集的位置
可以对鼠标事件加个监听
当 js 文件有混淆且你并想花时间解混淆无法用关键字搜索时
那就需要灵活运用 hook 功能了
可以对常用一些方法进行监听
比如对象序列化 JSON.stringify
编码转换 TextEncoder、btoa、atob等
输出堆栈信息来定位加密的可能位置
轨迹的加密是在sg文件中处理的
可以看到现在是正常的轨迹数据带x、y坐标和时间轴
又经过一个控制流处理转换后
再用TextEncoder转换
这里发现除了轨迹外还多了两个参数
前面一个是对轨迹走一个vmp运算
后面一个是用 CertifyId 和 sg 的动态 key 走一个 vmp 运算
转换成数组后再进行压缩算法
压缩完后和一个固定密钥再走一个vmp运算
你要想知道vmp运算是咋样的，就是这样的，大量运算出栈入栈
得到最终的data
结果验证
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：無色逆向 無色逆向《阿里V2滑动验证码算法分析-下篇》