UEFI Resident Motion Detection

Patent #08 covers a firmware-resident UEFI DXE driver that establishes a cryptographic baseline map of firmware state during the pre-boot phase — before the operating system loads. The baseline captures physical machine states directly from CPU and platform architecture registers, SMI timing durations, and execution frequencies. When a monitored firmware configuration structure deviates from baseline, the module intercepts the event vector and executes an autonomous containment protocol entirely within the firmware layer, without requiring the operating system.

The distinction is in the response architecture. Patent #08 covers firmware-resident containment — the response stays inside the firmware layer. Detection triggers a boot abort or a TPM forensic write, all before the OS bootloader executes. Patent #10 covers cross-layer detection communication — the DXE driver and SMM handler detect anomalies and communicate them via a named UEFI runtime variable to an OS-layer Rust agent, which seals the evidence to the PQC audit chain. Two different response approaches from the same detection layer. The attorney has confirmed these are two separate patent filings.

When a firmware implant is detected, two response paths are possible. The first is to communicate the detection upward to the OS layer for logging and response — Patent #10 covers this. The second is to abort the boot sequence immediately within the firmware layer, before the OS loads and potentially before a sophisticated implant can take further action. Patent #08 covers this second path. The response never reaches the OS, the implant cannot observe or interfere with the containment action, and the forensic evidence is committed to the TPM before any subsequent boot phase executes.

The DXE baseline is established first — before any OS code runs, the module interrogates hardware registers, measures SMI timing, and compiles a firmware-resident baseline map cached in protected volatile memory. The interception mechanism then monitors for deviations: any event vector attempting to modify a monitored firmware configuration structure is caught, its proposed state change is calculated against the baseline, and if the deviation exceeds the threshold, the containment protocol fires.

The monitored structures include volatile and non-volatile UEFI runtime variable namespaces, unmapped regions of ACPI system description tables (DSDT, SSDT, MADT), and System Management Mode code execution vector redirect targets. These are the specific structures that firmware implants modify to establish persistence or extend their control over the boot process.

The priority date is September 8, 2026, established by public disclosure of the claim language on the MDRwatchdog published claims page, corroborated by the PQC-sealed MDRwatchdog audit ledger (Block #1, 24,432 records, sealed September 7, 2026) and timestamped GitHub commits.