# Scan Control

Burp Bounty Pro provides granular control over scan execution, including pause/resume functionality, per-scan configurable thread pools, request rate limiting, and automatic optimization features.

## 🎮 Dashboard Controls

The Dashboard tab provides the following control buttons:

| Button               | Action                                                                                                               |
| -------------------- | -------------------------------------------------------------------------------------------------------------------- |
| ⏸️ **Pause All**     | Pauses all running scan tasks. Threads block at a safe synchronization point and resume exactly where they left off. |
| ▶️ **Resume All**    | Resumes all paused tasks. All blocked threads wake up and continue scanning without losing state.                    |
| ⏹️ **Stop**          | Stops all scans and clears the task queue. Running tasks are interrupted.                                            |
| 🗑️ **Clear Issues** | Clears the issues table (does not affect Burp Suite's issue list).                                                   |

> 📝 **Note:** Pause/Resume preserves full scan state — no scan progress is lost. Tasks continue from the exact point where they were paused.

## ⏸️ Pause & Resume

Burp Bounty Pro implements true, thread-safe pause/resume using a custom **PausableThreadPoolExecutor** — a thread pool that suspends execution without destroying threads or losing state.

### 🔧 How It Works

```
                    ┌──────────────┐
                    │  Scheduler   │
                    │ (per scan)   │
                    └──────┬───────┘
                           │
              ┌────────────▼────────────┐
              │ PausableThreadPoolExecutor │
              │                            │
              │  ┌─ Thread 1 ──┐           │
              │  │ beforeExecute() ──► if isPaused:    │
              │  │                       condition.await() │
              │  │              │           │
              │  ├─ Thread 2 ──┤           │
              │  ├─ Thread 3 ──┤           │
              │  └─ Thread N ──┘           │
              └────────────────────────────┘
```

1. Each scan creates its own `Scheduler` wrapping a `PausableThreadPoolExecutor`
2. When **Pause** is activated, the executor sets `isPaused = true`
3. Each thread checks `isPaused` in `beforeExecute()` — if paused, the thread blocks on a `Condition.await()`
4. When **Resume** is activated, `isPaused` is set to `false` and `Condition.signalAll()` wakes all blocked threads
5. ✅ Threads continue execution from exactly where they paused

### ⏱️ Pause Time Tracking

Burp Bounty Pro tracks the total time each scan spends paused. This paused time is subtracted from the scan duration calculation, ensuring accurate scan time reporting in the Dashboard. If you pause a scan for 10 minutes, the reported scan time reflects only the active scanning time.

### 🌐 Individual vs. Global Pause

* ⏸️ **Pause All / Resume All** — Controls all running scans at once from the Dashboard
* Each `ScanManager` instance maintains its own independent pause state via its own `Scheduler`

## ⚡ Per-Scan Scanner Settings

Scanner settings are configured **per scan** in the URL filter popup that appears before launching each scan. This allows different scans to use different thread counts and request rates.

### 📊 Configuration Fields

| Setting                    | Description                                                                                                                               | Default |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ------- |
| 🧵 **Threads**             | Number of threads in the scan's thread pool. Each scan creates its own independent `Scheduler` with this many threads.                    | 10      |
| 🔀 **Concurrency**         | Maximum concurrent connections for the scan. Controls how many HTTP requests can be in-flight simultaneously.                             | 10      |
| 📈 **Requests per second** | Rate limit for the scan. Controls the maximum number of requests sent per second. A value of 10 means one request every 100ms per thread. | 10      |

### 🔧 How Per-Scan Settings Work

```
Scan Launch Popup (FilterURLs)
  │
  ├─ 🔗 URL selection and filtering
  ├─ 🔄 Match and Replace rules
  └─ ⚡ Scanner Settings
      ├─ Threads: [10]
      ├─ Concurrency: [10]
      └─ Requests per second: [10]
          │
          ▼
     ScanManager created with these values
          │
          ▼
     Scheduler(threads) → PausableThreadPoolExecutor
```

Each scan is independent — you can run one scan with 20 threads against a robust target and another with 2 threads against a rate-limited target, simultaneously.

### 📋 Recommended Configurations

| Scenario                    | Threads | Concurrency | RPS | Notes                                    |
| --------------------------- | ------- | ----------- | --- | ---------------------------------------- |
| 🏴‍☠️ **Bug Bounty (fast)** | 20      | 20          | 50  | Stable targets with no rate limiting     |
| 🔒 **Penetration Test**     | 10      | 10          | 10  | Balanced speed and stealth               |
| 🛡️ **Rate-Limited Target** | 3       | 3           | 2   | Avoid triggering WAF or rate limits      |
| 🏥 **Sensitive Production** | 2       | 2           | 1   | Minimal impact on live systems           |
| 🏢 **Internal Network**     | 30      | 30          | 100 | Fast scanning on internal infrastructure |

> 💡 **Tip:** If a target starts returning 429 (Too Many Requests) or dropping connections, reduce the Threads and RPS values. You can also pause the scan, wait a moment, and resume.

### 🧠 Smart Scan Default Values

When Smart Scan rules trigger active scans automatically (without a manual popup), default values of **10 threads**, **10 concurrency**, and **10 RPS** are used. These are suitable for most scenarios.

## 🎯 Stop-on-First-Match

When a payload matches for a given profile and insertion point, Burp Bounty Pro automatically stops testing remaining payloads for that same combination.

**How it works:**

1. A shared `AtomicBoolean` flag is created per (profile + insertion point) combination
2. All payloads for that combination are scheduled as parallel tasks
3. When one task finds a match, it sets the flag to `true`
4. Other tasks check the flag before executing and skip if it's already set

**Benefits:**

* ✅ Prevents duplicate issues for the same vulnerability
* ⬇️ Reduces the number of requests sent to the target
* ⚡ Improves overall scan speed

**Behavior:**

* ⚠️ Due to the parallel nature of scanning, up to 2 issues may occasionally be reported (race condition is benign)
* 🔗 Multi-step profiles have their own stop-on-match logic per step
* 🌐 Collaborator-based profiles (`{BC}`) are excluded from this optimization since detection is asynchronous

## ⏱️ Scan Timeout

Scans are monitored for timeout conditions:

* ⏱️ **Scan Timeout** — If a scan exceeds the configured time limit (configurable in Options, in minutes), it's marked as "❌ Failed"
* 🛑 **Graceful Shutdown** — The thread pool supports a 30-minute graceful shutdown timeout

## 🔄 Redirect Loop Protection

To prevent infinite redirect loops:

* 🛡️ A maximum of **30 redirects** per request chain is enforced
* 🔢 Supported redirect status codes: `300`, `301`, `302`, `303`, `307`, `308`
* 📝 Per-profile redirect limits can be set with the `MaxRedir` field

## 🔁 Duplicate Scan Avoidance

Burp Bounty Pro tracks scan combinations to avoid re-scanning:

* Each (profile + insertion point + payload) combination is tracked
* If a combination has already been scanned, it's skipped on subsequent runs
* This is particularly useful when scanning multiple pages on the same host

## 🔎 Scan Scope (Per-Host Deduplication)

Active profiles support a `scanScope` setting:

| scanScope | Mode                  | Behavior                                      |
| --------- | --------------------- | --------------------------------------------- |
| 0         | **Per-URL** (default) | Profile runs on every URL scanned             |
| 1         | **Per-Host**          | Profile runs once per `host:port` combination |

Per-host deduplication is tracked via a thread-safe Set with keys in the format `profileName:host:port`. This eliminates redundant scans for profiles that test fixed paths (directory fuzzing, CVE probes, raw requests).

See [Active Scan](https://docs.bountysecurity.ai/active-scan#-scan-scope) for details.

## 🔢 Max Concurrent Scans

Limit the total number of concurrent scans running at any time:

* Configurable in **Options** > **Max Scans**
* Prevents excessive resource consumption when scanning multiple targets simultaneously