最近在搞某东的详情页抓取，在解决了h5st后进行翻页抓取时弹出了验证码，h5st的逆向可以参考我之前的文章，虽然版本更新频繁，但加密逻辑和环境几乎不变

大体观测后，知道了验证码出现的形式有三种，且商品页和详情页的各接口共用风控，即商品页出现验证码，详情页同样也会出现验证码，二者共用一套加密，依次为滑块、点选、旋转验证码，且触发旋转验证码后续不会变回前两者，旋转验证码样式如下

解决验证码可粗略分为3步：获取图片，识别图片，提交验证

1.获取图片：

获取图片用到了check接口，请求头中无加密，在负载中存在si，tk，ct三个加密参数，长度令人望而却步，但其实难度并不高，依次分析

si：复制后进行搜索，结果如下：

点击进入发现由服务器返回：

粗略看一下只有负载中body一个加密参数：

那si就只需要逆向body一个参数即可，xhr断点到这个位置：

代码做了混淆，body已生成且存储于_0x6835d9中，跟栈到此处

找到了body的生成位置，往上浏览不难发现是webpack加密

鉴于本人比较懒，所以选择直接全扣补环境，补环境过程在此省略，因为难度不大，至于吐环境脚本都是开源的，导出加载器补模块即可，最后附上结果图

rpid和evsid均在代码频繁请求触发验证码时由接口返回，但在浏览器中似乎并不会显示

tk、ct：xhr断点一步步跟栈即可找到，在此不再赘述，代码大致如下，仅供参考

其中所需参数均由服务器返回、轨迹或已存在的加密参数

2.识别图片：

市面上对于旋转验证码的识别较少，我问了云码的客服要了一个接口可识别该类旋转验证码，成功率5成以上，注意 图片在浏览器中存在缩放 ，比例可自行测试，轨迹我采用 写死 的方式，即把所有成功的轨迹手动拿下来，大概拿了50套左右，计算长度，然后根据长度返回轨迹，因为很多轨迹生成的方式经测试成功率都极低

3.提交验证：

在识别成功并再次通过check接口提交并返回值后依然回弹出验证码，经过测试后发现还需要带着返回的值去提交1个接口，即图中的invoke3，其加密参数与获取验证码时出现的enbody参数在同一个js文件中生成，但加密方式不同，可以从长度看出来

invoke2应该可有可无，我没有测试，但invoke3中使用了invoke2生成的加密参数与响应数据，所以还算有点用吧

至此，某东旋转验证码就算是结束了，总结验证流程吧：

获取图片——识别图片——提交验证，呼应上文，hhh

注意：

1.浏览器图片存在缩放；

2.商品页和详情页虽然使用相同加密但部分参数不同；

3.异步调用可删除；

文章仅供学习与交流，如有侵权或其他行为，请联系作者删除