PDHPI: Polymorphic Dual Hyper-Predictive Infrastructure

A Portable, Single-File Defense Layer for Application Infrastructure

Version 2.0
Created by Ping192
License: MIT

See Demo

1. Abstract

PDHPI (Polymorphic Dual Hyper-Predictive Infrastructure) is a single-file, zero-dependency defense layer designed to sit in front of or inside PHP applications. It observes real inbound requests, scores them against a set of detection rules, maintains rolling reputation and rate state, issues enforceable challenges when warranted, and runs a lightweight prediction engine against recent activity.

It is deliberately scoped as a complementary control. It is not a Web Application Firewall (WAF), not Runtime Application Self-Protection (RASP), and not a substitute for secure coding practices. Its value is cheap, correlated, per-request signal that can be acted on without introducing a separate service, database, or complex deployment pipeline.

PDHPI can be deployed as a library call, an edge observation endpoint, or a live operator console. The same codebase supports all three modes. It is designed to be upgraded and tailored to specific environments.

2. What PDHPI Does

2.1 Request Observation and Scoring

Every observed request is normalized and evaluated against a pluggable rule set. Current rules detect:

• SQL injection tautologies

• Secret and sensitive file probes (.env, .git, backups)

• Legacy scanner paths (/wp-admin, /xmlrpc.php, etc.)

• Webshell upload attempts

• Path traversal patterns

• Admin and staging path probes

• Elevated and flood-level request rates

• Hostile or watched reputation scores

• Multi-hit sessions

Each matching rule contributes a score. The aggregate score maps to one of three actions:

2.2 Rate Limiting

Per-IP request timestamps are kept in a bounded rolling window (default 60 seconds). Thresholds distinguish elevated traffic from flood behavior and feed into the scoring engine.

2.3 Reputation

Reputation is tracked at two levels:

• Fine-grained key — combination of IP and client fingerprint (session or derived identity). This drives scoring.

• Coarse IP key — tracks overall activity from an address for NAT risk assessment.

Scores increase on hostile events and decay on clean traffic. A NAT dampener detects when a single IP presents many distinct clients and can downgrade a would-be block to a challenge, reducing collateral damage on shared addresses.

2.4 Session Correlation

When a session identifier is supplied by the application, PDHPI tracks scored hits against it. When none is supplied, a stable fingerprint is derived from IP and User-Agent using an HMAC keyed by a local secret. This enables correlation even without application-managed sessions.

2.5 Enforced Challenge (Proof-of-Work)

When the verdict is challenge, PDHPI issues an HMAC-signed challenge containing a nonce, difficulty, timestamp, and signature. A self-contained HTML page runs a short client-side proof-of-work. On successful verification the session is granted a temporary pass. This is not a full CAPTCHA system; it is a low-cost gate against automated clients.

2.6 Wrapper Morphing

On a configurable interval the system rotates a "wrapper envelope" (padding, framing style, header order). The current envelope is emitted as response headers (X-PDHPI-*) so an edge layer can read and act on it. Behavior remains consistent; the observable shape of responses changes.

2.7 Adversarial Prediction

A set of lightweight hypothesis models runs against a rolling event window. Models include secret-file ladders, recon-to-exploit escalation, credential bursts, sequential ID walks, multi-region coordination, reputation-based re-attack, and session velocity.

Each model carries a calibration weight that drifts based on hit/miss outcomes. Low-performing models are automatically down-weighted. Predictions are standing hypotheses, not high-confidence blocking decisions.

2.8 State and Storage

State is kept in a single JSON document (or Redis key). Both backends support atomic read-modify-write:

• File backend — exclusive lock around mutate

• Redis backend — WATCH / MULTI / EXEC with retry

Optional MaxMind GeoLite2 support improves country attribution; a static prefix table is used as fallback.

2.9 Operator Surface

• Library mode — pdhpi_observe([...]) returns a verdict

• Edge mode — ?pdhpi=observe and ?pdhpi=envelope for JSON integration

• Console mode — live view of events, scores, reputation, predictions, and morph log

• CLI — tick, events, morph, predict, reputation, compact, vacuum, geoip install

The console does not invent traffic. If nothing is observing requests, it reports an empty state.

3. What PDHPI Does Not Do

PDHPI is intentionally limited. Clarity about boundaries is part of the design.

Treating PDHPI as a complete security stack would be incorrect. Treating it as a low-friction, high-signal first layer is correct.

4. How It Enhances Infrastructure

4.1 Immediate, Local Decisioning

Most organizations route security decisions through external services or batch pipelines. PDHPI evaluates each request in-process (or via a lightweight edge call) and returns an actionable verdict in the same request cycle. Latency impact is minimal; dependency surface is near zero.

4.2 Correlation Without a Data Platform

Rate, reputation, and session state are maintained locally. This produces multi-request context that simple per-request filters lack, without requiring a data warehouse, stream processor, or external threat-intel feed.

4.3 Graduated Response

Three outcomes—allow, challenge, block—support proportional control. Challenge reduces the cost of false positives relative to hard blocks, especially on shared or carrier-grade NAT addresses.

4.4 Edge-Readable State

Wrapper headers and the envelope endpoint allow CDNs, reverse proxies, or Workers to align response shaping or routing with the current defensive posture without embedding business logic in the edge.

4.5 Operational Visibility

The console and CLI expose the same state the library writes. Operators can see what was scored, why, and what the prediction engine currently expects—without a separate observability stack for this layer.

4.6 Deployability

A single PHP file with write access to a storage directory is sufficient. No Composer, no database schema, no message broker. This makes it suitable for constrained environments, rapid pilots, and systems where introducing new infrastructure is costly.

5. Use Cases

5.1 Small and Mid-Size PHP Applications

Drop pdhpi_observe() near the front of the request lifecycle. Block or challenge high-score traffic before it reaches application logic. Suitable for custom apps, internal tools, and modest public sites.

5.2 Edge / Auth-Request Integration

Point Nginx auth_request, Caddy forward auth, or a similar mechanism at ?pdhpi=observe. The edge receives a status code and JSON verdict; the application remains unchanged.

5.3 Complementary Layer Beside an Existing WAF

Use PDHPI for application-specific signals (session behavior, local reputation, custom paths) while the WAF handles broad protocol and known-bad-IP coverage. The two controls are additive, not competitive.

5.4 Pilot and Proof-of-Concept

Because deployment cost is low, teams can instrument a single service, observe real traffic, and decide whether deeper investment (managed WAF rules, RASP, or custom detection) is justified.

5.5 Hardened Demo and Reference Architecture

The dual-engine design (wrapper morphing + calibrated prediction) serves as a concrete reference for discussing proactive defense patterns with stakeholders, without requiring a full commercial stack.

5.6 Multi-Environment Tailoring

Rules, thresholds, challenge difficulty, storage backend, and GeoIP source can be adjusted per environment. The same core can protect a public API, an admin panel, or an internal registry with different policies.

6. Integration Patterns

Library (In-Process)

require_once 'index.php';

$v = pdhpi_observe([
    'ip'      => $_SERVER['REMOTE_ADDR'] ?? '',
    'method'  => $_SERVER['REQUEST_METHOD'] ?? 'GET',
    'path'    => parse_url($_SERVER['REQUEST_URI'] ?? '/', PHP_URL_PATH),
    'query'   => $_SERVER['QUERY_STRING'] ?? '',
    'body'    => file_get_contents('php://input'),
    'session' => $_COOKIE['session'] ?? null,
]);

switch ($v['action']) {
    case 'block':
        http_response_code(403);
        exit;
    case 'challenge':
        pdhpi_render_challenge($v['challenge']);
        exit;
}

Edge Observation

• GET/POST ?pdhpi=observe → JSON verdict + appropriate status code

• GET ?pdhpi=envelope → current wrapper state

• GET ?pdhpi=challenge → proof-of-work gate and verification

Operator Console

Visit the file in a browser. Empty state means no traffic is being observed yet—not that the system is fabricating events.

CLI

Operational commands for tick, event tail, reputation, prediction view, compaction, and GeoIP installation.

7. Upgrade and Tailoring Path

PDHPI is designed to be extended rather than replaced.

Ping192 can deliver tailored deployments: rule calibration against real traffic, Redis-backed multi-instance setups, integration with existing WAFs and log pipelines, and environment-specific policy packs.

8. Design Principles

• Honesty of scope — Complementary signal, not a full security platform.

• Zero mandatory infrastructure — PHP 7.4+ and local write access are enough to start.

• Real traffic only — The console and engines do not invent events.

• Graduated response — Allow, challenge, block.

• Correlation over isolation — Rate, reputation, and session context improve decisions.

• Atomic state updates — Concurrent requests do not silently drop updates.

• Calibrated prediction — Models that fail to predict are automatically de-emphasized.

• Edge visibility — Defensive state is readable by upstream layers without tight coupling.

9. Summary

PDHPI provides a portable, single-file defense layer that scores real requests, correlates them across rate, reputation, and session dimensions, enforces challenges when appropriate, rotates a lightweight transport envelope, and maintains a calibrated set of short-horizon attack hypotheses.

It enhances infrastructure by delivering immediate, local, low-dependency security signal and graduated controls. It does not replace WAFs, RASP, secure development practices, or incident response tooling.

Created by Ping192 ping192.sbs, PDHPI is intended to be deployed as-is for straightforward environments and upgraded or tailored for systems that require tighter policy, different storage, or deeper integration with existing security stacks.

PDHPI v2 — Polymorphic Dual Hyper-Predictive Infrastructure
© Ping192 · MIT License

#PDHPI #PolymorphicDualHyperPredictiveInfrastructure #PHPSecurity #DefenseLayer #SingleFileSecurity #ZeroDependency #RequestScoring #RateLimiting #ReputationTracking #SessionCorrelation #ProofOfWork #ChallengeResponse #WrapperMorphing #AdversarialPrediction #AtomicState #RedisBackend #FileBackend #GeoLite2 #MaxMind #SQLInjection #PathTraversal #WebshellDetection #AdminProbe #NATDampener #HMACSigned #ClientSidePoW #EdgeReadable #XPDHPIHeaders #OperatorConsole #CLICommands #DetectionRules #ThresholdTuning #StorageAbstraction #SessionFingerprinting #CalibratedModels #HypothesisModels #ReconToExploit #CredentialBursts #SequentialIDWalks #MultiRegionCoordination #ReputationReAttack #SessionVelocity #GraduatedResponse #ComplementarySecurity #WAFAlternative #RASPAlternative #SecureCoding #IncidentResponse #Ping192 #MITLicense