> For the complete documentation index, see [llms.txt](https://docs.wehost.co.in/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.wehost.co.in/blog/adaptive-percentage-based-search-finding-id-ranges-without-getting-blocked.md).

# 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.