1. 项目概述与核心价值在渗透测试和Web应用安全评估中登录、注册、找回密码等关键功能点前的验证码常常是自动化攻击如暴力破解、撞库的主要防线。传统的BurpSuite Intruder模块虽然功能强大但在面对图形验证码时往往需要手动识别并输入效率极低严重制约了测试的深度和广度。这个项目要解决的正是这个痛点将高精度的开源验证码识别库ddddocr与BurpSuite的自动化攻击引擎无缝集成实现验证码的实时、自动识别与绕过从而让爆破、枚举等测试流程真正实现全自动化。我之所以花时间折腾这个集成是因为在实际项目中遇到过太多“看似坚固”的验证码。有些验证码设计得并不复杂但手动处理几十上百次请求就足以让人崩溃。而市面上一些现成的Burp插件要么收费要么识别率感人要么配置复杂。ddddocr这个基于深度学习的OCR库在识别常见数字、字母验证码上表现出了惊人的准确率和速度而且是Python编写、开源免费这为我们打造一个轻量、高效、可控的自动化解决方案提供了绝佳的基础。这个方案不仅适用于安全测试人员对于需要进行大量重复请求测试的开发者和QA工程师同样具有很高的参考价值。简单来说这个项目的核心就是在BurpSuite发起自动化攻击如Intruder爆破时让每一次请求都能自动获取并识别页面中的验证码然后将识别结果作为请求参数的一部分发送出去全程无需人工干预。下面我将从设计思路、环境搭建、核心实现到避坑技巧完整地拆解这个过程。2. 整体架构与设计思路拆解要实现BurpSuite与ddddocr的集成我们不能指望有一个现成的“一键安装”插件。因为BurpSuite的插件体系基于Java和ddddocr基于Python处于不同的技术栈。因此核心思路是构建一个**“桥梁”式**的架构。这个架构通常包含三个部分BurpSuite插件端Client负责在BurpSuite中捕获HTTP请求提取出验证码图片可能是Base64编码也可能是图片URL然后将图片发送给识别服务端并接收返回的识别结果最后修改原始请求填入识别出的验证码。验证码识别服务端Server一个独立的、常驻的HTTP/API服务。它接收来自BurpSuite插件端发送的验证码图片数据调用ddddocr库进行识别并将识别出的文本结果返回。ddddocr识别引擎Engine服务的核心负责实际的图像识别计算。为什么选择这种CS客户端-服务器架构而不是开发一个纯Java的Burp插件直接集成ddddocr主要原因有三点技术栈隔离ddddocr及其依赖如ONNX Runtime、Pillow是Python生态的产物在Java中直接调用非常复杂且容易出错。通过HTTP API解耦双方只需遵守简单的数据协议。灵活性与可维护性识别服务可以独立部署、升级和扩展。例如你可以将识别服务部署在一台性能更强的机器上或者未来轻松切换为其他OCR引擎如PaddleOCR而无需修改Burp插件。复用性这个识别服务不仅可以服务于BurpSuite理论上任何能发送HTTP请求的工具如Python脚本、Postman集合、其他安全工具都可以调用它。在这个项目中我们将重点使用一个非常成熟且活跃的开源项目captcha-killer-modified作为我们的BurpSuite插件客户端。它原生支持这种代理识别的模式。而服务端我们将用Python的Flask框架快速搭建一个专门用于调用ddddocr。3. 环境准备与工具选型工欲善其事必先利其器。下面列出所有必需的软件和库并解释其作用。3.1 基础软件安装Java环境 (JRE 8): BurpSuite是基于Java开发的必须安装Java运行环境。建议安装最新的JRE 8或JDK 11 LTS版本。检查安装在终端输入java -version。BurpSuite Professional/Community: 本项目在Community免费版上即可运行。建议从PortSwigger官网下载最新版这是最安全、稳定的来源。Python 3.7: ddddocr需要Python 3.7及以上版本。建议安装Python 3.8或3.9兼容性最好。检查安装在终端输入python --version或python3 --version。代码编辑器/IDE: 如VS Code、PyCharm用于编写和调试Python识别服务端代码。3.2 核心Python库安装识别服务端依赖于以下几个Python库通过pip安装pip install flask pillow ddddocr requestsFlask: 轻量级Web框架用于快速搭建提供识别API的HTTP服务。Pillow (PIL): Python图像处理库ddddocr内部会用到用于加载和处理图片数据。ddddocr: 核心OCR库由深度炼丹炉训练针对验证码识别优化。requests: 可选。用于在服务端代码中测试或进行额外的网络请求例如如果验证码是URL可能需要先下载。注意安装ddddocr时它会自动安装其深度学习推理后端如onnxruntime。如果遇到网络问题可以考虑使用国内镜像源例如pip install ddddocr -i https://pypi.tuna.tsinghua.edu.cn/simple3.3 关键BurpSuite插件Captcha-Killer-Modified这是整个方案的“大脑”。原版Captcha-Killer已经停止维护而captcha-killer-modified是其社区维护的增强版修复了大量问题并增加了对新版BurpSuite的兼容性。获取方式在GitHub上搜索captcha-killer-modified从其Releases页面下载最新的.jar文件。安装在BurpSuite中依次点击Extender-Extensions-Add在Extension type选择Java然后加载下载的jar文件。为什么是它它提供了一个图形化界面来配置识别接口支持多种图片格式输入Raw、Base64、URL并能无缝集成到Intruder、Repeater等模块中通过设置Payload Processing规则自动调用识别服务。4. 验证码识别服务端Python Flask搭建详解服务端是整个流程的“计算中心”。它的任务很简单接收一个包含图片的POST请求识别返回文本。我们将创建一个名为ocr_server.py的文件。4.1 服务端核心代码实现#!/usr/bin/env python3 # -*- coding: utf-8 -*- BurpSuite ddddocr 验证码识别服务端 运行python ocr_server.py 默认监听 http://127.0.0.1:6000 import base64 import io import logging from flask import Flask, request, jsonify from PIL import Image import ddddocr # 配置日志方便调试 logging.basicConfig(levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s) logger logging.getLogger(__name__) app Flask(__name__) # 全局加载一次识别器避免每次请求重复加载耗时 # 注意ddddocr 第一次初始化可能会稍慢因为它要加载模型 try: ocr ddddocr.DdddOcr(show_adFalse) # show_adFalse 关闭广告信息 logger.info(ddddocr 识别器初始化成功) except Exception as e: logger.error(fddddocr 初始化失败: {e}) ocr None def decode_image(image_data): 通用图片解码函数处理Base64或二进制数据 img None try: # 尝试作为Base64解码 if isinstance(image_data, str) and (image_data.startswith(data:image) or len(image_data) 200): # 处理可能包含 data:image/png;base64, 前缀的格式 if base64, in image_data: image_data image_data.split(base64,)[1] img_data base64.b64decode(image_data) img Image.open(io.BytesIO(img_data)) else: # 否则视为二进制数据 img Image.open(io.BytesIO(image_data)) # 统一转换为RGB模式兼容性更好 if img.mode ! RGB: img img.convert(RGB) return img except Exception as e: logger.error(f图片解码失败: {e}) return None app.route(/ocr, methods[POST]) def handle_ocr(): 处理OCR识别请求的主接口 if ocr is None: return jsonify({error: OCR引擎未初始化}), 500 result {success: False, code: , message: } try: # 获取请求数据 data request.get_json() if not data: # 如果JSON解析失败尝试从form-data或raw body获取 data request.form.to_dict() if not data and request.data: # 可能是纯二进制图片数据 image_raw request.data img decode_image(image_raw) else: image_data data.get(image) if not image_data: return jsonify({success: False, code: , message: 未找到图片数据(image字段)}), 400 img decode_image(image_data) else: # JSON格式请求 image_data data.get(image) if not image_data: return jsonify({success: False, code: , message: JSON中未找到image字段}), 400 img decode_image(image_data) if img is None: return jsonify({success: False, code: , message: 图片数据解析失败}), 400 # 使用ddddocr进行识别 # 注意ddddocr的classification方法接收的是bytes img_byte_arr io.BytesIO() img.save(img_byte_arr, formatPNG) img_bytes img_byte_arr.getvalue() code ocr.classification(img_bytes) logger.info(f识别结果: {code}) result[success] True result[code] code result[message] 识别成功 except Exception as e: logger.exception(识别过程发生异常) result[message] f服务器内部错误: {str(e)} return jsonify(result), 500 return jsonify(result) app.route(/health, methods[GET]) def health_check(): 健康检查接口用于测试服务是否正常 return jsonify({status: ok, engine: ddddocr}) if __name__ __main__: # 启动服务监听本地6000端口允许远程主机访问如果需要 # debugTrue 仅用于开发生产环境应设为False app.run(host0.0.0.0, port6000, debugFalse, threadedTrue)4.2 服务端代码关键点解析全局OCR对象在服务启动时初始化ddddocr.DdddOcr()对象。这是一个重要的性能优化点。模型加载到内存需要时间和资源将其设为全局变量可以让所有后续识别请求共享同一个模型极大提升响应速度。灵活的图片处理decode_image函数尝试处理多种常见的图片输入格式带data:image/png;base64,前缀的完整Base64字符串。纯Base64字符串。原始的图片二进制数据Burp插件可能直接发送图片字节流。 这种鲁棒性设计确保了服务能适应不同插件或工具的调用方式。统一的RGB转换PIL库打开的图片可能有多种模式如RGBA, L等。将其统一转换为RGB模式可以避免因图片格式问题导致的识别错误。错误处理与日志完善的try...except块和日志记录对于调试在BurpSuite中出现的“识别失败”问题至关重要。通过查看服务端日志能快速定位是图片传输问题、解码问题还是ddddocr自身识别问题。健康检查接口(/health)这是一个好习惯。在浏览器中访问http://127.0.0.1:6000/health可以快速确认服务是否已成功启动。4.3 启动与测试服务在终端中进入ocr_server.py所在目录运行python ocr_server.py如果看到输出* Running on http://0.0.0.0:6000/和ddddocr 识别器初始化成功说明服务启动成功。你可以使用curl或 Postman 进行快速测试# 假设有一张验证码图片 code.png base64_str$(base64 -i code.png | tr -d \n) curl -X POST http://127.0.0.1:6000/ocr \ -H Content-Type: application/json \ -d {\image\: \$base64_str\}如果返回{code:5JgX,success:true}之类的JSON恭喜你服务端搭建成功。5. BurpSuite插件配置与联动实战服务端就绪后接下来就是在BurpSuite中配置captcha-killer-modified插件让它与我们的识别服务联动。5.1 插件界面概览与基本配置安装好插件后在BurpSuite顶部标签页会多出一个Captcha Killer。界面功能区Request用于配置如何从目标HTTP请求中“获取”验证码图片。Image显示当前获取到的验证码图片。Result显示识别服务返回的结果。Configuration核心配置区用于设置识别接口我们的Flask服务。配置识别接口切换到Configuration标签页。在Interface下拉菜单旁点击Add新增一个接口。URL填写我们的服务地址http://127.0.0.1:6000/ocr。Content-Type选择application/json。Post Data这里需要配置请求体。我们的服务期望一个JSON包含image字段。图片数据需要从HTTP请求中动态提取。配置如下{image: “[pic_base64]”}这里的[pic_base64]是一个占位符插件会自动用实际获取到的Base64图片数据替换它。Result Parsing这里告诉插件如何从服务返回的JSON中提取识别出的文本。我们的服务返回格式是{code: “识别结果”, ...}。因此配置Prefix为code: Suffix为。插件会截取这两个字符串之间的内容作为结果。5.2 实战案例配置一个登录爆破场景假设我们目标登录接口为POST /login请求参数为usernameadminpassword123456captcha???验证码图片由GET /captcha.php返回。步骤一获取验证码图片请求浏览器访问登录页BurpSuite开启代理拦截。找到浏览器加载验证码的请求通常是GET /captcha.php或类似将其发送到Captcha Killer插件界面。可以直接在Proxy history里右键该请求选择Send to Captcha Killer。步骤二配置图片获取规则在插件的Request标签页你会看到刚才发送的请求。点击Get按钮插件会执行这个请求并在Image区域显示获取到的图片。关键步骤我们需要告诉插件后续每次识别时都要重新执行这个GET请求来获取新的验证码。在Request区域确保选中的是我们刚发送的请求这表示将其作为“图片获取模板”。步骤三测试识别接口确保Python服务端正在运行。在Captcha Killer界面点击Get获取一张新图片然后点击识别按钮。观察Result区域。如果配置正确这里会显示从我们Flask服务返回的识别结果。重要调试如果识别失败查看Python服务端的终端输出日志这里会有详细的错误信息是排查问题的关键。步骤四集成到Intruder进行爆破这是最终目的。我们想爆破密码但每次请求都需要新的验证码。拦截一个完整的登录请求包含用户名、密码和验证码发送到Intruder模块。在Positions标签页清除所有自动标记然后手动标记你想要爆破的参数比如password。最关键的一步在Payloads标签页找到最下方的Payload Processing区域。点击Add-Invoke Burp Extension。在弹出的扩展选择器中选择Captcha Killer。这会打开一个配置窗口。你需要在这里配置“如何将识别出的验证码填入到HTTP请求中”。首先在Request部分你需要指定“从哪里获取验证码图片”。这通常就是我们在Captcha Killer主界面配置好的那个GET /captcha.php请求模板。插件会记住这个配置。然后在Response部分你需要配置“如何从识别结果中提取验证码文本”。这通常就是我们在Configuration里配置的结果解析规则Prefix/Suffix插件也会自动应用。最后在Update Request部分你需要指定“将提取到的文本替换原始请求中的哪个部分”。你需要指定一个参数名如captcha或一个自定义的字符串位置通过Add定义范围。通常我们会选择Update parameter然后输入参数名captcha。配置完成后回到Intruder的Payloads标签页你会看到添加了一条处理规则。这意味着Intruder在发送每一个Payload即每一个密码尝试之前都会先执行以下流程 a. 调用Captcha Killer插件。 b. 插件执行配置的GET /captcha.php请求获取一张全新的验证码图片。 c. 将图片发送到我们的http://127.0.0.1:6000/ocr服务进行识别。 d. 从返回结果中提取验证码文本。 e. 用这个文本替换原始攻击请求中的captcha参数值。 f. 发送修改后的登录请求进行爆破。至此一个全自动的、带验证码识别的爆破流程就配置完成了。点击Intruder的Start attack你将看到请求自动进行每个请求都使用了不同的验证码。6. 常见问题、排查技巧与优化实录在实际集成和使用过程中你几乎一定会遇到各种问题。下面是我踩过坑后总结的排查清单和优化建议。6.1 识别服务端常见问题问题现象可能原因排查步骤与解决方案服务启动失败提示端口占用端口6000被其他程序占用netstat -ano | findstr :6000(Win) 或lsof -i:6000(Mac/Linux) 查找并终止占用进程或修改app.run(port新的端口)。插件点击“识别”后Result报错或为空1. 服务未启动或网络不通。2. 接口URL或Post Data配置错误。3. 图片数据格式插件未正确提取。1. 浏览器访问http://127.0.0.1:6000/health确认服务存活。2. 在插件Configuration中检查URL和Post Data格式确保与服务器代码一致。特别注意JSON格式和引号。3. 查看Python服务端日志看是否收到请求以及错误信息。在插件Image标签页尝试将图片以Base64形式复制出来用curl手动测试接口。服务端日志显示图片解码失败插件发送的图片数据格式不符合预期。在Flask服务的handle_ocr函数开头添加logger.info(request.headers)和logger.info(request.data[:200])打印原始请求信息查看插件到底发送了什么。根据实际情况调整decode_image函数。识别率突然下降1. 验证码类型变化如中文、算式。2. 图片有严重干扰线、扭曲。3. ddddocr模型对该类型不擅长。1. ddddocr对纯数字字母验证码效果最好。如果是算式验证码需要先进行图像预处理如二值化、去噪或使用其他专门模型。2. 考虑在服务端添加预处理逻辑使用Pillow进行灰度化、二值化、降噪。3. 可以尝试ddddocr.DdddOcr(betaTrue)使用测试版模型或寻找更专门的OCR库。6.2 BurpSuite插件配置常见问题问题现象可能原因排查步骤与解决方案Intruder攻击时每个请求的验证码都一样插件配置的“获取验证码图片”的请求没有真正被执行或者该请求本身不返回新图片。1. 在Captcha Killer主界面确认Request里选中的是获取验证码的请求如GET /captcha.php而不是登录请求。2. 单独在Captcha Killer里多次点击Get观察图片是否变化。如果不变化说明目标服务器可能在会话Session/Cookie未变时返回相同图片。需要检查获取验证码的请求是否携带了正确的会话标识如Cookie、Token并在插件中配置“每次识别时使用当前会话”。Intruder攻击请求中的验证码字段未被替换Payload Processing规则中的“Update Request”配置错误。1. 在Intruder的Payload Processing规则中双击Captcha Killer规则进行编辑。2. 在Update Request部分确认你选择的是Update parameter并正确填写了参数名如captcha且该参数名与原始请求中的参数名完全一致包括大小写。3. 可以先用Repeater模块测试在Repeater中右键也有Extensions-Captcha Killer-Send to Intruder with Captcha的选项从这里生成的Intruder攻击模板其Payload Processing规则通常是预配好的成功率更高。插件界面点击“识别”正常但集成到Intruder后失败Intruder的Payload Processing是在每个Payload发送前动态执行的环境可能与插件主界面静态测试时不同。1. 检查Intruder攻击的“Resource Pool”设置是否限制了线程数或添加了延迟过快的请求可能导致目标服务器反爬或会话失效。2. 在Captcha Killer的Configuration-Request配置中确保勾选了Use current session或正确配置了会话处理如自动更新Cookie。这能保证Intruder在每次获取验证码时使用的是最新的会话状态。6.3 性能与稳定性优化心得服务端性能Flask默认是单线程同步的。当Intruder并发线程数很高时识别服务可能成为瓶颈。可以通过app.run(threadedTrue)启用多线程或者使用生产级WSGI服务器如gunicorn来部署服务。pip install gunicorn gunicorn -w 4 -b 0.0.0.0:6000 ocr_server:app-w 4表示启动4个 worker 进程并发处理能力更强。识别缓存对于某些系统同一个会话短时间内验证码可能不变。可以在服务端添加一个简单的缓存如使用functools.lru_cache以图片数据的MD5值为键避免对完全相同的图片进行重复识别减少计算开销。错误重试与降级在Intruder的Payload Processing中可以配置多条规则。例如第一条规则调用Captcha Killer如果识别失败返回空则触发第二条规则使用一个固定的错误值或手动输入。这可以防止因偶发识别失败导致整个攻击停止。验证码类型判断更高级的用法是在服务端对图片进行简单分析如颜色分布、尺寸、轮廓先判断验证码类型再决定调用哪个识别模型ddddocr用于字符其他模型用于算式实现更通用的识别服务。这个从零搭建的BurpSuite集成ddddocr的方案虽然需要一些配置步骤但它给了你完全的控制权和透明度。你清楚地知道图片如何流转、文本如何识别、请求如何被修改。这种掌控感在面对复杂多变的实际测试环境时比任何黑盒工具都来得可靠。 基于ddddocr与BurpSuite的验证码自动化识别与绕过实战
1. 项目概述与核心价值在渗透测试和Web应用安全评估中登录、注册、找回密码等关键功能点前的验证码常常是自动化攻击如暴力破解、撞库的主要防线。传统的BurpSuite Intruder模块虽然功能强大但在面对图形验证码时往往需要手动识别并输入效率极低严重制约了测试的深度和广度。这个项目要解决的正是这个痛点将高精度的开源验证码识别库ddddocr与BurpSuite的自动化攻击引擎无缝集成实现验证码的实时、自动识别与绕过从而让爆破、枚举等测试流程真正实现全自动化。我之所以花时间折腾这个集成是因为在实际项目中遇到过太多“看似坚固”的验证码。有些验证码设计得并不复杂但手动处理几十上百次请求就足以让人崩溃。而市面上一些现成的Burp插件要么收费要么识别率感人要么配置复杂。ddddocr这个基于深度学习的OCR库在识别常见数字、字母验证码上表现出了惊人的准确率和速度而且是Python编写、开源免费这为我们打造一个轻量、高效、可控的自动化解决方案提供了绝佳的基础。这个方案不仅适用于安全测试人员对于需要进行大量重复请求测试的开发者和QA工程师同样具有很高的参考价值。简单来说这个项目的核心就是在BurpSuite发起自动化攻击如Intruder爆破时让每一次请求都能自动获取并识别页面中的验证码然后将识别结果作为请求参数的一部分发送出去全程无需人工干预。下面我将从设计思路、环境搭建、核心实现到避坑技巧完整地拆解这个过程。2. 整体架构与设计思路拆解要实现BurpSuite与ddddocr的集成我们不能指望有一个现成的“一键安装”插件。因为BurpSuite的插件体系基于Java和ddddocr基于Python处于不同的技术栈。因此核心思路是构建一个**“桥梁”式**的架构。这个架构通常包含三个部分BurpSuite插件端Client负责在BurpSuite中捕获HTTP请求提取出验证码图片可能是Base64编码也可能是图片URL然后将图片发送给识别服务端并接收返回的识别结果最后修改原始请求填入识别出的验证码。验证码识别服务端Server一个独立的、常驻的HTTP/API服务。它接收来自BurpSuite插件端发送的验证码图片数据调用ddddocr库进行识别并将识别出的文本结果返回。ddddocr识别引擎Engine服务的核心负责实际的图像识别计算。为什么选择这种CS客户端-服务器架构而不是开发一个纯Java的Burp插件直接集成ddddocr主要原因有三点技术栈隔离ddddocr及其依赖如ONNX Runtime、Pillow是Python生态的产物在Java中直接调用非常复杂且容易出错。通过HTTP API解耦双方只需遵守简单的数据协议。灵活性与可维护性识别服务可以独立部署、升级和扩展。例如你可以将识别服务部署在一台性能更强的机器上或者未来轻松切换为其他OCR引擎如PaddleOCR而无需修改Burp插件。复用性这个识别服务不仅可以服务于BurpSuite理论上任何能发送HTTP请求的工具如Python脚本、Postman集合、其他安全工具都可以调用它。在这个项目中我们将重点使用一个非常成熟且活跃的开源项目captcha-killer-modified作为我们的BurpSuite插件客户端。它原生支持这种代理识别的模式。而服务端我们将用Python的Flask框架快速搭建一个专门用于调用ddddocr。3. 环境准备与工具选型工欲善其事必先利其器。下面列出所有必需的软件和库并解释其作用。3.1 基础软件安装Java环境 (JRE 8): BurpSuite是基于Java开发的必须安装Java运行环境。建议安装最新的JRE 8或JDK 11 LTS版本。检查安装在终端输入java -version。BurpSuite Professional/Community: 本项目在Community免费版上即可运行。建议从PortSwigger官网下载最新版这是最安全、稳定的来源。Python 3.7: ddddocr需要Python 3.7及以上版本。建议安装Python 3.8或3.9兼容性最好。检查安装在终端输入python --version或python3 --version。代码编辑器/IDE: 如VS Code、PyCharm用于编写和调试Python识别服务端代码。3.2 核心Python库安装识别服务端依赖于以下几个Python库通过pip安装pip install flask pillow ddddocr requestsFlask: 轻量级Web框架用于快速搭建提供识别API的HTTP服务。Pillow (PIL): Python图像处理库ddddocr内部会用到用于加载和处理图片数据。ddddocr: 核心OCR库由深度炼丹炉训练针对验证码识别优化。requests: 可选。用于在服务端代码中测试或进行额外的网络请求例如如果验证码是URL可能需要先下载。注意安装ddddocr时它会自动安装其深度学习推理后端如onnxruntime。如果遇到网络问题可以考虑使用国内镜像源例如pip install ddddocr -i https://pypi.tuna.tsinghua.edu.cn/simple3.3 关键BurpSuite插件Captcha-Killer-Modified这是整个方案的“大脑”。原版Captcha-Killer已经停止维护而captcha-killer-modified是其社区维护的增强版修复了大量问题并增加了对新版BurpSuite的兼容性。获取方式在GitHub上搜索captcha-killer-modified从其Releases页面下载最新的.jar文件。安装在BurpSuite中依次点击Extender-Extensions-Add在Extension type选择Java然后加载下载的jar文件。为什么是它它提供了一个图形化界面来配置识别接口支持多种图片格式输入Raw、Base64、URL并能无缝集成到Intruder、Repeater等模块中通过设置Payload Processing规则自动调用识别服务。4. 验证码识别服务端Python Flask搭建详解服务端是整个流程的“计算中心”。它的任务很简单接收一个包含图片的POST请求识别返回文本。我们将创建一个名为ocr_server.py的文件。4.1 服务端核心代码实现#!/usr/bin/env python3 # -*- coding: utf-8 -*- BurpSuite ddddocr 验证码识别服务端 运行python ocr_server.py 默认监听 http://127.0.0.1:6000 import base64 import io import logging from flask import Flask, request, jsonify from PIL import Image import ddddocr # 配置日志方便调试 logging.basicConfig(levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s) logger logging.getLogger(__name__) app Flask(__name__) # 全局加载一次识别器避免每次请求重复加载耗时 # 注意ddddocr 第一次初始化可能会稍慢因为它要加载模型 try: ocr ddddocr.DdddOcr(show_adFalse) # show_adFalse 关闭广告信息 logger.info(ddddocr 识别器初始化成功) except Exception as e: logger.error(fddddocr 初始化失败: {e}) ocr None def decode_image(image_data): 通用图片解码函数处理Base64或二进制数据 img None try: # 尝试作为Base64解码 if isinstance(image_data, str) and (image_data.startswith(data:image) or len(image_data) 200): # 处理可能包含 data:image/png;base64, 前缀的格式 if base64, in image_data: image_data image_data.split(base64,)[1] img_data base64.b64decode(image_data) img Image.open(io.BytesIO(img_data)) else: # 否则视为二进制数据 img Image.open(io.BytesIO(image_data)) # 统一转换为RGB模式兼容性更好 if img.mode ! RGB: img img.convert(RGB) return img except Exception as e: logger.error(f图片解码失败: {e}) return None app.route(/ocr, methods[POST]) def handle_ocr(): 处理OCR识别请求的主接口 if ocr is None: return jsonify({error: OCR引擎未初始化}), 500 result {success: False, code: , message: } try: # 获取请求数据 data request.get_json() if not data: # 如果JSON解析失败尝试从form-data或raw body获取 data request.form.to_dict() if not data and request.data: # 可能是纯二进制图片数据 image_raw request.data img decode_image(image_raw) else: image_data data.get(image) if not image_data: return jsonify({success: False, code: , message: 未找到图片数据(image字段)}), 400 img decode_image(image_data) else: # JSON格式请求 image_data data.get(image) if not image_data: return jsonify({success: False, code: , message: JSON中未找到image字段}), 400 img decode_image(image_data) if img is None: return jsonify({success: False, code: , message: 图片数据解析失败}), 400 # 使用ddddocr进行识别 # 注意ddddocr的classification方法接收的是bytes img_byte_arr io.BytesIO() img.save(img_byte_arr, formatPNG) img_bytes img_byte_arr.getvalue() code ocr.classification(img_bytes) logger.info(f识别结果: {code}) result[success] True result[code] code result[message] 识别成功 except Exception as e: logger.exception(识别过程发生异常) result[message] f服务器内部错误: {str(e)} return jsonify(result), 500 return jsonify(result) app.route(/health, methods[GET]) def health_check(): 健康检查接口用于测试服务是否正常 return jsonify({status: ok, engine: ddddocr}) if __name__ __main__: # 启动服务监听本地6000端口允许远程主机访问如果需要 # debugTrue 仅用于开发生产环境应设为False app.run(host0.0.0.0, port6000, debugFalse, threadedTrue)4.2 服务端代码关键点解析全局OCR对象在服务启动时初始化ddddocr.DdddOcr()对象。这是一个重要的性能优化点。模型加载到内存需要时间和资源将其设为全局变量可以让所有后续识别请求共享同一个模型极大提升响应速度。灵活的图片处理decode_image函数尝试处理多种常见的图片输入格式带data:image/png;base64,前缀的完整Base64字符串。纯Base64字符串。原始的图片二进制数据Burp插件可能直接发送图片字节流。 这种鲁棒性设计确保了服务能适应不同插件或工具的调用方式。统一的RGB转换PIL库打开的图片可能有多种模式如RGBA, L等。将其统一转换为RGB模式可以避免因图片格式问题导致的识别错误。错误处理与日志完善的try...except块和日志记录对于调试在BurpSuite中出现的“识别失败”问题至关重要。通过查看服务端日志能快速定位是图片传输问题、解码问题还是ddddocr自身识别问题。健康检查接口(/health)这是一个好习惯。在浏览器中访问http://127.0.0.1:6000/health可以快速确认服务是否已成功启动。4.3 启动与测试服务在终端中进入ocr_server.py所在目录运行python ocr_server.py如果看到输出* Running on http://0.0.0.0:6000/和ddddocr 识别器初始化成功说明服务启动成功。你可以使用curl或 Postman 进行快速测试# 假设有一张验证码图片 code.png base64_str$(base64 -i code.png | tr -d \n) curl -X POST http://127.0.0.1:6000/ocr \ -H Content-Type: application/json \ -d {\image\: \$base64_str\}如果返回{code:5JgX,success:true}之类的JSON恭喜你服务端搭建成功。5. BurpSuite插件配置与联动实战服务端就绪后接下来就是在BurpSuite中配置captcha-killer-modified插件让它与我们的识别服务联动。5.1 插件界面概览与基本配置安装好插件后在BurpSuite顶部标签页会多出一个Captcha Killer。界面功能区Request用于配置如何从目标HTTP请求中“获取”验证码图片。Image显示当前获取到的验证码图片。Result显示识别服务返回的结果。Configuration核心配置区用于设置识别接口我们的Flask服务。配置识别接口切换到Configuration标签页。在Interface下拉菜单旁点击Add新增一个接口。URL填写我们的服务地址http://127.0.0.1:6000/ocr。Content-Type选择application/json。Post Data这里需要配置请求体。我们的服务期望一个JSON包含image字段。图片数据需要从HTTP请求中动态提取。配置如下{image: “[pic_base64]”}这里的[pic_base64]是一个占位符插件会自动用实际获取到的Base64图片数据替换它。Result Parsing这里告诉插件如何从服务返回的JSON中提取识别出的文本。我们的服务返回格式是{code: “识别结果”, ...}。因此配置Prefix为code: Suffix为。插件会截取这两个字符串之间的内容作为结果。5.2 实战案例配置一个登录爆破场景假设我们目标登录接口为POST /login请求参数为usernameadminpassword123456captcha???验证码图片由GET /captcha.php返回。步骤一获取验证码图片请求浏览器访问登录页BurpSuite开启代理拦截。找到浏览器加载验证码的请求通常是GET /captcha.php或类似将其发送到Captcha Killer插件界面。可以直接在Proxy history里右键该请求选择Send to Captcha Killer。步骤二配置图片获取规则在插件的Request标签页你会看到刚才发送的请求。点击Get按钮插件会执行这个请求并在Image区域显示获取到的图片。关键步骤我们需要告诉插件后续每次识别时都要重新执行这个GET请求来获取新的验证码。在Request区域确保选中的是我们刚发送的请求这表示将其作为“图片获取模板”。步骤三测试识别接口确保Python服务端正在运行。在Captcha Killer界面点击Get获取一张新图片然后点击识别按钮。观察Result区域。如果配置正确这里会显示从我们Flask服务返回的识别结果。重要调试如果识别失败查看Python服务端的终端输出日志这里会有详细的错误信息是排查问题的关键。步骤四集成到Intruder进行爆破这是最终目的。我们想爆破密码但每次请求都需要新的验证码。拦截一个完整的登录请求包含用户名、密码和验证码发送到Intruder模块。在Positions标签页清除所有自动标记然后手动标记你想要爆破的参数比如password。最关键的一步在Payloads标签页找到最下方的Payload Processing区域。点击Add-Invoke Burp Extension。在弹出的扩展选择器中选择Captcha Killer。这会打开一个配置窗口。你需要在这里配置“如何将识别出的验证码填入到HTTP请求中”。首先在Request部分你需要指定“从哪里获取验证码图片”。这通常就是我们在Captcha Killer主界面配置好的那个GET /captcha.php请求模板。插件会记住这个配置。然后在Response部分你需要配置“如何从识别结果中提取验证码文本”。这通常就是我们在Configuration里配置的结果解析规则Prefix/Suffix插件也会自动应用。最后在Update Request部分你需要指定“将提取到的文本替换原始请求中的哪个部分”。你需要指定一个参数名如captcha或一个自定义的字符串位置通过Add定义范围。通常我们会选择Update parameter然后输入参数名captcha。配置完成后回到Intruder的Payloads标签页你会看到添加了一条处理规则。这意味着Intruder在发送每一个Payload即每一个密码尝试之前都会先执行以下流程 a. 调用Captcha Killer插件。 b. 插件执行配置的GET /captcha.php请求获取一张全新的验证码图片。 c. 将图片发送到我们的http://127.0.0.1:6000/ocr服务进行识别。 d. 从返回结果中提取验证码文本。 e. 用这个文本替换原始攻击请求中的captcha参数值。 f. 发送修改后的登录请求进行爆破。至此一个全自动的、带验证码识别的爆破流程就配置完成了。点击Intruder的Start attack你将看到请求自动进行每个请求都使用了不同的验证码。6. 常见问题、排查技巧与优化实录在实际集成和使用过程中你几乎一定会遇到各种问题。下面是我踩过坑后总结的排查清单和优化建议。6.1 识别服务端常见问题问题现象可能原因排查步骤与解决方案服务启动失败提示端口占用端口6000被其他程序占用netstat -ano | findstr :6000(Win) 或lsof -i:6000(Mac/Linux) 查找并终止占用进程或修改app.run(port新的端口)。插件点击“识别”后Result报错或为空1. 服务未启动或网络不通。2. 接口URL或Post Data配置错误。3. 图片数据格式插件未正确提取。1. 浏览器访问http://127.0.0.1:6000/health确认服务存活。2. 在插件Configuration中检查URL和Post Data格式确保与服务器代码一致。特别注意JSON格式和引号。3. 查看Python服务端日志看是否收到请求以及错误信息。在插件Image标签页尝试将图片以Base64形式复制出来用curl手动测试接口。服务端日志显示图片解码失败插件发送的图片数据格式不符合预期。在Flask服务的handle_ocr函数开头添加logger.info(request.headers)和logger.info(request.data[:200])打印原始请求信息查看插件到底发送了什么。根据实际情况调整decode_image函数。识别率突然下降1. 验证码类型变化如中文、算式。2. 图片有严重干扰线、扭曲。3. ddddocr模型对该类型不擅长。1. ddddocr对纯数字字母验证码效果最好。如果是算式验证码需要先进行图像预处理如二值化、去噪或使用其他专门模型。2. 考虑在服务端添加预处理逻辑使用Pillow进行灰度化、二值化、降噪。3. 可以尝试ddddocr.DdddOcr(betaTrue)使用测试版模型或寻找更专门的OCR库。6.2 BurpSuite插件配置常见问题问题现象可能原因排查步骤与解决方案Intruder攻击时每个请求的验证码都一样插件配置的“获取验证码图片”的请求没有真正被执行或者该请求本身不返回新图片。1. 在Captcha Killer主界面确认Request里选中的是获取验证码的请求如GET /captcha.php而不是登录请求。2. 单独在Captcha Killer里多次点击Get观察图片是否变化。如果不变化说明目标服务器可能在会话Session/Cookie未变时返回相同图片。需要检查获取验证码的请求是否携带了正确的会话标识如Cookie、Token并在插件中配置“每次识别时使用当前会话”。Intruder攻击请求中的验证码字段未被替换Payload Processing规则中的“Update Request”配置错误。1. 在Intruder的Payload Processing规则中双击Captcha Killer规则进行编辑。2. 在Update Request部分确认你选择的是Update parameter并正确填写了参数名如captcha且该参数名与原始请求中的参数名完全一致包括大小写。3. 可以先用Repeater模块测试在Repeater中右键也有Extensions-Captcha Killer-Send to Intruder with Captcha的选项从这里生成的Intruder攻击模板其Payload Processing规则通常是预配好的成功率更高。插件界面点击“识别”正常但集成到Intruder后失败Intruder的Payload Processing是在每个Payload发送前动态执行的环境可能与插件主界面静态测试时不同。1. 检查Intruder攻击的“Resource Pool”设置是否限制了线程数或添加了延迟过快的请求可能导致目标服务器反爬或会话失效。2. 在Captcha Killer的Configuration-Request配置中确保勾选了Use current session或正确配置了会话处理如自动更新Cookie。这能保证Intruder在每次获取验证码时使用的是最新的会话状态。6.3 性能与稳定性优化心得服务端性能Flask默认是单线程同步的。当Intruder并发线程数很高时识别服务可能成为瓶颈。可以通过app.run(threadedTrue)启用多线程或者使用生产级WSGI服务器如gunicorn来部署服务。pip install gunicorn gunicorn -w 4 -b 0.0.0.0:6000 ocr_server:app-w 4表示启动4个 worker 进程并发处理能力更强。识别缓存对于某些系统同一个会话短时间内验证码可能不变。可以在服务端添加一个简单的缓存如使用functools.lru_cache以图片数据的MD5值为键避免对完全相同的图片进行重复识别减少计算开销。错误重试与降级在Intruder的Payload Processing中可以配置多条规则。例如第一条规则调用Captcha Killer如果识别失败返回空则触发第二条规则使用一个固定的错误值或手动输入。这可以防止因偶发识别失败导致整个攻击停止。验证码类型判断更高级的用法是在服务端对图片进行简单分析如颜色分布、尺寸、轮廓先判断验证码类型再决定调用哪个识别模型ddddocr用于字符其他模型用于算式实现更通用的识别服务。这个从零搭建的BurpSuite集成ddddocr的方案虽然需要一些配置步骤但它给了你完全的控制权和透明度。你清楚地知道图片如何流转、文本如何识别、请求如何被修改。这种掌控感在面对复杂多变的实际测试环境时比任何黑盒工具都来得可靠。