Intruder payload processing and grep-match/grep-extract

Payload processing: an optional case rule (upper/lower) and an optional
encode rule (URL/Base64/Hex/HTML) applied to every payload line before
it's substituted into the request, cycled with 'c'/'e'. Case always
runs before encode - folding an already-encoded value would corrupt it
(e.g. uppercasing Base64 padding). Applied entirely client-side in
startIntrude() (payload_rules.go): a pure string transform with no
proxy-side state, so it needs no protocol changes and reuses the
Decoder's own urlEncodeAll.

Grep-match/grep-extract: two optional Go regexps, edited with 'm'/'v'
using the same modal edit-buffer pattern as the history list's '/'
search (enter validates-and-commits, esc reverts to the last-confirmed
pattern, an unparseable regexp is rejected with an error rather than
silently accepted). Evaluated server-side, in internal/ipc/server.go's
"intrude" handler, against each result's actual entry.ResponseRaw -
that's where the real response bytes already are, and it's how Burp's
own grep options work (matched against the real response, not a
client-refetched copy). Grep-match flags a result (new Match column);
grep-extract captures the first submatch, or the whole match if the
pattern has no capturing group (new Extract column). Both patterns are
compiled once before the attack starts and apply for that run only, not
retroactively if changed mid-attack.

All four new keys (c/e/m/v) are gated to normal mode, checked in the
view's outer key switch before ever reaching the template/payloads
vi-textareas - otherwise they'd be either untypeable letters or steal
keystrokes mid-edit. Same discipline as the Repeater tab keys.

internal/ipc: Request gained GrepMatch/GrepExtract string fields (for
"intrude"), IntrudeResultMsg gained GrepMatch bool/GrepExtract string,
and the client Intrude() helper takes the two pattern strings as new
trailing parameters.

Verified live in tmux against a running daemon and real httpbin.org
traffic: built a template with a §marked§ query param, payloads 1/2/3,
grep-match `"id": "2"` and grep-extract `"id": "([0-9]+)"`, ran the
attack and confirmed the Match column flagged only the payload=2 row
and Extract correctly pulled 1/2/3 from each response respectively;
cycled case/encode through all states; confirmed an invalid regexp
(`[abc`) is rejected with a visible error and esc correctly reverts to
the last-confirmed pattern instead of committing the invalid one.

(Also confirmed, incidentally: a batch of vi normal-mode two-key
commands like "gg"/"dd" sent as one multi-character tmux send-keys
argument doesn't reliably reach the app as separate keystrokes - a
tmux scripting artifact, not a bug in the vi-mode implementation, which
works correctly when each key is sent as its own event, as any real
keypress would be.)

go build/vet/gofmt/test/mod tidy all clean.

1 files changed, 24 insertions, 4 deletions

diff --git a/PLAN.md b/PLAN.md
index 2dac629..d874f69 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -124,10 +124,30 @@ the correct tab (send results carry the tab index they belong to), and
 the status line/response pane it's shown in only updates live if that
 tab is still the one on screen.
 
-Still open from "worth considering": Intruder payload processing
-(encoding/case rules) and grep-match/grep-extract on results, CA install
-UX per OS, multiple proxy listeners and upstream proxy chaining. None of
-these are started yet.
+Shipped since: Intruder payload processing and grep-match/grep-extract.
+Payload processing - an optional case rule (upper/lower) and an optional
+encode rule (URL/Base64/Hex/HTML), cycled with `c`/`e` - is applied
+client-side to each payload line before it ever crosses the IPC socket,
+case first then encode (encoding an already-case-folded value is safe;
+the reverse would corrupt e.g. Base64 padding), since it's a pure string
+transform with no proxy-side state involved and reuses the Decoder's own
+`urlEncodeAll`. Grep-match/grep-extract are optional Go regexps
+(`m`/`v` to edit, both gated to normal mode and both revert-on-esc /
+validate-on-enter the same way the history list's `/` search box
+works), evaluated server-side in `internal/ipc/server.go`'s "intrude"
+handler against each result's actual response bytes - chosen over a
+client-side implementation because the daemon already has `entry.
+ResponseRaw` in hand right where the result is built, and Burp's own
+grep options work the same way (matched against the real response, not
+a client-refetched copy). Grep-match flags a result (shown as a Match
+column); grep-extract captures the first submatch (or the whole match
+if the pattern has no capturing group) into an Extract column. Both are
+configured once before `ctrl+r` starts an attack and apply for that run
+only - matching Burp, which doesn't retroactively re-grep already-fired
+requests if you change the options mid-attack.
+
+Still open from "worth considering": CA install UX per OS, multiple
+proxy listeners and upstream proxy chaining. Neither is started yet.
 
 Skipped deliberately (from the research, matches this tool's stated
 scope): active/passive vulnerability scanning, plugin marketplace,