声明

本文仅供学习参考，如有侵权可私信本人删除，请勿用于其他途径，违者后果自负！ 如果觉得文章对你有所帮助，可以给博主点击关注和收藏哦！

分析

网址：

aHR0cHM6Ly9jZmUubS5qZC5jb20vcHJpdmF0ZWRvbWFpbi9yaXNrX2hhbmRsZXIvMDMxMDE5MDAvP3JldHVybnVybD1odHRwczovL2l0ZW0uamQuY29tLzEwMDA0ODI3Mjc2Mi5odG1sJnJxaG9zdD1odHRwczovL2FwaS5tLmpkLmNvbSZycGlkPXJwLTE4NjU0OTQ5MC0xMDA1Ni0xNzA5NzEzMjA4MzcxJmV2dHlwZT0yJmV2YXBpPWNvbG9yX3BjX2RldGFpbHBhZ2Vfd2FyZUJ1c2luZXNzJnNvdXJjZT0xJmZvcmNlQ3VycmVudFZpZXc9MQ==

直接上图

点击【快速验证】
![image.png](https://img-blog.csdnimg.cn/img_convert/96ed05ad9c543a0f49860269989b4556.png

可以看到是一个比较常规的滑块验证码，感觉难度一般，只有轨迹校验的会比较严格。

还是老样子，进行一下抓包，观察一下整体的流程，然后进行模拟。

点击快速验证就会出来验证码相关的接口，逐个分析。

抓包分析

1. 第一个api请求，参数中有一个enbody进行了加密。

返回内容中有一个data，该参数贯穿整个流程，十分重要。

2. 第二个api请求经过测试，可以忽略。
3. fp接口，参数中有si和ct两个加密参数。

响应中中的st在下面用到了，fp没有发现用处。

4. 第一个check接口，请求参数有si(第一个api返回的data)，tk、ct(和之前的ct无关)

相应内容比较关键了，有接口的base64格式的图片。

5. 第二个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是空字符串，第二次的请求涉及到了轨迹加密。

我这里轨迹处理使用的是缩放法，也可以选择网上开源的轨迹库，这个问题不大。

验证

整体来说还是比较适合练手，难度适中。

参考资料

某东三种验证码分析流程