# Polymorphic Defense — Two Layers

Polymorphism in PDHPI operates at two layers. They are independent
engines with different targets, but they share a primitive: change the
shape while preserving behavior.

## Layer 1 — Wrapper morphing (transport)

The console rotates the shape of its own packets on a fixed schedule.
The current envelope has four components:

| Component | Values | Effect |
|---|---|---|
| Padding bucket | 512, 768, 1024, 1280, 1500, 2048 | Response sizes bucket differently |
| Framing | length-prefix, delimiter, chunked | Byte-level parse of the stream changes |
| Header order | canonical, shuffled, lexical, reverse | Metadata order changes |
| Envelope ID | A–F | Combined fingerprint of the above |

Envelope rotation happens every 8 seconds by default.

## Layer 2 — Rule morphing (application)

The polymorphic signature engine rewrites detection rules while
preserving their behavior. The four rewrite styles are:

    # 1. plain literal
    /(OR|AND)\s+\d+\s*=\s*\d+/i

    # 2. string concatenation
    reg('(OR|AND' + ')\s+\d+\s*=\s*\d+')

    # 3. hex-escaped
    "\x28\x4f\x52\x7c\x41\x4e\x44\x29..."

    # 4. closure-wrapped
    fn() => /(OR|AND)\s+\d+\s*=\s*\d+/

All four catch the same attacks. All four compile to the same behavior.
No two look alike to a scanner reading the source.

## What this does not do

- It does not make the console uncrackable
- It does not replace encryption or authentication
- It does not stop an attacker who is already inside the perimeter

It raises the cost of attacking the console's own defensive layer.