BruteForceAI：用 LLM 找登入表單選擇器，再交給多執行緒去打
Advanced LLM-powered brute-force tool combining AI intelligence with automated login attacks
秒懂
- 它是什麼？
- BruteForceAI 把登入頁暴力破解拆成兩個階段：先用 LLM 從 HTML 推斷帳號、密碼與送出按鈕的選擇器，再用 Playwright 多執行緒送出組合。本文說明它的資料流、實際指令、授權限制，以及什麼情況下它反而是錯的工具。
- 適合誰用？
- BruteForceAI 適合已經取得書面授權、需要對大量自建或客戶登入頁做密碼噴灑測試的滲透測試者，以及想研究 LLM 如何把非結構化 HTML 轉成可執行選擇器的人。不適合把它當成通用掃描器：它只處理登入表單，遇到 MFA、CAPTCHA、SSO 或前端框架動態渲染的頁面就沒有對應機制。
- 可以商用嗎？
- 請先確認。這個儲存庫使用的授權不在我們自動分類的範圍內，商用前請閱讀儲存庫中的 LICENSE 檔案。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 60 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是選擇器維護，不是密碼猜測本身
傳統登入暴力破解工具要求使用者先手工找出表單的 CSS 選擇器或欄位名稱，再寫進設定。目標頁面改版一次，設定就失效。BruteForceAI 把這一步交給 LLM：README 描述 Stage 1 由模型讀取 HTML 內容，判斷哪個元素是使用者名稱欄位、哪個是密碼欄位、哪個是送出按鈕。Stage 2 才拿這些選擇器去跑攻擊。
這個定位決定了它的適用對象。它服務的是手上有一批登入頁、欄位命名各異、又不值得逐頁人工分析的人。README 的 topics 列出 bugbounty 與 loginpages，說明作者預設的使用場景是漏洞賞金與滲透測試。對於只有一兩個固定目標、選擇器早已寫死的情況，導入 LLM 分析反而增加依賴與成本。
兩階段資料流：HTML 進、選擇器出、Playwright 執行
從 README 的指令結構可以看出，analyze 與 attack 是兩個獨立子命令，中間靠 SQLite 資料庫銜接。analyze 讀取 --urls 指向的檔案，抓取頁面 HTML，送給 LLM 供應商，取得選擇器後寫入資料庫。attack 再從資料庫讀出這些選擇器，用 Playwright 開啟瀏覽器、填入帳密、送出表單。
README 提到「Automatic retry with feedback learning」與「DOM change detection for success validation」。前者指分析失敗時會帶回饋重試，後者指登入後比對 DOM 變化來判斷是否成功，而不是只看 HTTP 狀態碼。這對前端以 JavaScript 更新畫面的登入頁是必要的，因為表單送出後狀態碼可能仍是 200。
攻擊階段的執行模型是多執行緒加上同步延遲。README 寫明「Synchronized delays between attempts for same user」，意思是同一帳號的連續嘗試之間會等待，避免同一帳號被連續觸發而觸發鎖定。這個設計承認了暴力破解的核心限制：真正的瓶頸不是請求速度，而是目標的防護策略。
從安裝到送出第一輪嘗試的實際指令
README 給的安裝路徑是先建虛擬環境，再安裝依賴與瀏覽器。
python -m venv .venv source .venv/bin/activate pip install -r requirements.txt playwright install chromium
依賴清單列出 playwright、requests、PyYAML。LLM 供應商有兩條路。本機用 Ollama：
curl -fsSL https://ollama.ai/install.sh | sh ollama pull llama3.2:3b
雲端用 Groq，需要 API key。README 的範例把 key 直接寫在命令列上：
python BruteForceAI.py analyze --urls targets.txt --llm-provider groq --llm-model llama-3.3-70b-versatile --llm-api-key YOUR_KEY
把 API key 放在命令列會被寫進 shell 歷史紀錄，這是操作上的實際風險，README 沒有提供環境變數或設定檔的替代路徑。
分析完成後執行攻擊：
python BruteForceAI.py attack --urls targets.txt --usernames users.txt --passwords passwords.txt --mode passwordspray --threads 15 --delay 10 --jitter 3 --success-exit --verbose --output results.txt
可辨識的參數包括 --mode（bruteforce 或 passwordspray）、--threads、--delay、--jitter、--success-exit、--user-agents、--verbose、--output，以及 Discord、Slack、Teams、Telegram 的 webhook 通知。另有 clean-db 與 check-updates 兩個維運子命令。
模型選擇的取捨：本機慢但可控，雲端快但把 HTML 送出去
README 對模型的建議相當具體。Ollama 端預設 llama3.2:3b，另列 llama3.2:1b 與 qwen2.5:3b。Groq 端預設 llama-3.3-70b-versatile，並明確標註 llama-3.1-8b-instant「Not recommended」，理由是 rate limiting issues，需要 3 次以上嘗試。這是少見的坦白，等於承認雲端免費或低階層的速率限制會讓分析階段反覆重試。
真正的取捨在資料流向。用 Groq 意味著目標頁面的 HTML 會離開你的機器，送到第三方。對客戶網站的滲透測試而言，這可能違反委託合約或資料處理條款。Ollama 在本機推論，HTML 不出網，代價是需要足夠的硬體跑模型，且 3B 等級模型對複雜表單的判斷品質不如 70B。README 用「Best quality」與「Fast and reliable」區分 Groq 的兩個模型，但沒有給出任何準確率數字，因此選型只能靠自行在目標表單上試跑。
自動更新檢查與 NOASSERTION 授權是兩個要先查清楚的點
README 的功能清單裡有一項「Automatic update checking from mordavid.com」，搭配 check-updates 子命令與 PyYAML 依賴。這表示工具會主動向作者網域發出請求。在隔離環境或客戶內網執行時，這個對外連線需要事先被告知或阻擋。README 沒有說明這個檢查傳送哪些資訊，也沒有提供關閉選項。
授權狀態更需要注意。repo 的 License 欄位是 NOASSERTION，代表自動化判定無法識別出標準授權條款，而 README 的徽章標示 Non-Commercial。兩者並不一致：NOASSERTION 是 GitHub 的判定結果，不是授權本身；Non-Commercial 是 README 的宣稱。商用前必須直接閱讀 repo 內的 LICENSE 檔全文，確認使用範圍、是否允許修改與再散布。這不是法律意見，只是指出文件與判定之間的落差。此外 repo 沒有檢索到任何 release，版本資訊僅見於 README 的 v1.0.0 徽章，升級路徑實際上是追 main 分支。
什麼時候它是錯的工具
第一個明確的邊界是防護機制。工具靠送出表單並比對 DOM 變化判斷成功。目標若使用 MFA、CAPTCHA、裝置指紋或 SSO 導向，帳密正確也拿不到有效工作階段，整個攻擊階段的成功判定就失去意義。README 沒有任何繞過或整合這些機制的描述。
第二個邊界是鎖定策略。--delay 與 --jitter 只能降低觸發頻率，無法避免累積失敗次數。面對嚴格鎖定政策，passwordspray 模式（每個密碼對所有帳號測一次）比 bruteforce 更合理，因為它在鎖定門檻前能覆蓋更多帳號，但這仍取決於目標的計數邏輯，README 沒有提供任何偵測鎖定的機制。
第三個邊界是規模。每個目標都要經過 LLM 分析，Groq 免費層會 rate limit，本機模型則受限於硬體。把它當成對成千上萬目標的掃描器並不現實。
替代方案是 Burp Suite Intruder 或 ffuf 這類工具。差異在於：Burp 與 ffuf 要求你事先提供欄位名稱與 payload 位置，換頁面就要重設；BruteForceAI 用 LLM 換取設定彈性，代價是多一個模型依賴、一次 HTML 外送、以及分析階段的不確定性。若目標登入頁結構穩定且數量少，傳統工具更快也更可預測。
維護成本與採用判斷
這個專案的維護成本主要來自三個外部依賴：Playwright 的瀏覽器版本、LLM 供應商的模型名稱與 API 行為、以及目標網站本身的改版。模型名稱會隨供應商淘汰而失效，README 已列出多個 Groq 模型選項並對其中一個標註不建議，說明這類變動是常態。Playwright 需要定期執行 playwright install chromium 更新瀏覽器。
repo 沒有 release，升級等同於拉取 main 分支的最新提交，沒有版本號可供回退比對。日誌寫入 SQLite，clean-db 可清理資料表，但 README 未說明 schema 是否隨版本變動。
採用判斷應該落在具體條件上：先在自己的測試環境用 Ollama 跑一次 analyze，確認 llama3.2:3b 能否正確標出目標表單的三個選擇器；再確認 repo 內 LICENSE 檔的實際條款是否允許你的使用情境；最後在目標環境確認對 mordavid.com 的連線是被允許還是必須封鎖。這三項都通過，才有理由把它放進流程。
編輯結論
BruteForceAI 適合已經取得書面授權、需要對大量自建或客戶登入頁做密碼噴灑測試的滲透測試者，以及想研究 LLM 如何把非結構化 HTML 轉成可執行選擇器的人。不適合把它當成通用掃描器：它只處理登入表單，遇到 MFA、CAPTCHA、SSO 或前端框架動態渲染的頁面就沒有對應機制。導入前先確認三件事：repo 的 LICENSE 檔實際內容與商用條款、README 提到的自動更新檢查會向 mordavid.com 發出什麼請求、以及目標環境是否允許 Playwright 啟動 Chromium。這三點沒確認前，不要把它接進正式流程。
社群筆記