From 6114567258bcad0517a0d881168711aaacdba5d5 Mon Sep 17 00:00:00 2001
From: srdusr <99972264+srdusr@users.noreply.github.com>
Date: Thu, 11 Jun 2026 00:37:00 +0200
Subject: Intruder: Battering ram, Pitchfork, and Cluster bomb attack modes
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Generalizes Intrude beyond Sniper to all four of Burp's attack modes
(proxy.AttackMode). Sniper and Battering ram only ever need one shared
payload set; Pitchfork and Cluster bomb are inherently per-position, so
they take one payload set per §marked§ position instead.

Request-set generation (intrudeValues) is pure and side-effect free,
so the total request count is validated against the existing 1000
cap before anything is dispatched - Cluster bomb's product is checked
incrementally, one payload set at a time, so a pathological product
bails out before ever trying to enumerate it. This also makes the
combinatorics unit-testable without a live target.

IntrudeResultMsg now reports Values (one substitution per marked
position, in order) instead of a single Position/Payload pair, since
three of the four modes touch multiple positions per request.

TUI: `a` cycles the attack mode. Pitchfork/Cluster bomb reuse the
existing single Payloads pane rather than a new multi-widget editor -
sets are separated by a `---` delimiter line, in position order.

Verified live against a real daemon: all four modes produce the
expected substitution values and request counts, and pitchfork
correctly rejects a payload-set count that doesn't match the
template's marked positions.
---
 PLAN.md | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

(limited to 'PLAN.md')

diff --git a/PLAN.md b/PLAN.md
index 8c86d18..87c01cf 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -65,13 +65,19 @@ hudsucker) - same problem, worth studying even though this build is Go.
   form isn't possible yet - only rewriting/removing existing ones. The
   underlying engine (rules.ApplyHeaders) already supports arbitrary
   text-block edits; it's specifically the form UI that's constrained.
-- Step 7 (Intruder-equivalent) shipped Sniper only: one payload set,
-  one §marked§ position fuzzed at a time, every other marked position
-  held at its base value - the mode that covers most real Intruder
-  usage. Battering ram / pitchfork / cluster bomb aren't implemented.
-  Sequential sending only (no concurrency), capped at 1000 generated
-  requests as a fixed safety limit against an accidental huge wordlist
-  combined with several positions. Reuses the Repeater send primitive
+- Step 7 (Intruder-equivalent) now covers all four of Burp's attack
+  modes (proxy.AttackMode: Sniper, BatteringRam, Pitchfork,
+  ClusterBomb). Sniper and BatteringRam only ever need one shared
+  payload set; Pitchfork and ClusterBomb are inherently per-position,
+  so they need one set per §marked§ position - the request-generation
+  logic (intrudeValues) is pure and side-effect free specifically so
+  the request count (positions × payloads for Sniper, a product for
+  ClusterBomb) can be validated against the 1000-request cap before
+  anything is dispatched, and so it's unit-testable without a live
+  target. The TUI reuses the single Payloads pane for per-position sets
+  too, split by a `---` delimiter line, rather than adding a
+  multi-widget payload-set editor. Sequential sending only (no
+  concurrency). Reuses the Repeater send primitive
   (proxy.Server.sendRaw) directly - an attack is just that primitive
   run in a loop with generated bytes - and results land in the same
   history table tagged source="intruder", same as Repeater's
-- 
cgit v1.2.3