顶象二次验证分析，如何规避二次验证

顶象二次验证分析，如何规避二次验证

声明

本文章中所有内容仅供学习交流使用，不用于其他任何目的，不提供完整代码，抓包内容、敏感网址、数据接口等均已做脱敏处理，严禁用于商业用途和非法用途，否则由此产生的一切后果均与作者无关！
本文章未经许可禁止转载，禁止任何修改后二次传播，擅自使用本文讲解的技术而导致的任何意外，作者均不负责，若有侵权，请联系作者立即删除！
在互联网时代,随着网络安全问题日益引起人们的关注,各种验证码技术被广泛应用于各种网站和应用程序中,这其中包括了滑块验证码,它的应用范围十分广泛,本期逆向dx的滑块,可以看到它的防御能力和用户体验都是4星,适用于追求用户体验的业务场景,因此算是最为常见的了。

本篇难度入门
本篇难度入门
本篇难度入门

写在开头

该篇文章不针对某个网站，只对验证码分析走向做必要分析，常见的二次流程大概是如下：

常见的情况分为：

定制站域名 js不会改变，算法相对简单，建议扣算法

官源 一天二变

简要举例1

无意看到一个站，起初以为是上图第三种情况，无限循环验证，后面仔细一看这句话意思是出二次，但是手动是一次。

所以对应上文第二种情况，首先从环境入手，这里简单写几个坑点

环境

screen 不对的话会出二次验证，navigator dom 原型等检测，不对的话环境会设置异常，导致走二次。

轨迹

对于轨迹，我只能说基本不校验，还是那句话，格式和网页正确就行，看俩组对比图，

dinit.tm=new Date().getTime()-2300

初始化间隔，我设置的2300，正常压入的话，轨迹是基本无差的，1-2摆动，达到我们说的正确了吗？

![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传](

因为他调用的是这个 (0, De[“now”])() - this[“tm”];， 所以把这个now重写就行了，加上随机延迟，修正后如下：

这看着正常多了，我们首先先不重写这个date方法，我们来跑一次，稳稳出二次。

我们重写这个来跑一次，

后面就是把我刚刚说的那几个监测点屏蔽，然后对比去跑，你也能得到完美的结果。

简要举例2

以海X 举例，我们将蜜罐出现的必要条件 c 写错或者写死，发现出现如下：

常见蜜罐，无限面积，所以谁让你过面积，你请他吃罐头。

用正确的c跑一下.进入正常的二次逻辑：

顶x 定制站点选一般为生僻词，且标题也是生僻词，一般达到高准确率的办法就行混合生成，可以理解为这种办法做到一定情况可以通杀百分之95的点选，个别低的话混合一点真实数据集，否则遇到一个站从头开头，黄花菜都凉了。

生僻字/简体数据集目前的话已经几千万了，对于叠字也有支持率，遇到新验证，业务不至于宕掉。