From ce6ce32469da720105258cb66e0274b2b009cd1d Mon Sep 17 00:00:00 2001
From: srdusr <99972264+srdusr@users.noreply.github.com>
Date: Tue, 3 Feb 2026 00:38:00 +0200
Subject: Intruder-equivalent: Sniper attacks with § markers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Implements build-order step 7, the last (optional) item. Scoped to
Sniper only - one payload set, one §-marked position fuzzed at a time,
others held at their base value - since that covers most real Intruder
usage; battering ram / pitchfork / cluster bomb aren't implemented.
Sequential sending, capped at 1000 generated requests as a fixed safety
limit.

internal/proxy: repeat.go's Repeat() is refactored into a shared
sendRaw(..., source) primitive so Intrude can reuse the exact same
raw-byte send/record path with source="intruder" instead of
duplicating it. intrude.go adds ParseMarkers/buildRequest (marker
parsing and payload substitution, covered by intrude_test.go - this is
fiddly byte-splicing logic, worth locking down with real tests rather
than trusting it by inspection) and Intrude(), which walks positions ×
payloads calling sendRaw and streaming each result through a callback.

internal/ipc gains a dedicated streaming "intrude" connection (same
shape as Subscribe, but blocking sends rather than drop-on-slow-
consumer - each result is the attack's actual data, not a
notification). cmd/mitmux gains an Intruder view: editable request
template (ctrl+p inserts a § marker at the cursor - typing § directly
also works, ctrl+p just doesn't require a keyboard layout that can
produce it), editable payload list, and a live results table wired to
the existing detail view (selecting a row and hitting enter opens the
full request/response for that specific attack request).

Verified live against real external traffic: a Sniper attack against
httpbin.org/status/§200§ with payloads 200/404/500 produced exactly the
three corresponding real status codes back (not a canned/local result),
confirmed the three requests landed in history tagged source="intruder"
with the § markers correctly stripped from what was actually sent, and
confirmed opening a result row's full detail from the results table.

This closes out the full build order from PLAN.md (steps 1-7).
---
 PLAN.md | 11 +++++++++++
 1 file changed, 11 insertions(+)

(limited to 'PLAN.md')

diff --git a/PLAN.md b/PLAN.md
index 745511c..64d1a0d 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -63,3 +63,14 @@ 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
+  (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
+  source="repeater", rather than a separate results store.
-- 
cgit v1.2.3