BruteForceAI：用 LLM 识别登录表单选择器，再交给 Playwright 跑撞库

它真正省掉的是选择器维护，不是防护对抗

传统撞库脚本最烦的部分不是发请求，而是找输入框。目标站点换个前端框架、把 input 的 id 从 user 改成 login-email，脚本就废了，得重新打开开发者工具抄一遍选择器。BruteForceAI 把这一步交给 LLM：给它一段 HTML，让它输出用户名框、密码框和提交按钮的选择器。README 把整个流程拆成两个阶段，Stage 1 是 AI Analysis，Stage 2 是 Smart Attack，两个阶段对应两个子命令 analyze 和 attack。

目标用户写得很明确：渗透测试和 bug bounty。README 的 About 段落自称是 penetration testing tool，topics 里同时挂了 bruteforce 和 bugbounty。这意味着它假设使用者已经有授权，工具本身不提供任何授权判断或范围限制。如果你的场景是红队演练里快速摸一遍登录口，它的定位是对的；如果你想要的是一个能自动绕防护的通用爆破器，它不解决这个问题。

两阶段数据流：HTML 进模型，选择器进 SQLite，Playwright 再读出来

从 README 能确认的机制是这样的。analyze 阶段抓取目标页面的 HTML，做一次 smart HTML content extraction，然后把内容送给 LLM，让它给出登录表单元素和对应的选择器。README 提到 automatic retry with feedback learning，也就是第一次识别失败或验证不通过时，会把反馈再喂回去重试。识别结果落到本地 SQLite 数据库里，attack 阶段从这里读选择器，用 Playwright 驱动 Chromium 实际填写并提交。

LLM 有两个 provider。Ollama 跑在本地，README 给的默认模型是 llama3.2:3b，也列了 llama3.2:1b 和 qwen2.5:3b。Groq 是云端，默认模型写的是 llama-3.3-70b-versatile，README 标注为 Best，并说明它 1 attempt 就能成。同一份文档里 llama-3.1-8b-instant 被标了 Not recommended，理由是 rate limiting issues，需要 3+ attempts。这段模型对照表是 README 里信息密度最高的部分，也是唯一带性能倾向的描述，但它没有给出任何测试条件。

成功判定这一环值得单独看。README 写的是 DOM change detection for success validation，即提交后比对页面结构变化来判断是否登录成功。这是一个脆弱的信号：SPA 里一个 toast 提示、一次路由跳转、甚至加载动画的挂载卸载都可能触发 DOM 变化。文档没有说明它如何区分成功跳转和失败提示，这一块在采用前必须自己验证。

装起来要几步：venv、Playwright 的 Chromium、外加一个模型后端

依赖很薄。README 要求 Python 3.8 以上，pip install -r requirements.txt，然后单独跑 playwright install chromium 把浏览器装下来。requirements.txt 里被点名的包只有三个：playwright、requests、PyYAML，其中 PyYAML 是给更新检查用的。

README 建议先建虚拟环境，命令是 python -m venv .venv，激活方式分平台：Windows PowerShell 用 .venv\Scripts\Activate.ps1，cmd 用 .venv\Scripts\activate.bat，macOS 和 Linux 用 source .venv/bin/activate。文档特别注明建环境只需一次，但每个新终端都要重新激活。

模型后端二选一。本地路线是 curl -fsSL https://ollama.ai/install.sh | sh 装 Ollama，然后 ollama pull llama3.2:3b。云端路线去 Groq Console 拿 key，在命令行里传 --llm-provider groq --llm-api-key YOUR_KEY。两条路线的差别不只是速度：走 Groq 意味着把目标页面的 HTML 内容发到第三方服务，走 Ollama 则全部留在本机。做授权测试时这个区别经常决定能不能用。

analyze 和 attack 的具体参数

命令结构是 python BruteForceAI.py <command> [options]，四个子命令分别是 analyze、attack、clean-db 和 check-updates。

识别阶段最小用法是 python BruteForceAI.py analyze --urls urls.txt --llm-provider ollama。要指定本地模型就加 --llm-model llama3.2:3b。README 给的完整示例是 python BruteForceAI.py analyze --urls targets.txt --llm-provider ollama --llm-model llama3.2:3b。

攻击阶段必须给三个文件：--urls、--usernames、--passwords。README 的进阶示例把参数铺得很开：--mode passwordspray 切到密码喷洒模式，--threads 15 控制并发，--delay 10 和 --jitter 3 控制节奏，--success-exit 表示拿到第一组有效凭证就退出，--user-agents user_agents.txt 指定 UA 轮换池，--verbose 打开详细输出，--output results.txt 把结果落盘。

两种攻击模式的差别在遍历顺序。bruteforce 是把用户名和密码的组合全试一遍，passwordspray 是用同一个密码去撞所有用户名。后者在真实环境里更常见，因为很多站点按账号锁定而不按 IP 锁定，同一密码横扫可以避开单个账号的失败计数。README 还提到 synchronized delays between attempts for same user，也就是针对同一用户名的尝试之间有同步延迟，这个设计和喷洒模式是配套的。

运维侧的参数包括代理支持、浏览器可见性控制、实时 webhook 通知（Discord、Slack、Teams、Telegram）以及基于 SQLite 的完整日志。README 里 --discord-webhoo 那一行被截断了，参数名不完整，实际拼写需要看源码确认。

它绕不过验证码和 MFA，README 也没打算绕

最硬的限制是能力边界。整份 README 没有出现验证码识别、MFA 绕过、WAF 指纹对抗或账号锁定规避的任何描述。它列出的规避手段只有三样：随机 User-Agent 轮换、带 jitter 的延迟、代理支持。这些都是降低请求特征的手段，属于节奏控制，不是对抗检测系统。

这意味着面对带验证码或二次验证的登录页，attack 阶段大概率走不通，而且失败方式可能不明显：Playwright 提交后页面停在验证码上，DOM 确实变了，成功判定这一环怎么处理，文档没说。

第二个限制是 LLM 识别的稳定性。用 3b 级别的本地模型去解析结构复杂的登录页，输出格式错误或选择器指错元素都有可能。README 承认有 retry with feedback learning，但没给出重试上限或失败后的行为。如果 analyze 阶段对某个 URL 一直失败，数据库里会留下什么状态，文档没有交代。

第三是并发与封禁的关系。--threads 支持到 100 以上，但 --delay 和 --jitter 是按用户同步的，不同用户之间没有全局节流。高线程配合短延迟对目标站点是实打实的压力，README 只把它当作可配置项，没有给任何推荐区间。

和 Hydra 或 ffuf 相比，差别在识别环节而不是在速度

同类工具里最常见的做法是 Hydra 那种模式：用 http-post-form 这类模块，把表单的字段名和失败特征写成一行模板手工填进去。它的优势是快、无外部依赖、行为完全可预测，跑一万次请求消耗的资源可以精确估算。代价是模板要人写，页面一改就得重写。

BruteForceAI 走的是另一条路：用一次 LLM 调用换掉人工写模板这一步，代价是引入浏览器、引入模型推理、引入一个不确定的输出环节。Playwright 驱动真实 Chromium 意味着每次尝试的开销远高于裸 HTTP 请求，同样线程数下吞吐量不在一个量级。所以这两个工具不是替代关系：目标固定、表单简单、要跑大批量字典时，模板化工具更合适；目标登录页结构复杂或者经常变动、字典本身不大时，BruteForceAI 的识别环节才体现出价值。

还有一类工具是 ffuf 那种纯 HTTP 模糊测试器，它根本不理解表单，靠的是响应长度和状态码过滤。BruteForceAI 在成功判定上用的是 DOM 变化，比状态码更接近真实登录语义，但也更难调试。

许可证不是标准开源协议，更新检查会连回作者站点

GitHub 把这个仓库的许可证识别为 NOASSERTION，而 README 里的徽章写的是 Non-Commercial。这两个信号指向同一个结论：这不是 MIT 或 Apache 那类标准许可证，商用需要你自己去读仓库根目录的 LICENSE 文件确认条款。README 的 License 小节在给出的内容里被截断了，正文没有展开任何条款细节。对于要把它放进商业渗透测试交付流程的团队，这是采用前必须先解决的前置问题，而不是事后补的手续。

维护成本方面，README 里有一项 automatic update checking from mordavid.com，对应的子命令是 check-updates，PyYAML 就是为这个功能引入的依赖。也就是说工具在运行时可能会向作者站点发起检查请求。对于在隔离网络里做测试的场景，这个行为需要提前确认并可能屏蔽。

依赖面本身不大，三个 Python 包加一个 Chromium，升级压力主要来自 Playwright 的浏览器版本和 Ollama 的模型拉取。仓库没有发布任何 release，README 徽章上的 v1.0.0 是文档里唯一的版本标识，所以升级路径基本等于跟随 main 分支。clean-db 子命令用于清理数据库表，长期使用后 SQLite 会累积历史尝试记录，这个命令是配套的维护入口。

编辑结论

它适合已经拿到书面授权、且目标登录页结构经常变动、手工维护选择器成本高的渗透测试人员，也适合只想在本地用 Ollama 跑一遍表单识别、不想把 HTML 发给云端的人。不适合需要绕过验证码、MFA 或 WAF 的场景，README 完全没有提到这些能力。上手前先确认三件事：仓库根目录的 LICENSE 文件到底写了什么，因为 GitHub 识别为 NOASSERTION 而徽章写的是 Non-Commercial；Groq 那条链路会把目标 HTML 发到第三方；以及 attack 步骤在你的目标上是否真的能区分登录成功和失败，README 只提到用 DOM 变化来判断。

官方来源

1. Issues
2. MorDavid/BruteForceAI on GitHub
3. Project website
4. README