Burp Suite captcha-killer插件实战：自动化破解带验证码登录接口

1. 项目概述：当验证码遇上自动化

在Web安全测试，尤其是渗透测试的授权范围内，一个经典的场景就是登录接口的暴力破解。但现代应用为了安全，几乎无一例外地加上了验证码这道防线。传统的Intruder模块在这里就卡壳了，因为它无法处理每次请求都需要变化的验证码参数。这就是我们今天要深入探讨的captcha-killer插件存在的意义。它不是一个独立的验证码识别工具，而是一座桥梁，将Burp Suite强大的自动化攻击引擎（Intruder）与后端灵活的验证码识别服务（可以是任何OCR接口、打码平台或自定义脚本）连接起来，实现了对带验证码防护接口的自动化测试。

captcha-killer 0.1.2版本是一个在安全圈内流传甚广的插件，它解决了测试人员手动刷新、识别、填入验证码的痛点，将“爆破”流程重新变得自动化。简单来说，它的工作流是：Burp Suite拦截到登录请求 -> captcha-killer插件自动向配置好的识别接口发送验证码图片请求 -> 获取识别结果 -> 将结果自动填充回原始请求的对应参数中 -> 最后由Intruder完成密码字典的遍历。整个过程，测试者只需要配置好一次，后续的“识别-替换-重放”全部由工具链自动完成。

这篇文章，我将以一个拥有多年实战经验的测试者角度，为你拆解captcha-killer 0.1.2从环境搭建、插件配置、到实战爆破的全流程。我会重点分享那些官方文档里不会写的细节、配置过程中容易踩的坑，以及如何根据不同的验证码类型调整策略。无论你是刚开始接触Web安全测试的新手，还是想优化自己自动化流程的老手，这篇“保姆级”解析都能给你带来可直接复现的参考价值。

2. 核心工具链搭建与环境准备

工欲善其事，必先利其器。使用captcha-killer，你需要搭建一个由三部分组成的工具链：Burp Suite主体、captcha-killer插件本身，以及一个后端验证码识别服务。每一环的稳定都至关重要。

2.1 Burp Suite与captcha-killer插件安装

首先，确保你有一个可用的Burp Suite Professional版本或社区版。captcha-killer是一个Java编写的插件，以Jar包形式分发。你需要从可靠的来源（如GitHub仓库）下载captcha-killer-0.1.2.jar文件。在Burp Suite中，安装路径是：Extender->Extensions->Add-> 在Extension type下拉菜单中选择Java-> 然后浏览并选中你下载的Jar包文件。

注意：Burp Suite的版本兼容性是需要留意的第一个坑。较新版本的Burp Suite（如2024.x）可能对旧版Java插件存在兼容性问题。如果加载失败，可以尝试在Burp的启动参数中调整Java兼容性设置，或者寻找社区维护的修改版（如captcha-killer-modified）。我个人的经验是，对于这类核心工具链插件，在测试环境或虚拟机中固定一个稳定的Burp Suite版本（例如2022.3或2023.9）是一个省心的选择。

加载成功后，你会在Burp的标签页中看到一个新的Captcha Killer选项卡。点开它，界面相对简洁，主要包含验证码请求的显示区、识别结果区以及关键的配置面板。

2.2 验证码识别后端服务部署

这是整个流程的技术核心，也是灵活性最大的部分。captcha-killer插件本身不识别验证码，它只负责将验证码图片（通过HTTP请求获取）转发给你配置的识别接口，并接收返回的文本结果。因此，你需要自建或使用一个识别服务。

方案一：使用本地Python脚本（ddddocr方案）这是目前最流行且免费的开源方案，基于深度学习库ddddocr。你需要一个Python环境（建议3.7-3.9，避开3.10+可能存在的兼容性问题）。

1. 准备识别脚本：你需要一个能启动HTTP服务的Python脚本。网络上常见的captcha-killer-modified项目会提供一个api.py脚本。其核心逻辑是：接收一个POST请求，请求体中包含验证码图片的Base64编码数据，然后调用ddddocr库进行识别，并将结果以JSON格式返回（如{"code": "200", "message": "xxxx"}）。
2. 安装依赖：在命令行执行pip install ddddocr aiohttp。ddddocr是识别核心，aiohttp用于构建异步HTTP服务器，提升并发处理能力。
3. 运行服务：在脚本目录下执行python api.py。脚本通常会监听本地的8888端口。此时，你的识别服务接口地址就是http://127.0.0.1:8888。

实操心得：这个脚本默认可能只针对4位数字字母验证码优化。如果你的目标验证码是6位、包含中文或复杂干扰线，你需要修改脚本中的识别逻辑。例如，在ddddocr初始化时传入参数show_ad=False可以关闭广告检测（这是一个常见误区，它其实是用于检测特定类型广告的，并非广告），更重要的是调整classification或detect方法的参数。这部分需要一定的Python和OCR知识，也是从“能用”到“好用”的关键。

方案二：使用商业打码平台API对于难以用开源库识别的复杂验证码（如滑块、点选、空间推理等），可以接入打码平台。这些平台提供HTTP API，你只需要按照其文档要求，构造一个发送图片和接收识别结果的请求模板即可。优点是识别率高、种类全，缺点是会产生费用。在captcha-killer中，你需要根据平台的API文档，精心构造Request template。

方案三：自定义识别接口如果你有更特定的需求，比如识别内部系统自定义的验证码，可以用任何你熟悉的语言（Python、Java、Go等）编写一个识别服务，只要保证其HTTP接口的输入输出格式能被captcha-killer适配即可。这提供了最大的灵活性。

2.3 环境连通性测试

部署好识别服务后，首要任务是测试整个链路的连通性。打开Burp Suite的浏览器代理，访问一个带有验证码的测试页面（例如DVWA、Pikachu靶场）。拦截浏览器获取验证码图片的HTTP请求（通常是一个GET请求到类似/captcha.php的地址）。

将这个请求包（Raw格式整个请求）发送到captcha-killer插件：在Burp的Proxy -> Intercept或History中找到该请求，右键 ->Send to Captcha Killer。此时，请求内容会出现在插件的请求框中。

1. 获取验证码：点击插件界面的获取按钮。如果配置正确，右侧的图片预览区域应该能显示出验证码图片。如果这里失败，通常是请求包本身有问题（如需要特定Cookie或Header），或者网络不通。你需要检查原始请求是否完整，特别是Host、Cookie等头部信息。
2. 配置识别接口：在识别接口URL中填入你的后端服务地址，如http://127.0.0.1:8888。
3. 配置请求模板：这是最关键的一步。点击请求模板，你需要根据后端服务要求的格式，重写发送给识别接口的请求。例如，对于上述的ddddocr脚本，它期望一个JSON body，里面包含图片的Base64数据。你需要在模板中，用占位符<@IMG_RAW></@IMG_RAW>或<@IMG_B64></@IMG_B64>来代表从原始验证码请求中提取的图片数据。一个典型的模板如下：

   POST / HTTP/1.1 Host: 127.0.0.1:8888 Content-Type: application/json {"image": "<@IMG_B64></@IMG_B64>"}

4. 配置响应解析：在结果提取部分，你需要告诉插件如何从识别接口的返回包中提取出验证码文本。如果接口返回{"code": "200", "message": "5g7y"}，那么你可以使用正则表达式或JSON路径来提取。例如，使用正则表达式："message":\s*"(\w+)"。配置好后，点击识别按钮，下方的结果框应该就能显示出识别出的验证码文本了。

走到这一步，意味着你的captcha-killer插件已经能够独立完成“获取图片->发送识别->解析结果”的单个循环。这是后续自动化爆破的基础。

3. 插件核心配置与爆破流程详解

当验证码识别链路打通后，我们就可以将其融入到Burp Suite Intruder的自动化攻击流程中。这个过程需要精细的配置，一步错可能导致整个攻击失败。

3.1 爆破场景分析与参数定位

我们以最常见的“用户名固定，密码字典爆破，且每次请求需携带新验证码”的场景为例。假设登录请求如下：

POST /login.php HTTP/1.1 Host: target.com Content-Type: application/x-www-form-urlencoded username=admin&password=§123456§&vcode=§abcd§

这里，password和vcode是变量。vcode的值需要每次请求前动态获取并识别。

首先，你需要确定验证码的获取请求。通常是一个独立的GET请求，比如GET /captcha.php?r=0.123456789。关键点在于：这个获取验证码的请求，往往与登录请求共享会话状态（通过Cookie中的Session ID关联）。这意味着，在爆破过程中，每次发起登录尝试前，都必须先使用同一个会话去获取一个新的验证码，然后用这个新验证码去组合登录请求。

3.2 Intruder与captcha-killer的联动配置

这是整个教程最核心的部分，我将分步骤拆解：

步骤1：发送登录请求到Intruder在Burp Suite中，拦截或从历史记录中找到目标登录请求，右键 ->Send to Intruder。

步骤2：设置攻击类型与攻击点在Intruder的Positions标签页：

• 攻击类型选择Pitchfork（草叉模式）：这是必须的。因为我们需要同步遍历两个不同的Payload集合：密码字典（Payload set 1）和验证码（Payload set 2）。Pitchfork模式会将两个集合的项一一对应组合。
• 清除默认标记：点击Clear §。
• 标记变量：在请求体中，将password的值标记为Payload 1（如password=§123456§），将vcode的值标记为Payload 2（如vcode=§abcd§）。注意，username如果不是变量就不要标记。

步骤3：配置Payload集合切换到Payloads标签页：

• Payload set 1：这是你的密码字典。选择Simple list，然后加载你的密码文本文件。
• Payload set 2：这是动态验证码的来源。这里必须选择Extension-generated。在下拉菜单中，选择captcha-killer。这意味着，Intruder在发起每一次请求时，都会向captcha-killer插件请求一个新的验证码值来填充vcode参数。

步骤4：激活并配置captcha-killer插件回到Captcha Killer标签页，确保界面上的是否使用复选框被勾选。这表示插件已处于待命状态，准备响应Intruder的验证码生成请求。

现在需要进行流程绑定：

1. 在插件界面，找到验证码数据包区域。将之前我们测试成功的那个“获取验证码图片的HTTP请求”（GET /captcha.php）的原始数据，完整地粘贴或通过Send to Captcha Killer加载进来。
2. 确保识别接口URL和请求模板配置正确，并且点击识别能正常返回结果。
3. 至关重要的一步：Cookie同步。在插件界面，通常有一个Cookie from request的按钮或选项。点击它，它会自动从你加载的“验证码数据包”中提取Cookie。你必须确保这个Cookie与后续Intruder发起登录请求时使用的Cookie是一致的。因为服务器需要通过Cookie来关联“发出的验证码”和“验证的验证码”。一种稳妥的做法是，在Intruder的Resource Pool设置中，将线程(Number of threads)设置为1，并勾选Use the same cookie for all requests（在Intruder的Options标签页->Request Headers部分可以添加或确保Cookie头存在）。这样可以避免因并发导致的会话混乱。

步骤5：设置资源池与线程在Intruder的Resource Pool标签页，创建一个新的资源池，并将Number of threads设置为1。这是另一个关键点。因为如果使用多线程并发，线程A获取的验证码，可能会被线程B的登录请求使用，而服务器端会话中存储的验证码是线程A的，这会导致验证码不匹配而失败。单线程虽然慢，但保证了请求的串行和会话一致性。

3.3 启动攻击与结果分析

所有配置完成后，回到Intruder的Start attack按钮，点击开始。你会看到攻击窗口弹出，Intruder开始工作。

观察攻击过程：

• 对于每一次攻击尝试，Intruder会先“悄无声息”地触发captcha-killer插件的工作流程：插件使用配置的Cookie去请求一个新的验证码图片，发送到识别接口，得到文本结果。
• 然后，Intruder将这个识别结果作为Payload set 2，与你密码字典中的当前项（Payload set 1）组合，构造出完整的登录请求并发送。
• 在攻击结果表格中，你会看到Payload1是密码，Payload2是动态生成的验证码。

你需要根据HTTP状态码、响应长度、返回内容等信息来判断哪些请求可能成功了（例如，状态码302重定向到登录后首页，或返回了“登录成功”的JSON标志）。Burp Intruder的过滤器（Filter）功能可以帮助你快速定位这些异常响应。

4. 实战进阶：疑难排查与优化策略

按照上述流程操作，理论上可以完成爆破。但实战环境千变万化，下面是我总结的常见问题与进阶技巧。

4.1 常见失败原因与排查清单

问题现象	可能原因	排查步骤
插件点击获取无图片	1. 验证码请求包不完整（缺少必要Header如Cookie、Referer）。 2. 目标服务器验证码接口有额外校验（如时间戳、Token）。 3. 网络不通或目标服务不可用。	1. 在Burp Repeater中重放原始验证码请求，确认能正常返回图片。 2. 对比Repeater中成功的请求与发送到插件的请求，确保完全一致。 3. 检查插件中加载的请求包Raw格式是否完整，特别是前几行的请求行和头部。
点击识别无结果或报错	1. 识别接口URL错误或服务未启动。 2. 请求模板格式错误，不符合识别接口要求。 3. 结果提取正则表达式/JSON路径配置错误。 4. 验证码类型太复杂，识别率低。	1. 用浏览器或Postman直接测试识别接口，确认其正常工作。 2. 在插件中，使用手动请求功能（如果有）测试模板，查看原始请求和响应。 3. 检查响应提取规则，确保能匹配到返回数据中的正确字段。对于JSON，使用$.message这类JSONPath通常更可靠。 4. 尝试更换识别引擎（如用打码平台），或优化本地识别脚本参数。
Intruder攻击全部返回验证码错误	1.会话不同步：这是最常见的原因。Intruder请求的Cookie与插件获取验证码的Cookie不一致。 2.验证码一次性使用：服务器在验证一次后立即使当前验证码失效，而Intruder可能因重试等原因重复使用。 3.验证码参数名不匹配：登录请求中的验证码参数名（如vcode,captcha）与服务器预期不符。	1.确保Cookie同步：在插件和Intruder的请求头中强制使用相同的Cookie字符串。可以在Intruder的Options->Request Headers中添加Cookie: sessionid=xxx。 2.严格单线程：确保资源池线程数为1。 3. 在Repeater中手动模拟“获取验证码->立即登录”流程，确认参数名和流程无误。
识别率低下，导致爆破效率差	1. 验证码有强干扰（扭曲、粘连、背景噪声）。 2. 开源识别库（如ddddocr）未针对该类型优化。 3. 图片预处理不足。	1. 考虑使用付费打码平台，它们针对复杂验证码的识别模型更强大。 2. 修改本地识别脚本，加入图片预处理步骤，如二值化、去噪、灰度处理、字符分割等。这需要一定的图像处理知识。 3. 在captcha-killer的请求模板中，可以尝试先对Base64图片数据进行解码、处理、再编码，然后发送。但这通常需要在中间加一层代理处理服务。

4.2 性能优化与稳定性提升技巧

1. 识别服务优化：如果你的本地ddddocr脚本处理速度慢，可以考虑将其部署在性能更好的机器上，或者使用异步框架（如aiohttp, FastAPI）重写，以提高并发处理能力。虽然Intruder是单线程请求，但识别服务本身可以并行处理多个识别任务（如果未来扩展其他用途）。
2. 请求重放与去重：在真正的测试中，网络波动或服务端偶尔无响应可能导致个别请求失败。可以在Intruder攻击完成后，筛选出状态码为5xx或超时的请求，将其单独保存，然后修改captcha-killer的配置，使用一个新的会话Cookie，对这些失败请求进行重试。
3. 验证码缓存策略（谨慎使用）：对于一些简单的、非一次性验证码（虽然少见），可以尝试在本地脚本中实现简单的缓存。即对相同的图片Base64哈希值，直接返回缓存的结果，避免重复识别。但这需要你非常确定目标系统的验证码不是一次性的。
4. 结合其他Burp插件：可以结合Logger++插件，详细记录每一次请求和响应的全过程，便于事后分析哪一步出了问题。也可以使用Turbo Intruder（虽然它更复杂）来尝试实现更高效的自定义并发逻辑，但会话管理会变得极具挑战。

4.3 应对更复杂的验证码机制

• 滑块验证码：captcha-killer本身难以处理。需要更专门的工具链，通常包括：1. 获取背景图和缺口图；2. 使用图像识别算法计算缺口位置；3. 模拟滑块拖动轨迹。这个过程可能需要编写自定义的Python脚本，并通过一个中间API服务与Burp交互。captcha-killer在这里的角色可能仅限于传递图片和接收计算出的滑动距离。
• 点选验证码：识别出需要点击的文字或物体后，需要返回的是坐标信息（如x1,y1|x2,y2）。这需要你的识别后端能够输出坐标，并且登录接口可能接受坐标序列作为验证参数。你需要修改请求模板和结果提取规则来处理坐标数据。
• 短信/邮箱验证码：这通常不属于图形验证码范畴，captcha-killer不适用。这类爆破需要关注的是验证码的时效性、重放攻击和次数限制。测试重点在于逻辑漏洞，而非自动化识别。

最后，我必须强调，所有技术都应在合法授权的范围内使用。自动化安全测试工具是一把双刃剑，captcha-killer这样的插件极大地提升了安全测试人员评估验证码机制强度的效率，但同样，它也可能被滥用。理解其原理和流程，有助于我们更好地设计出能够抵御此类自动化攻击的验证码系统，这才是安全领域知识分享与进步的真正意义。在实际项目中使用时，请务必确保你拥有对目标系统进行测试的明确授权。整个配置过程看似繁琐，但一旦跑通，你就会发现它为我们打开了一扇自动化测试的新大门，尤其是面对那些自以为有验证码就高枕无忧的登录接口时。