丶妖冶叔叔
自动识别输入验证码的软件
简单来说，分为三步。
第一步：预处理将待识别的图片获取到，并转为机器可识别的内容。
一般来说，有二值化，阀值分割，霍夫变换等等图像处理的手段。
最后通常都是转成一串01代码。
第二步：训练对于简单的识别码，不需要训练，针对待识别的字码的特点设计相应的检测函数就可以。
对于复杂的验证码，就要用到一些相对的复杂的训练算法了。
在模式识别一书中有较多介绍。
第三步：识别通常有了预处理后的数据，与训练后的训练库，识别就是比较简单的一步了。
将待识别的验证码放入训练库中，得到的就是机器识别验证码的结果了。
有自动识别输入验证码的软件吗？
展开全部 目前按键精灵能够完成的验证码识别，只能做到规则的数字，文字等。
如果是类似QQ登录验证码那种，经过变形，小大无规律，排列紧凑的，是无法识别的。
识别的原理是比较简单的通过识别屏幕上的色点，有色的点视为1，无色的点为0，则一个数字或者文字字符就可以化为01010101的字串，然后通过这个特征字串与已经保存识别出来的字串相比，就可以知道该字串相应的文字或者数字。
例如：1 这个数字，特征字串是1010101000001010000000，如果屏幕识别后得到的字串相同的话，就可以认为这个字符识别出来就是 1 这个数字。
如果是带有杂点的验证码的话，可以通过将验证图片2值化降噪处理。
原理相对简单，取色点的RGB值然后（R+B+G）/3，得到的值大于某数，或者小于某数，就可以化为1或者0....
腾讯的点击验证码是什么原理
对于伪造网络请求的攻击方面，还有很多技术细节，篇幅有限，如果感兴趣可以看一下我的这篇博客，讲的就是有关验证码方面的一些技术细节：CSRF漏洞的原理如果提到的哪个专业术语我没有做通俗的解释，请在下方回复。
如果觉得长，想要直入主题的话可以直接找到 ---重要内容分割线---，看那部分其实是这套验证码最核心的安全机制。
目前web前端的验证码主要分几类：1 看到图形，肉眼识别后输入字符；2 根据界面图形，进行鼠标、手指（移动端）交互操作；3 短信、电话、邮箱验证。
其中第3条，很多时候往往会与第1条相结合起来，以防止CSRF漏洞造成的短信炸弹攻击。
包括用户无感知的人机检验方式（简单地如前端token+referrer判断，这个待会儿再讲）在内，以上所说的所有手段，终究目的是一个，那就是检查当前访问者究竟是一个“人”，还是一台“机器”。
这在计算机研究领域被称为图灵测试，图灵是一位计算机科学家，他提出对于“人工智能”的定义是：如果把一台电脑放在一个与外界隔绝的房间里，同时把一个人放在一个一模一样的房间里，同时对人和电脑进行各种各样的提问、测试，如果两者做出的反应基本一致（总会有差异，哪怕人与人之间也会有不同），那么认为这台电脑的算法水平已经达到了“人工智能”的级别。
说了这么多，想表达的还是一点，对于“让机器模拟人的行为”或者说“把自己伪装成一个人”，这样的事情在专业领域是有很多研究的。
现在网络上存在着诸多验证码、安全校验等等东西，很多人不理解，认为这种东西增加了人们对于软件的正常使用的成本。
其实这些安全手段，都是为了防止黑客以各种各样的技术手段，伪造网络请求，假冒真实用户的身份去“刷”网站的各个接口。
下面回到主题，来谈一谈题主所提到的这个腾讯的验证码页面的技术实现。
粗略地翻了一下这个页面的源代码（对于web领域，页面程序的源代码是完全裸奔的，这一点与客户端程序不同，所以如果想要研究对方的代码，对于web开发者来说是一件比较容易的事情，换句话说web前端代码里边是没有太多秘密可言的，因此web的安全性也相对差一些），这个页面在我见过的一些验证码系统中是很常见的一种，就是前面提到的那第1种，看图识别输入字符的验证码形式。
下面上代码：先来看看在UI层面，就是最常见的，通过javascript在DOM上绑定的监听事件触发回调，如图所示，如果我把右边红圈中的click监听remove掉，点击按钮之后就什么反应都没有了，所以基本确定它验证码的逻辑都卸载了这个CT_btn_trigger的回调函数中。
然后看看点击后弹出的layer：全都是用DOM实现的，我在代码中没有发现任何flash object的痕迹（为什么提flash，这个也放在后边说），输入验证码之后监听网络数据包，找到了发送验证码的那个接口：服务端的接受验证码的接口为https://ssl.captcha.qq.com/cap_union_verify_new 而我们刚刚输入的一条验证码，query字段名称是ans。
这里的这一条网络请求是https协议传输的，包括整个qq安全中心的页面也都是上了https的，https协议与我们熟知的http协议最大的不同就是，通过加密手段规避掉了网络中间层对数据包的截获，这一点对于这套验证码来说还是值得肯定的，目前的很多验证码系统对于传输验证码的网络请求都没有上https。
昨晚看的仓促，刚刚又翻了一下发现了这一套验证码系统的核心部分，其实就是上面截图中的collect字段，感谢 @李默然 的提醒，这部分其实也就是我在前文中所提到的那个token，从collect这个字段命名不难猜出这个token是一个前端拼装起来的东西。
具体如何拼装，在这里我就不一一扒代码了，考虑到毕竟是一个安全中心的页面，把技术细节在这里讲的太透了，普通用户也不那么关心，反倒是替别有用心的人省了点儿事。
所以就不给腾讯的前端同学找麻烦了，在这里简单述说说吧。
collect参数，在用户点击这个按钮的那一刻，就会从服务端传过来一个collect参数，这时的collect参数中做了一些组装和软加密处理，拿到的是密文，明文中的内容不难猜测一定包裹了验证码所需的那张图片的url。
当输入验证码完成后，从客户端发往服务器的那条请求中，虽然ans字段中的验证码是明文，但是还依然带了一个collect字段，而这时的collect字段和上一个collect字段内容是不同的，显然也是一个加密后的结果，推测可知这个collect字段在服务端解密后拿到的明文中，至少也要包含用户本地操作的一些数据，这数据中就包括，他输入的那段验证码所对应的图片究竟是哪张。
也许存了图片的url，也许是服务端记录图片的某一组key值，但这个对应关系是一定要有的。
以上提到的collect字段，其实是整个这套验证码系统最为关键的一点，黑客如果要破译这层csrf防御，首先需要搞明白两处collect字段是如何加密的。
如果放在其他系统客户端的角度来说，破译这层加密的难度不小，但是由于web客户端的代码是裸奔的，这个天然的劣势导致，黑客不一定要以数学的方法去解出这套加密机制，而是可以直接翻看源代码，看明白collect字段是怎么拼装的，然后只要结合起图片识别模块就可以对这个接口进行强刷了...
转载请注明出处51数据库 » 自动识别验证码软件原理
