文章总结： 文章详细分析了阿里V2滑动验证码的算法实现，包括请求流程、参数加密机制和验证过程。通过逆向分析发现，验证码系统使用多重AES加密和HMAC签名保护数据传输，其中Signature通过HMAC+Base64编码生成，Data参数采用多重AES加密，密钥来自DeviceConfig解密后的信息。文章提供了调试技巧和关键代码位置，为绕过验证码提供了技术路径。
综合评分： 90
文章分类： 逆向分析,漏洞分析,WEB安全,渗透测试,代码审计
阿里V2滑动验证码算法分析-上篇
原创
無色逆向
無色逆向
2025年12月5日 08:06
北京
声明
本文章中所有内容仅供学习交流使用，不用于其他任何目的，严禁用于商业用途和非法用途，否则由此产生的一切后果均与作者无关！若有侵权，请联系公众号【無色逆向】删除。
前言
前不久刚研究过阿里的无感验证 acw_sc__v2 的算法
在ip质量较好的情况下可以直接通过校验
但也有可能触发二次校验
也就是滑动验证码
目标网站
aHR0cHM6Ly9odW5hbi56Y3lnb3YuY24vbHViYW4vYW5ub3VuY2VtZW50L2xpc3Q=
抓包分析
快速点几下翻页即可触发验证
第一次请求
4e77***.captcha-pro-open.aliyuncs.com
载荷中的参数大部分都是请求 queryPage 接口触发验证的响应中获取的
可以从 requestInfo 中提取出来，基本都是固定参数
DeviceData 是设备信息的加密数据
可以搜索关键词定位到加密位置
是个标准的 aes 加密，也可以固定写死
SignatureNonce 是个随机生成的类似uuid
Signature 是数据加密来的后文会分析
响应内容
重点在 DeviceConfig
第二次和第三次请求接口地址一样
device.captcha-open.aliyuncs.com
一次是Log2一次是Log3
Data参数包含设备信息等进行加密
第四次请求和第一次接口一样
CaptchaVerifyParam 参数包含设备信息和轨迹等进行加密
响应内容中VerifyCode为 T001即表示最终验证通过
通过之后将 CertifyId 带入请求中即可获取目标数据
u_asig 即 CertifyId
u_atoken 是 requestInfo 中的 token 值
SignatureNonce
下个xhr断点到触发验证
断点位置 p7 参数已全部生成
向上跟栈，进入 AliyunCaptcha.js文件中
跟的步数比较多，耐心点边看边跟着
定位到加密位置，很明显暴露出其加密方法
再打上断点跟到这来
这里要说明一下，这个js也是动态的，有个后缀 ?t=
它的值定义方法还是在触发验证的响应中可以找到
时间计算，一小时内的值是不变的
所以打上断点后只要在当前一小时内或者不重开浏览器还是可以一直调试的
否则历史断点就会没了
想一劳永逸就替换 js 文件吧
SignatureNonce 指向了 de 方法
就是随机生成的，算法直接抠下来就行
Signature
再看 Signature 调用了 Sr 方法
两个参数，一个固定字符串作为加密密钥和一个已知所有参数的对象
进入 Sr，代码混淆+嵌套控制流
分析下来，实际算法就是个 hmac+base64 编码
将参数和一些字符串拼接进行 url 编码，再进行 hmac 加密
加密后的结果再经过 base64 编码后就是 Signature 了
这样第一次请求完事了
接着是第二、三次请求中的Data加密分析
Data
xhr断点打开继续跳
此时已生成Data和其它参数
往上跟栈，这里不太好跟，都是混淆的代码
拉到最前面位置
在 feiling.js 文件中定位到一个异步迭代函数的位置
参数是一个数组，里面都是大量的环境检测后的结果
在走两个栈进入一个 s 函数，并且在这里Data生成了
s 函数又是个嵌套控制流+大量三元运算
从头开始分析找 Data 的生成位置太费劲了
这里我们看到 Data 在参数 J 里面
那么我们直接在 s 函数里面找关键字 J[
可以搜到三处位置，那么这三处就是 J 对象里参数赋值位置
需要注意的是 feiling 这个文件也是动态更新的
你调试的时候可能和我这代码不一样
但是逻辑和分析的方式大致是不变的
GatherCost
Type
Data
既然 Data 位置找到了，那么下个断点跟过去
这里我跟的 feling 文件就更新了，代码也变了
现在不是 J 而是 R 了
这里只是创建了一个浅拷贝对象，最终要将这些环境加入加密
继续往下走几个循环
到这会进入一个异步promise
异步执行完后就会生成我们所有要的加密Data
这块调试就要靠耐心了，调到如下位置
继续调试就会再进入一个控制流
加密逻辑全在这个控制流里面了
算法就是多重aes加密
每次都变换不同key，iv是固定的
比如
将环境参数进行了拼接
而用到的 key 是哪来的呢
还记得第一次请求响应中的 DeviceConfig 吗
我们需要将它进行aes解密
用的是固定的 key 和 iv
解密完可以看到里面包含了时间戳、feling文件版本和ip等信息
前面的环境对象也会用到里面的一些参数，所以很重要
用井号分割取第一段进行base64解码
证实了这次aes加密的密钥就是这么来的
而它固定的key和iv找起来可以用技巧
如果你已经在调试Data加密过程的那么一定会走到如下图位置
否则直接全局搜索关键字 decrypt:
定位到 AliyunCaptcha.js 文件中
已知算法中会大量调用aes加解密
而这里正是其入口位置
那么我们直接在这下个断点或者插桩
就能看到所有的要加解密的数据和其key、iv
key、iv 是 WordArray 类型
需要再进行一下转换就是明文的了
String.fromCharCode(...n.words.flatMap(w => [(w>>>24)&0xff,(w>>>16)&0xff,(w>>>8)&0xff,w&0xff]).slice(0, n.sigBytes))
解密结果
解密后继续调试会进行赋值
剩余最后一次请求以及一些动态key的生成
我们下篇再继续分析
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：無色逆向 無色逆向《阿里V2滑动验证码算法分析-上篇》