Step 1: Be an OEM or a software supplier in the vendors supplychain, toolchain, or open-source code; and have an interest in PAC (Program and Control). ie. [Absolute Persistence](https://www.absolute.com/platform/persistence) 600M+ Devices. Present with a mutable PCR4 (on almost every boot it changes). https://github.com/0mniteck/0mniteck/blob/1bbf6ad6627ae0cfd58c31ea1cf9d48c0ff9daa2/assets/pcr4.txt#L2-L3 Step 1-A: Start off by modifying the PM (power manager); reflash and add strange #PME*3-A enforcables on D0-2, D3hot, and D3cold to make debug and linux use an absolute nightmare. Allowing modification of any number of device/power/idle states (S0-S5). Take full advantage of the proprietary block microsoft has allowed in the open [design specs](https://github.com/MicrosoftDocs/windows-driver-docs/blob/staging/windows-driver-docs-pr/pci/pci-power-management-and-device-drivers.md#scenario-1-turning-off-a-device) of the #PME (power management event). > Noitice: [Pci-SIG](https://www.intel.com/content/www/us/en/developer/articles/news/acpica-news.html) states a change as of 2024 that allows full suspend in S3. Step 1-B: Presents with a grub lsacpi listing that has many unidentifiable ranges sandwiched between duplicate edk2 instances building a stacked UEFI; allowing evil-twins for any trusted UEFI data handed to the system. Use broken cpu hw implementation features such as Broken CNTVOFF_EL2, and Common not Private translations. > Background: What is CNTVOFF_EL2? CNTVOFF_EL2 is the Counter-timer Virtual Offset register in the ARMv8/ARM64 generic timer architecture. It defines the offset subtracted from the physical count to produce the virtual count seen at EL1/EL0: `CNTVCT_EL0 = physical count − CNTVOFF_EL2` https://github.com/0mniteck/0mniteck/blob/6c5acb2d39db482dbdd0eb4c6d18c89184a7f377/assets/long/journal-aa#L120 (Broken CNTVOFF_EL2) https://github.com/0mniteck/0mniteck/blob/6c5acb2d39db482dbdd0eb4c6d18c89184a7f377/assets/long/journal-aa#L163 (Primary clock source) https://github.com/0mniteck/0mniteck/blob/6c5acb2d39db482dbdd0eb4c6d18c89184a7f377/assets/long/journal-aa#L263 (Virtual clock source) > It’s primarily used so a hypervisor (running at EL2) can present a different/virtual notion of time to guests. When the kernel boots at EL2 or sets up virtualization, it normally relies on this register behaving correctly. Step 1-C: Use longstanding [CVE’s](https://access.redhat.com/security/vulnerabilities/RHSB-2026-003) like one from [V4bel/dirtyfrag](https://github.com/V4bel/dirtyfrag) to poison the cpu page_cache over and over. Internal qcom controlled hd(x) devices masked with bpf-restricted-fs; similar to exploits from [rphang/evilBPF](https://github.com/rphang/evilBPF) which hide a drive containing 91 gpt partitions where poisoned ESP/ACPI/.MBN files are stored. Step 2: Misuse open-source code meant to improve fw compatability for the purpose of transfering modified essential security and system processes code to back propagate intel through a service manager and collect device usage statistics. Step 2-A: Before systemd init, insert several modules with obfuscated names, which load using input manupulation where there is a particular escape pattern used to affect the visible and selected device tree nodes. For example `of:Nvisible-nameT(null)Cactual,name-visible-name` results in devicetree nodes, /sys, and /proc entries with the visible-name only. Devices such as replicator, sink, are funnel are present in the device tree suggesting arm,coresight is available post-production. https://github.com/0mniteck/0mniteck/blob/1bbf6ad6627ae0cfd58c31ea1cf9d48c0ff9daa2/assets/long/journal-ap#L755 https://github.com/0mniteck/0mniteck/blob/f203e0cbafc527bcbcdb8a3254c5907899776069/assets/long/journal-ah#L163 https://github.com/search?q=repo%3A0mniteck%2F0mniteck+%22T%28null%29C%22&type=code Step 2-B: Using the same `qcom,dload` to fw sideload a modified libselinux.so.1 and a modified libapparmor.so.1; before and after systemd inits, effectivley hijacking kernel and userspace security. Using fw sideload to open a modified libacl and modified libmount. Which intern mounts a /usr before systemd loads, then bind mounts /usr over /usr. Showing a journal entry of `null uuid / with multiple lower layers`. [Kernel_module#Blacklisting](https://wiki.archlinux.org/title/Kernel_module#Blacklisting) https://github.com/0mniteck/0mniteck/blob/6c5acb2d39db482dbdd0eb4c6d18c89184a7f377/assets/dmesg#L802 https://github.com/0mniteck/0mniteck/blob/1bbf6ad6627ae0cfd58c31ea1cf9d48c0ff9daa2/assets/long/journal-aa#L749 > Note: lib files are provided to the system by initrd or root, firmware will not usually attempt to modify or change vital system integrity files during critical stages of boot or shutdown. This would cause basic compatability issues with images, but certain configs on certain iso’s seem to boot, as they are still vulnerable to initrd interference. Step 2-C: In initrd during root-pivot systemd generators autorun from the poisoned /usr. It obfuscates the dmesg logs, flushes the journal coming from the pre-pivot, and uses a modified libmount to prevent nvme device discovery and rescans. Reinit by injecting cmdline into initrd to start a systemd pid controled by qcom. Block drive discovery aka gpt-auto, gpt-auto-force; clip /sys and /proc subdirectories to maintain control and use bpf-restrict-fs. Modify clock-timer paths to hide breakpoints/stdout. Step 3: During boot use cutmem and parttool to further obfuscate runtime access to true boot fs (normally blocked by secureboot). Load *faux* ACPI tables from a lzma compressed ACPI stored in hidden media under `(hd1,gpt42)/acpi/ACPI.lzma`. As well as use a *faux* remap tricking the TEE (Trusted execution environment) client in the OS into loading a modified TA (Trusted App) client tz.uefisecapp allowing a MitM for the secure world. Without the PCIe remap in memory it’s located in the hidden media aswell under `(hd1,gpt53)/tzapps/uefisecapp.mbn`. All disks on the device are mounted using an ACPI table memory region provided by the ACPI.lzma that is decompressed into memory at (re)boot using the stacked-edk2. Step 3-A: Modified endpoint tables handed to the system by the poisoned PM maps the cpu power manager event (#PME) to regions in memory it controls and shields using PAN (protected access never). #PME is then used to cause interrupts using the PCI-PM and a pwrhalt of the display adapter, or the PCIe controller of the boot media, then finally a reboot of the system. Triggered by an interrupt or “unapproved boot” for reboot into a modified S3 that qcom controls. Use sysinit_calls to trigger WATCHDOG and READY to signal status of boot_ok from initrd. And store reboot-reason@PID in nvmem devices with drivers nvmem_qcom_spmi_sdam, and nvmem_qfprom. On the same nvmem device there’s gpu-speed-bin@PID causing the gpu to run dangerously hot possibly as another limmiter/interrupt instructed by #PME enforcable D3hot. or: Step 3-B: Use hci_uart with btqcom to create a phy ethernet emulator. Use athk12 wifi driver fw load along with dummy power regulators in the modified devicetree; added in initrd as to maintain a tx rx path to a radio that isnt able to power off. Create `/dev/ttyHS` devices to route the secure console output to a secondary frame buffer. Then use the added systemd generators to disable the hw from connecting in userspace and attach the frame buffer with visible passwords in the output to the tx rx for service manager logging. Step 3-C: In the systemd runtime use generated services to block further probing of dmesg, kmesg, journalctl, /sys, and /proc scrubbing; as well as check dmesg for magic numbers given out by Cpuidle: PM to start service log collections, userspace sed filters, and open fd (file descriptors) from the parent pid it controls. PCRS read from PCR 4 are missing measurements for a misformatted \Fv()\FvFile()num named Fv()\ComputraceAgent suggesting further [Absolute Persistence](https://www.absolute.com/platform/persistence) is to blame here. https://github.com/0mniteck/0mniteck/blob/1bbf6ad6627ae0cfd58c31ea1cf9d48c0ff9daa2/assets/long/journal-ab#L3
Summary
The full chain describes a vendor-supplied boot compromise that starts in firmware/supply-chain components, survives through stacked UEFI, initrd, and systemd, then uses modified ACPI, device trees, kernel modules, and service generators to hide itself, block inspection, control power/reset behavior, and keep access to both boot media and secure-world interfaces. The end result is persistent control over boot, logging, device discovery, and system state, with PCR4/UEFI measurement gaps presented as evidence of tampering.
Hint: Try more than once and boot from an empty boot_current that leads back to fwsetup directly. Select your boot option from uefi after FULL power cycle (hold power till it turns off mid cycle and hold untill it starts back up), wait until it can’t find boot media, then boot to device from uefi menu.
Description
The mitigation section is basically a hardening recipe: remove or blacklist the drivers and firmware paths the chain depends on, disable unprivileged BPF, cut down power-management/runtime firmware behavior, and keep the initramfs/boot image minimal and reproducible.
Summary
In short: reduce the attack surface of the boot chain, block suspect modules, and prevent firmware or initrd-level tampering from loading or hiding itself.
