Skip to main content
Most tools give you one knob: a fixed delay, and a hope. Evasive Mode throws that out. It watches how each host responds and adjusts in real time, speeding up when the target is healthy, backing off the instant it sees rate-limiting, blocking or strain, and doing it per host, with an optional Tor lane that rotates your exit IP so no single address ever draws attention. It is strictly additive and off by default; a project opts in.
Evasive Mode running

Evasive Mode active on an automated attack, with the live pacing state

​
The brain behind it

A fixed delay is a blunt instrument. Set it too slow and you burn the engagement window; set it too fast and you trip a WAF, collect a block, or degrade the target. Worse, a target’s tolerance is not constant, it changes with load, time of day and which endpoint you hit. One number cannot track that. Evasive Mode replaces the number with a feedback loop, the same control principle that keeps network congestion stable. For every host it:
  1. Senses the signals the target actually gives off, a sliding window of status codes, challenge pages and latency.
  2. Decides a state from those signals: healthy, straining, or blocked.
  3. Acts on the rate, climbing gently while clean, holding and switching identity while straining, and dropping hard with a cooldown when blocked.
  4. Recovers, resuming at a floor rate and ramping back only after it has seen several clean intervals in a row.
The result is that each host runs at the fastest rate it will quietly tolerate, and eases off before it trips a defence, not after. A single strict endpoint slows only itself; the rest of the surface keeps moving. This is the part we spent the most engineering on, and it is what separates “a scanner with a delay flag” from a tool that behaves like a careful human operator.

How the pacing works

The per-host sensor, the normal, throttle, blocked, cooldown, resume, parked state machine, and the additive-increase, multiplicative-decrease rate model.

Tor egress and exit rotation

How supported tools route through Tor, how the exit IP rotates on every tool, and why payload tools stay direct but still paced.

​
In recon and in attacks, one engine

Evasive Mode is not bolted onto one feature. The same core drives both halves of the platform:
  • In recon, it scales the chosen profile’s pacing down (rates and concurrency) without touching its coverage, and routes the Go HTTP tools through Tor. A deep run stays deep, it just arrives politely.
  • In automated attacks, it paces each tool against the live response of its targets, rewrites tool commands to add the right rate and proxy flags, and rotates the Tor exit between tools. Payload tools are kept direct (where Tor would break or stall them) but are still governed by the same adaptive pacing.
Turning it on is one choice at the project level; a badge shows it is active and at what intensity, and the live run surfaces the current state of each host.

​
Intensities

One setting picks how hard it pushes. Each intensity is a complete pacing profile, not just a speed dial.

Quiet

Low and slow. Starts around 1.5 req/s, ramps gently, backs off hard, cools down longer, and reaches for Tor early. For sensitive targets.

Balanced

The default. Starts around 8 req/s up to a ceiling of 30, with sensible back-off and cooldowns. The right call for most engagements.

Aggressive

Flat out. Starts around 20 req/s up to 50, tolerates more pushback before backing off, short cooldowns. For permissive targets and tight windows.

​
What it is not

  • Not a fixed delay. The rate moves with the target, continuously.
  • Not proxychains. D0pam1ne uses each tool’s native SOCKS support, because proxychains injects a library at load time that crashes some tools on Apple Silicon.
  • Not a coverage cut. Evasive Mode changes how fast and how quietly a run goes, never how much it covers.
Evasive Mode is additive and off by default. Turning it off returns every tool to normal, direct pacing. Keep it on for sensitive engagements.