# Adaptive Percentage-Based Search: Finding ID Ranges Without Getting Blocked

### DISCLAIMER

This was done during a test when I asked myself, is there a smarter way to go about executing it

### The Problem

During a test, I discovered that user ID `16000` exists on a web application. But I needed to answer two critical questions:

1. **What's the lower bound?** Where do valid IDs start? 1? 5000? 12000?
2. **What's the upper bound?** Where do they end? 20000? 50000? 100000?

I had one valid ID and needed to find the complete range with:

* **Minimal total requests** (more stealth)
* **Even fewer 404 errors** (WAFs detect and block repeated failures and risk of getting noticed)

**The Challenge:** Modern sites use Web Application Firewalls (WAFs) that block IPs showing automated scanning behavior. Too many 404 errors in a row = instant block.

### The Solution

This algorithm finds both the lowest and highest valid IDs from a single known ID, while staying under WAF detection thresholds.

**Core Concept:** Adjust your search step size based on what you find:

* Find a valid ID (200)? Take **bigger steps** (go faster)
* Hit an invalid ID (404)? Take **smaller steps** and **backtrack** to safety

Think of it like exploring a dark hallway:

1. You know one door opens (your starting ID)
2. Step back 10% of your position
3. Try that door:
   * Opens? Great! Try a bigger step (20%) next time
   * Locked? Go back to the last open door, try a smaller step (5%)
4. Repeat until you find the edges

**Key Formula:** `step_size = percentage × current_id`

### Why Traditional Algorithms Fail

**Linear Search** (`16000, 15999, 15998...`)

* Hundreds of thousands of requests
* Guaranteed block

**Binary Search** (split range in half each time)

* Very fast in theory
* Can generate 10+ consecutive 404s
* **42% block rate** in testing

**Exponential Search** (double distance: `+1, +2, +4, +8...`)

* Overshoots boundaries
* **12% block rate** in testing

None of these were designed with WAF detection in mind.

### How It Works

#### Step-by-Step Rules

```
Starting percentage: 10%
On success (200): Double percentage (max 50%)
On failure (404): Halve percentage (min 0.05%) + wait before next try

Formula: step = percentage × current_id
```

#### Example: Finding Bounds from ID 16000

**Lower Bound (searching backwards):**

```
Start: 16000, step = 10%
→ 14400 ✓ (double to 20%)
→ 11520 ✓ (double to 40%)
→ 6912  ✗ (backtrack, halve to 20%)
→ 9216  ✗ (backtrack, halve to 10%)
→ 10368 ✗ (backtrack, halve to 5%)
→ 10944 ✓ Lower bound found!
```

**Upper Bound (searching forwards):**

```
Start: 16000, step = 10%
→ 17600 ✓ (double to 20%)
→ 21120 ✓ (double to 40%)
→ 29568 ✗ (backtrack, halve to 20%)
→ 25344 ✗ (backtrack, halve to 10%)
→ 23232 ✓ Upper bound found!
```

**Result:** Found both boundaries in \~12 requests with minimal 404s

### Testing Results

We tested against a simulated WAF that blocks after **7 consecutive 404s**.

**Test Setup:**

* 200,000 ID range
* 5 different data densities (20%-99% valid IDs)
* 25 runs per scenario = 125 total trials

**Ban Rates:**

* **Adaptive Percentage:** 0% (0 out of 125 trials blocked)
* **Binary Search:** 42% (53 trials blocked)
* **Exponential Search:** 12% (15 trials blocked)

### Performance

For a 200,000 ID range:

* **Linear Search:** \~200,000 requests
* **Binary Search:** \~17 requests (but high block risk)
* **Adaptive Percentage:** \~8-12 requests (zero blocks)

**95% fewer requests than linear search, with built-in stealth.**

### How It Stays Undetected

1. **Success Bias** - Actively seeks valid IDs, avoids 404 clusters
2. **Backtracking** - Never keeps probing into invalid regions
3. **Variable Steps** - Unpredictable pattern breaks detection heuristics
4. **Exponential Delays** - Waits 1s, 2s, 4s, 8s after consecutive failures

### Implementation Details

**Backtracking:**

* Saves last valid ID position
* Returns there after any 404
* Prevents getting lost in invalid ranges

**Fine-Tuning:**

* At minimum step size (0.05%), switches to precise sequential search
* Confirms exact boundary within ±0.1% of candidate

**Timing:**

* Delays increase with consecutive 404s
* Resets on success
* Mimics human browsing

### When to Use This

**Perfect for:**

* Single IP testing (no proxy pool available)
* Production systems with active WAFs
* Unknown ID ranges
* Time-limited engagements

**Real Constraints It Handles:**

* No IP rotation
* Live WAF monitoring
* Limited time

### The Bottom Line

This algorithm trades a tiny bit of theoretical speed for **massive practical stealth**.

* **Efficiency:** Near O(log n) with small boundary refinement
* **Safety:** 0% observed block rate across 125 trials

When WAFs are in play and you can't rotate IPs, this is the right tool. Standard textbook algorithms will get you blocked.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.wehost.co.in/blog/adaptive-percentage-based-search-finding-id-ranges-without-getting-blocked.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.