声明
本文仅供学习参考，如有侵权可私信本人删除，请勿用于其他途径，违者后果自负！ 如果觉得文章对你有所帮助，可以给博主点击关注和收藏哦！
分析
网址：
aHR0cHM6Ly9jZmUubS5qZC5jb20vcHJpdmF0ZWRvbWFpbi9yaXNrX2hhbmRsZXIvMDMxMDE5MDAvP3JldHVybnVybD1odHRwczovL2l0ZW0uamQuY29tLzEwMDA0ODI3Mjc2Mi5odG1sJnJxaG9zdD1odHRwczovL2FwaS5tLmpkLmNvbSZycGlkPXJwLTE4NjU0OTQ5MC0xMDA1Ni0xNzA5NzEzMjA4MzcxJmV2dHlwZT0yJmV2YXBpPWNvbG9yX3BjX2RldGFpbHBhZ2Vfd2FyZUJ1c2luZXNzJnNvdXJjZT0xJmZvcmNlQ3VycmVudFZpZXc9MQ==
直接上图
点击【快速验证】
可以看到是一个比较常规的滑块验证码，感觉难度一般，只有轨迹校验的会比较严格。
还是老样子，进行一下抓包，观察一下整体的流程，然后进行模拟。
点击快速验证就会出来验证码相关的接口，逐个分析。
抓包分析
- 第一个api请求，参数中有一个
enbody进行了加密。
返回内容中有一个data，该参数贯穿整个流程，十分重要。
- 第二个api请求经过测试，可以忽略。
- fp接口，参数中有
si和ct两个加密参数。
响应中中的st在下面用到了，fp没有发现用处。
- 第一个check接口，请求参数有
si(第一个api返回的data)，tk、ct(和之前的ct无关)
相应内容比较关键了，有接口的base64格式的图片。
- 第二个check接口（滑块验证接口），请求参数有
si(第一个api返回的data)、tk和ct都是新的加密生成内容。
滑块验证正确的结果:
滑块验证失败的结果：
还有其他情况，这里就不过多展开了。如果出现代表加密参数模拟出现问题，自行检查。
总结
一共有4个网络请求需要关注
- 第一个api接口请求
- fp接口请求
- 第一次check接口请求
- 第二个check接口请求
逻辑分析
api请求分析
上文中提及的验证码发包流程请求均是xhr，所以直接打下xhr断点分析会比较方便，后面的所有接口都是这种方式去寻找堆栈。
- xhr断点怎么操作？
- Sources面板->右边XHR/fetch BreakPoints
重新刷新页面，点击快速验证即可触发断点。
向下跟几层堆栈，就可以发现端倪
| 参数 | 含义 |
|---|---|
| requrestId | 需要验证的页面id |
| evApi | 不清楚直接写死 |
| shshshfpx | 指纹随机生成 |
| eid | 不清楚直接写死 |
shshshfpx的算法可以扣一扣还是比较简单的。
然后就是请求参数中的enbody参数，跳进方法中。
实际加密是AES加密，直接引入现成库CryptoJS
// npm install crypto-js
const CryptoJS = require('crypto-js')
至此第一个api接口的加密参数分析完成，其实第二个api的加密和第一个是一致的，只是参数不同。
fp 请求分析
依旧是使用xhr断点，跟栈很轻松定位。
扣代码没什么难度，需要什么拿什么即可。
check请求分析
第一次请求中的t是空字符串，第二次的请求涉及到了轨迹加密。
我这里轨迹处理使用的是缩放法，也可以选择网上开源的轨迹库，这个问题不大。
验证
整体来说还是比较适合练手，难度适中。
参考资料
[某东三种验证码分析流程]
