# Index - Stages of Interception This index reorganizes the archive along a **vertical axis**: the layer of the computing and communications stack at which authority is exercised, identity is asserted, and mediation can occur. The existing indexes are keyed to entities ([[Index - People|People]], [[Index - Device Inventory|Devices]], [[Index - Technology and Product Lineage|Technology Lineage]]) or to recurrence ([[Index - Pattern Ledger|Pattern Ledger]]). Neither is keyed to *where in the stack* something happens, which is the axis along which both compromise and defense are actually structured. ## Reading rules specific to this index The word **interception** in this document names a *category of technical possibility documented in public literature*, not an established occurrence. Each stage separates five columns of claim that must never be merged: 1. **[[Resident Authority|Resident authority]]** — what entity legitimately controls state at this layer. 2. **[[Persistent Identifier|Persistent identifiers]]** — what survives a reset, migration, reinstall, or ownership change at this layer. 3. **Documented mediation modality** — how this layer is known, in published technical literature, to be observed, altered, impersonated, or bridged. This is generic, not an assertion about this archive. 4. **Evidence obtainable** — what artifact would settle a question at this layer, and from where. 5. **Archive coverage** — what the processed notebooks actually contain, with its confidence tier. A stage entry is **never** by itself evidence that interception occurred. Presence of a tool in the notebooks records study, acquisition, or experimentation. Per the vault-wide rule, page adjacency and index co-location record investigative proximity only. See [[Identifier Collision|Identifier Collision]] and [[Observability Asymmetry|Observability Asymmetry]] for the two failure modes this index is most exposed to. Coverage status: reconstructed from sixteen of approximately two hundred notebooks. Stage assignments are provisional and expected to be revised as later notebooks supply operational context the current material cannot preserve. **Stage-number rule:** these are vertical layers, not a chronological attack sequence or kill chain. A record may occupy several stages at once, skip stages, or move upward and downward over time. **Citation status:** this draft contains substantial public-literature synthesis, but many expanded technical claims do not yet carry point-of-claim citations. Until a source pass is complete, treat those passages as working technical analysis rather than independently auditable verification. --- ## Stage 0 — Physical object, label, and supply chain **Resident authority:** manufacturer, contract assembler, certifying body, and whoever last held physical custody. **Persistent identifiers:** [[Device Serial Number|serial number]], [[Federal Communications Commission Identifier|FCC ID]], [[Industry Canada Certification Number|IC number]], [[Universal Product Code|UPC]], [[Asset Barcode|asset barcode]], [[UL File Number|UL file number]], [[Printed Circuit Board Certification|PCB certification marks]], [[ANATEL|ANATEL]], [[Korea Certification|KC]], [[NOM Certification|NOM]], [[China Radio Transmission Equipment Type Approval|CMIIT]], [[CE Marking|CE]], [[Restriction of Hazardous Substances Directive|RoHS]]. **Documented mediation modality:** interdiction and implantation during shipment; relabeling; substitution of a visually identical unit; grey-market refurbishment with altered firmware. This is the layer at which the *object's* identity and the *record's* identity can diverge before any software runs. **Evidence obtainable:** photographed labels with legible identifiers, purchase and shipment records, [[Adhesive Residue|adhesive residue]] and label-tampering indicators, warranty and repair history, certification database lookups keyed to the FCC or IC grantee code. **Archive coverage:** extensive. Label harvesting is a durable notebook practice — see [[Device Label Harvesting|Device Label Harvesting]] and [[Index - Device Inventory|Index - Device Inventory]]. Includes the unresolved [[Citrine Home|CubeBlue]]-labeled object carrying `8385C2` and the truncated `KR5` FCC prefix associated with [[Continental Automotive|Continental Automotive]]. Both remain **unresolved**; the grantee-code inference is *plausible interpretation*, not verification. --- ## Stage 1 — Radio, spectrum, and access network **Resident authority:** licensed carrier, [[Mobile Virtual Network Operator|MVNO]], spectrum regulator, and the operator of whatever base station the device actually associates with. **Persistent identifiers:** [[International Mobile Equipment Identity|IMEI]], [[Integrated Circuit Card Identifier|ICCID]], [[Subscriber Identity Module|IMSI]], [[Mobile Country Code|MCC]] / [[Mobile Network Code|MNC]], [[Public Land Mobile Network|PLMN]], [[Physical Cell ID|PCI]], [[Tracking Area Code|TAC]], [[E-UTRA Absolute Radio Frequency Channel Number|EARFCN]], [[Access Point Name|APN]], [[Service Set Identifier|SSID]] and BSSID, [[Media Access Control Address|MAC]] / OUI. **Bearer technologies:** [[Long-Term Evolution|LTE]], [[LTE Band 12|band-specific allocations]], [[Time-Division Long-Term Evolution|TD-LTE]], [[Global System for Mobile Communications|GSM]], [[Voice over LTE|VoLTE]], **WiMAX (IEEE 802.16)**, [[Wireless Wide Area Network|WWAN]], [[Wi-Fi Alliance Certification|Wi-Fi]], [[Zigbee|Zigbee]], [[Bluetooth|Bluetooth]] and [[Bluetooth Network Encapsulation Protocol|BNEP]], [[Near-Field Communication|NFC]], [[Infrared Data Association|IrDA]]. > **WiMAX placement note.** WiMAX (IEEE 802.16) is an access-network radio bearer and a structural sibling of LTE, which is why it is filed at Stage 1 rather than at Stage 3. It operated principally at 2.3, 2.5, and 3.5 GHz licensed and 5.8 GHz unlicensed, straddling the [[Ultra High Frequency|UHF]] ceiling (3 GHz) and the [[Super High Frequency|SHF]] floor. **Chronological constraint:** major U.S. WiMAX networks were decommissioned in 2015–2016 (Sprint/Clearwire terminating service in late 2015), so a live WiMAX reference functions as a period anchor for [[Index - Master Chronology|Master Chronology]] rather than as a contemporaneous capability. No WiMAX notebook evidence appears in the twelve processed sources; this entry is a forward slot pending later source material and the separately noted owner-held photographs. > > **WiMAX as a firmware boot device — contested, with owner-supplied evidence pending.** The question resolves differently at two layers, and the two must be kept separate. > > *Literature finding (Stage 3, firmware-selectable boot device).* For any medium to appear in a BIOS or UEFI boot menu, the adapter must expose a pre-OS network stack — a legacy PXE option ROM, or a UEFI driver implementing the Simple Network Protocol and PXE base code. Ethernet does this universally. Wi-Fi does it rarely but genuinely: UEFI 2.5 onward added wireless supplicant and HTTP Boot capabilities, and some vendor firmwares expose wireless boot. **No vendor documentation located to date exposes a WiMAX radio as a selectable boot device**, and every Intel AMT-supported wireless adapter list found so far names Wi-Fi-only parts rather than the WiMAX combination modules (Centrino Wireless-N + WiMAX 6150, Centrino Advanced-N + WiMAX 6250). WiMAX adapters generally depended on OS-resident drivers and a connection manager, machinery that does not exist before the OS loads. > > *Owner-supplied claim (pending production).* Bryant McGill states that photographs exist of firmware exposing this capability, and that they will be produced to the archive. **This claim supersedes the literature finding if the photographs bear it out**, and it is recorded here at owner-supplied tier rather than dismissed. The literature finding above is a statement about what public documentation shows, not a determination that no such firmware shipped — OEM firmware variants, regional SKUs, and carrier-specific builds are exactly the population that vendor documentation covers least well, and a firmware exposing WiMAX as a boot device would be a **genuinely notable artifact** rather than a marginal one. > > *Resolution criteria — what the photographs need to show.* The decisive distinction is **which menu the entry appears in**. A WiMAX entry in a device-enable or radio-configuration menu is device enablement, which was common on ThinkPad, Dell, and comparable business machines of the era, and does not establish boot capability. A WiMAX entry in the **boot order, boot device list, or network-boot device selection** would establish it. Capture, where possible: the full menu with its heading and breadcrumb, the vendor and model, the BIOS or UEFI version and date string, any POST-time option ROM or UNDI banner naming the WiMAX device, the exact wording of the entry (whether it reads WiMAX, WWAN, or Wireless — these are not interchangeable), and any adjacent UEFI network-stack or PXE settings. Photograph the machine's service tag or model label in the same session so the artifact binds to a specific device in [[Index - Device Inventory|Device Inventory]]. > > *Stage 10–11 alternative, independently plausible.* A WiMAX CPE or router terminates the radio link and presents ordinary Ethernet or Wi-Fi downstream, so a machine on that LAN can PXE/BOOTP boot with the responder reachable anywhere the routed path extends, including across the WiMAX bearer. The radio is then transport *under* the bootstrap rather than the boot device itself. This remains plausible regardless of how the Stage 3 question resolves, and the two possibilities should not be conflated when the photographs are read. **Documented mediation modality:** [[International Mobile Subscriber Identity Catcher|IMSI catchers]] and downgrade-forced association; [[Signalling System No. 7|SS7]] and [[Base Station System Application Part|BSSAP]] signaling-plane abuse; SIM swap and number-porting takeover; rogue access points and evil-twin SSIDs; APN and MMS misrouting during provisioning. **Evidence obtainable:** carrier provisioning and port-out records, SIM byte-level dumps, band and cell-registration logs, [[Software-Defined Radio|SDR]] captures ([[SDRplay RSPdx|RSPdx]]), [[Kismet|Kismet]] / [[linssid|linssid]] / [[Wigle.net|Wigle]] survey data, dated BSSID observations. **Archive coverage:** substantial. Mobile reachability recovery (activation, support escalation, APN routing, MMS, number migration) is treated as a single provisioning workflow in `Scanned_20260730-1706`, pages 4–5. SIM byte and EMV tag inspection appears in `Scanned_20260730-1235`, pages 15–16 and 26–33. ### "Lock" decomposes into four unrelated mechanisms The word *lock* is used across consumer, repair, and security literature for four mechanisms that live at different layers, respond to different interventions, and require entirely different evidence. Collapsing them produces claims that cannot be tested, so the archive should never use the bare term. **1. Physical RF band support.** The front-end module, power amplifiers, duplexers, filters, and antenna tuning either pass a band or they do not. **No software operation changes this.** A handset without the hardware for a given band cannot be configured onto it. *Evidence:* teardown and component part numbers, regulatory grant filings, chipset and FEM datasheets. **2. Modem non-volatile configuration.** Qualcomm-lineage modems keep an NV item store in the EFS partition holding band-enable masks, the Preferred Roaming List, RF calibration, and feature flags. This is **software state, modifiable with the appropriate service credential**, and a QCN file is a backup of it. *Evidence:* NV item dumps, QCN backups with timestamps, service-tool logs, calibration records. **3. Subsidy or SIM lock.** A flag in protected storage, historically a writable value and on modern devices fuse-backed or gated behind a server-signed OEM unlock token. *Evidence:* carrier unlock request records, OEM unlock portal history, token issuance records. **4. Network-side authorization.** An IMEI or MEID entry in a carrier's equipment identity register, provisioning database, or blocklist. **This is not on the device at all**, and nothing done to the handset alters it. *Evidence:* carrier account and provisioning records, EIR status queries, port-out history. **The tool class that operates on layer 2.** Qualcomm's own QPST and QXDM are the vendor baseline; third-party service utilities — DFS CDMA Tool, CDMA Workshop, and comparable products — reimplement that access with a service-shop interface, and communities including XDA and its Russian-language counterpart 4PDA distributed procedures for their use. These are **legitimate repair instruments** for restoring RF calibration after board replacement or recovering a corrupted EFS, and the same access enables ESN and MEID rewriting for handset cloning, which is a serious criminal offense in the United States and elsewhere. The archive records this tool class as a *capability that exists*; possession or study of such a tool evidences neither use nor intent, and this index does not treat it otherwise. --- ## Stage 2 — Silicon, board, and low-level bus **Resident authority:** SoC vendor, board designer, and any process with debug-bus access. **Persistent identifiers:** [[System on a Chip|SoC]] part numbers, [[Apple System Coprocessor|coprocessor]] and [[System Management Controller|SMC]] identities, [[Apple Tristar|Tristar]], fuse and OTP state, board revision silkscreen. **Interfaces:** [[Serial Peripheral Interface|SPI]], [[Inter-Integrated Circuit|I2C]], [[System Management Bus|SMBus]], [[Universal Asynchronous Receiver-Transmitter|UART]], [[In-system Programming|ISP]], [[BOSSA|BOSSA]], [[Atmel SAM Microcontroller|SAM]] programming. **Documented mediation modality:** debug-port access below all OS protections; flash reprogramming via SPI clip; coprocessor firmware substitution; power and thermal side channels. **Evidence obtainable:** flash dumps with hashes, chip photography, [[PCI-Z|PCI-Z]] / [[inxi|inxi]] enumeration, vendor part lookups via [[Digi-Key Electronics|Digi-Key]] and [[Intel ARK|Intel ARK]]. **Archive coverage:** present as *hardware descent* — router administration traced downward into antennas, radio silicon, Ethernet switching, PCB provenance, and jumpers. `Scanned_20260730-1235`, pages 22 and 24–25; [[Qualcomm Atheros|Qualcomm Atheros]], [[Skyworks Solutions|Skyworks]], [[Analog Devices|Analog Devices]], [[Lite-On Technology|Lite-On]], [[Sino Wealth Electronic|Sino Wealth]]. ### Irreversible state — fuses, OTP, and storage write-protect This is the layer where **"bit-locked" and "welded" cease to be metaphors**. Everything above Stage 2 is, in principle, reversible: firmware can be reflashed, an OS reinstalled, a package removed, an account recovered. At Stage 2 a class of state exists that is **irreversible by design**, and this property is the technical core of the capture thesis. **SoC one-time-programmable fuses (eFuses).** Blown during manufacture or first provisioning, they cannot be un-blown by any software operation. They typically carry the **secure-boot public key hash** (fixing which signing authority the device will obey for its entire life), the **JTAG and debug disable** state, the **lifecycle state** advancing from development to production irreversibly, and **anti-rollback counters**. The Samsung Knox warranty bit is the widely known consumer instance. The archive's [[Factory Reset Protection|FRP]] and [[Boot Startup Security|startup security]] material sits directly above this substrate. **eMMC and UFS write-protection.** [[eMMC|eMMC]] exposes, through its extended CSD register, **permanent write protect** (irreversible once set), **power-on write protect** (reasserted every power cycle), and temporary write protect, applied at whole-device or write-protect-group granularity, with separate controls for the boot partitions. The `PARTITION_SETTING_COMPLETED` bit makes the hardware partition configuration permanent. **RPMB** uses an authentication key that is one-time programmable — once written it can never be read back or changed, so whoever programs it holds that authenticated channel permanently. UFS provides the equivalent through permanent and power-on write-protect flags at LUN granularity. **No software, jailbreak, reflash, or OS reinstall reverses a permanent write-protect bit.** **Anti-rollback is the double-edged case worth stating explicitly.** Counters in fuses or RPMB prevent installing firmware older than the recorded version. The security rationale is sound — it blocks downgrade to a known-vulnerable image. The symmetric consequence is that **it equally blocks restoring a known-good older state**, which is the archive's [[Continuity Architecture|reversibility-as-architecture]] principle being removed at the hardware level. A device that has advanced its anti-rollback counter has permanently lost a recovery path, and the mechanism cannot distinguish an owner restoring a trusted image from an attacker downgrading to exploit one. **Storage controller firmware.** eMMC, UFS, and SSD controllers run their own firmware with vendor-specific command sets that are typically undocumented and reachable through manufacturer modes. That firmware mediates every read and write, is not visible to the host, and — per the flash-translation-layer note at Stage 4 — determines what physically persists regardless of what the host believes it erased. This is a genuine supply-chain concern at the component rather than the device level. **Baseband processors.** A cellular baseband is a separate processor running its own real-time operating system, with vendor- and often carrier-signed firmware, its own memory, and on weaker designs DMA access to application-processor memory unless constrained by an [[Input-output memory management unit|IOMMU]]. The application processor generally cannot inspect, attest, or halt it. It is the clearest instance of a second execution domain welded to the same board and outside the owner's authority. --- ## Stage 3 — Pre-OS firmware, boot policy, and network boot **Resident authority:** platform firmware and whatever boot policy it enforces — the last layer at which no operating system exists to be trusted. See [[Pre-OS Trust Boundary|Pre-OS Trust Boundary]]. **Persistent identifiers:** [[NVRAM|NVRAM]] variables, [[Machine Owner Key|MOK]] enrollment, [[Trusted Platform Module|TPM]] PCR state, firmware version and build strings, [[iBoot|iBoot]] version, [[Bootloader Firmware Slot|bootloader slot]] state. **Firmware and boot entities:** [[Coreboot|Coreboot]], [[Libreboot|Libreboot]], [[SeaBIOS|SeaBIOS]], [[System76 Open Firmware|System76 Open Firmware]], [[MrChromebox Firmware Utility Script|MrChromebox]], [[Minifree|Minifree]], [[Unified Extensible Firmware Interface|UEFI]], [[BIOS|BIOS]], [[AMI Aptio|AMI Aptio]], [[American Megatrends|American Megatrends]], [[Clover EFI bootloader|Clover]], [[Ozmosis firmware|Ozmosis]], [[Acidanthera|Acidanthera]], [[FakeSMC|FakeSMC]], [[UEFITool|UEFITool]], [[MMTool|MMTool]], [[UEFI BIOS Updater|UBU]], [[CPU microcode|CPU microcode]], [[Advanced Configuration and Power Interface|ACPI]] and [[ACPI Differentiated System Description Table|DSDT]] patching, [[MaciASL|MaciASL]], [[Enhanced FAT UEFI driver|EFI FAT driver]], [[EFI Graphics Output Protocol|GOP]], [[EFI Universal Graphics Adapter|EUGA]], [[UEFI Shell|UEFI Shell]]. **Boot loaders and chainers:** [[GNU GRUB|GRUB]], [[grub.cfg|grub.cfg]], [[rEFInd|rEFInd]], [[SYSLINUX|SYSLINUX]], [[EXTLINUX|EXTLINUX]], [[PXELINUX|PXELINUX]], [[LILO|LILO]], [[GRML Rescueboot|GRML Rescueboot]], [[Initial RAM Filesystem|initramfs]], [[Linux Kernel Image|vmlinuz]]. **Network boot:** [[Preboot Execution Environment|PXE]], BOOTP, DHCP, network boot ROMs, PCI-LAN option ROMs, [[Linux Terminal Server Project|LTSP]], [[Diskless Remote Boot in Linux|DRBL]]. > **BOOTP, DHCP, and PXE — lineage and why this is the sharpest pre-OS trust boundary.** > > *Lineage.* BOOTP is the ancestor and DHCP the descendant, not the reverse. BOOTP was specified in RFC 951 (1985) explicitly to bootstrap diskless workstations; DHCP arrived in RFC 1531 (1993) and settled at RFC 2131 (1997), and it was deliberately built as a **backward-compatible superset** — same UDP ports 67 and 68, same packet layout, with BOOTP's vendor-extensions field generalized into DHCP's options field. RFC 1542 codified the interoperation, which is why a DHCP server can still serve a pure BOOTP client and why relay agents written for one work for the other. The two are best treated as one protocol family with a lease-management layer added on top. > > *Why the bootstrapping intuition is correct.* BOOTP's original design carries the boot instruction in the reply itself: `siaddr` names the server holding the boot image and the 128-byte `file` field names the image, with the transfer performed over [[Trivial File Transfer Protocol|TFTP]] — an unauthenticated, connectionless protocol chosen for the same reason as everything else at this layer, namely that it is small enough to fit in a boot ROM. DHCP carries the equivalent as option 66 (TFTP server name) and option 67 (bootfile name); DHCPv6 carries it as option 59 (bootfile URL, RFC 5970). **These fields let the responder redirect the client to an arbitrary host**, which is the technical substance behind "bootstrapping from unusual locations." > > *Two further mechanisms sharpen the point.* PXE clients announce themselves with vendor class identifier `PXEClient` (option 60) and consume vendor-specific data in option 43, which permits **ProxyDHCP**: a machine that is not the DHCP server, listening on UDP 4011, supplies the boot parameters while the real DHCP server supplies only the address. Boot direction and address assignment are therefore separable and can legitimately originate from different hosts. Separately, UEFI HTTP Boot (UEFI 2.5 onward) moved the same pattern to a URL, widening the range of sources a firmware will fetch executable code from. > > *Why it is a trust boundary rather than merely a protocol.* Neither BOOTP nor DHCP authenticates the responder in ordinary deployment. RFC 3118 defined DHCP authentication in 2001 and is effectively undeployed. The client is a machine with **no operating system, no user, no credential store, and no policy** accepting an executable image from whichever host answers a broadcast first. The mitigating control is not in the protocol at all but below it, in [[Unified Extensible Firmware Interface|UEFI]] Secure Boot and the signed-bootloader chain, and above it in switch-level DHCP snooping and port security — which is precisely why [[Coreboot|Coreboot]], [[Libreboot|Libreboot]], and firmware-password and startup-security policy sit in this same stage rather than a different one. > > Source: `Scanned_20260730-1706`, PDF pages 36–37 (PXE, BOOTP, network boot ROMs, PCI-LAN); `Scanned_20260730-1719`, PDF pages 44–57 and 67–75. ### The control-transfer chain — what "unverified stops" actually names The intuition that a specific class of *handoff points* constitutes the platform's core exposure is correct, and the technical family it names is **control-transfer points**: places where execution passes from one authority to another, historically with no verification of the destination. Enumerated in order, on a legacy x86 platform these are the reset vector and initial boot block; **POST checkpoints** (the codes emitted to port `0x80` that a POST card reads); **PCI option ROM execution**, where the firmware enumerates devices and runs code supplied by each device in ring 0 before any OS exists; **interrupt vectors**, the real-mode IVT and later the protected-mode IDT; **SMI handlers**, installed into SMRAM during POST; **ACPI method invocation**; UEFI **DXE dispatch and protocol installation**; and finally boot-device selection and bootloader handoff. Each is a "stop" in the sense the draft intends — a point where control halts, consults a table, and resumes somewhere it was told to go. **Two corrections that make the claim defensible.** *First, this is not the origin.* Stages 0 through 2 sit beneath it: supply-chain substitution, debug-bus access, and flash reprogramming all precede POST and are unconstrained by anything in this list. Firmware is where the *first software* trust decision happens, not where the trust chain starts. *Second, "unverified" is period-dependent and should be dated in any claim.* On pre-verified-boot platforms the description is broadly accurate: option ROMs ran unsigned, the IVT was writable, and nothing attested the firmware to anything. Modern platforms moved the root beneath the firmware into a separate processor — **Intel Boot Guard** (from roughly the Haswell generation, 2013) verifies the initial boot block using the Management Engine, and **AMD Platform Secure Boot** does the equivalent through the Platform Security Processor. [[Unified Extensible Firmware Interface|UEFI]] Secure Boot additionally verifies option ROMs and bootloaders, though a legacy CSM path disables that. The archive already holds the relevant artifact: the HP EliteDesk startup menu at `Scanned_20260730-1719` PDF page 37 exposes both `F3 UEFI Drivers (3rd party option ROM mgmt)` and `F4 Start Intel CIRA` — third-party pre-OS code management and Management Engine remote access presented as adjacent menu entries on one machine. **Any claim about verification status must therefore name the platform generation**, because the answer changed materially around 2013. ### ACPI as a standing firmware-to-OS channel **ACPI deserves separate treatment because it is not a handoff — it is a persistent interpreter relationship.** Every other item above transfers control once and is done. [[Advanced Configuration and Power Interface|ACPI]] instead has the firmware hand the operating system a set of tables — [[ACPI Differentiated System Description Table|DSDT]], SSDT, FADT, MADT, and others — containing **AML**, ACPI Machine Language: compiled bytecode that the OS interprets *in kernel context*, through ACPICA on Linux and the ACPI driver on Windows. AML `OperationRegion` declarations grant access to system memory, I/O ports, PCI configuration space, and SMBus. The firmware is therefore not merely initializing the machine; it is supplying a **program the kernel will keep executing for the machine's entire uptime**, on every power-state transition, thermal event, lid close, dock, and battery query. The trust relationship does not end at boot. Two consequences follow. **AML can trigger SMIs**, entering **System Management Mode** — code resident in SMRAM, installed during POST, executing at higher privilege than the kernel or hypervisor and invisible to both, conventionally described as *Ring −2*. SMRAM is protected once firmware sets the lock bit; where firmware fails to lock it, or where a handler calls out into unprotected memory, SMM becomes the deepest software persistence available on the platform. And ACPI includes at least one table whose *documented purpose* is executing firmware-supplied code inside the OS: **WPBT**, the Windows Platform Binary Table, which causes Windows to run a binary extracted from firmware at boot. It is a legitimate, vendor-used mechanism — anti-theft agents rely on it — and it has been shipped in ways that drew significant criticism. Firmware-to-OS code delivery is a *designed feature*, not only an exploit class. **The archive's own tools are the same mechanism.** [[Clover EFI bootloader|Clover]], [[Ozmosis firmware|Ozmosis]], [[MaciASL|MaciASL]], and DSDT patching — all present in `Scanned_20260730-1719` pages 44–55 for hardware-compatibility purposes — are ACPI table modification tools. Injecting a modified DSDT to make an unsupported machine boot is the *same operation* as injecting a modified DSDT for any other purpose. This is the sharpest instance in the archive of a principle already recorded in the Pattern Ledger: **capability is neutral and intent is not visible in the artifact.** Their presence in the notebooks evidences compatibility work, which is what the surrounding pages describe. ### Vendor firmware writers — Odin, and why the front end is not the authority The archive holds this directly at `Scanned_20260730-1650` PDF page 5, headed "Odin Flash software," recording the version as `Oden 3.14` and preserving the standard slot recipe: **BL** for [[Bootloader Firmware Slot|bootloader]] material, **AP** for the [[Application Processor Firmware Slot|application-processor]] system package, **CSC** for [[Consumer Software Customization|regional and carrier configuration]] with a user-data wipe, and **[[HOME_CSC|HOME_CSC]]** when preserving user data. `Oden` is the notebook's own spelling; [[Samsung Odin|Odin]] is canonical, and the variant should be preserved as written rather than silently corrected, per the archive's transcription rule. **The architectural point, which generalizes well beyond Samsung.** Odin is a **Windows front end speaking a proprietary protocol to the device's bootloader in download mode**. It transports images and issues commands. It does not grant authority. Every meaningful check happens **on the device**, in the bootloader, which is itself verified by a chain rooted in the fuses described at Stage 2: - **Signature enforcement** — a locked bootloader accepts only vendor-signed images, and that verification executes in firmware where no host-side tool can reach it. - **Anti-rollback level** — firmware below the device's recorded rollback counter is refused **unconditionally**, including on an unlocked bootloader. This is a hard constraint, not a policy setting. - **Binary revision and partition compatibility** — packages built for a different binary revision or partition layout are rejected regardless of signing. - **OEM unlock state and Knox status** — these determine what class of image the device will accept at all. **Patched flashing utilities exist and are commonly misdescribed.** Modified Odin builds circulate that disable *client-side* behaviors — package checksum validation, CSC-matching restrictions, model-string checks. These are real and they do remove friction. **They remove host-side checks only.** No host-side patch causes a locked bootloader to accept an unsigned image, because the front end is not where the decision is made. A tool described as able to "force write over any ROM no matter what" is therefore best read as describing one of: a device already OEM-unlocked, on which any Odin build works identically; an engineering or factory bootloader binary with permissive enforcement; a specific bootloader vulnerability, which would be device-and-version bound rather than a general capability; or an overstatement of ordinary flashing. **The archive's page-5 reconstruction already reaches this conclusion and should be treated as the settled reading**: real authority lies in bootloader state, signature enforcement, anti-rollback fuses, partition layout, and package compatibility — not in the executable. **The claim is decidable against a physical artifact, which is unusual and valuable.** Any write of unofficial firmware trips the **Knox warranty bit**, an eFuse, permanently. A device reading `0x0` has never accepted unofficial firmware, whatever any tool was claimed to do. A device reading `0x1` has, though the fuse identifies neither who nor when, and owner experimentation trips it identically. Combined with binary revision, anti-rollback level, bootloader version, and download-mode status lines, this converts an unverifiable capability claim into a **checkable device state** — which is the correct disposition for it. **Identifier collision warning.** [[Heimdallr|Heimdallr]] in this vault currently appears in Apple crash-log context alongside [[CrashCapture|CrashCapture]]. [[Heimdall|Heimdall]] — no trailing R — is separately the open-source cross-platform alternative to Odin for Samsung download-mode flashing. These are unrelated and must not be merged if Samsung flashing material is later expanded. See [[Identifier Collision|Identifier Collision]]. Worth recording separately because it makes three abstractions in this index concrete on ordinary business hardware. Lenovo, Dell, HP, and other OEMs embed the **Absolute persistence module** (historically Computrace) directly in platform firmware. It is the widely deployed production example of the **WPBT-class mechanism** described above: firmware-resident code that reinstalls its agent into the operating system, surviving OS reinstallation and disk replacement because it does not live on the disk. Three properties make it the reference case for this index: **It is user-visible.** Unlike SMM handlers or ME firmware, it appears in firmware setup as a named setting, so it can be inspected without special tooling. **It is irreversible in one direction by design.** The setting typically offers *Disabled*, *Enabled*, and *Permanently Disabled* — and the permanent state is one-way, matching the Stage 2 fuse and write-protect pattern. Once an activated module is disabled permanently, the state cannot be restored; once activated, it is deliberately difficult to remove. **It is the cleanest illustration of the authorization gap.** The identical mechanism serves theft recovery for an individual owner, fleet tracking for an enterprise, and — where a device leaves an organization without proper deprovisioning — **continued reporting to a prior owner's account after the device has changed hands entirely.** The firmware setting records that persistence is active. It does not record whose account receives the report, or whether the current possessor agreed to it. See [[Index - Company and Institution|Index - Company and Institution]] for the corporate lineage and the actor-class framework below for why the mechanism alone settles nothing. **Evidence obtainable:** ACPI table dumps compared against vendor reference (`acpidump`, table checksums), AML disassembly of DSDT and SSDT for unexpected `OperationRegion` scope or WPBT presence, SMRAM lock-bit state, option ROM inventory with signatures, Boot Guard and PSB fuse and policy status, TPM PCR values 0 through 7 covering firmware and option ROM measurements, and POST checkpoint traces where a card or debug header is available. **Standing caution.** Everything in this subsection describes *published platform architecture and research literature*. It establishes that these channels exist and what they are capable of. It establishes nothing whatsoever about whether any of them was used against any system in this archive, and no artifact in the processed notebooks currently speaks to that question. Per this index's reading rules, an attack-surface description is not an incident record. **Platform lock and recovery policy:** [[Boot Startup Security|Boot Startup Security]], [[macOS Startup Security Utility|Startup Security Utility]], [[macOS Firmware Password|firmware password]], [[macOS Recovery|macOS Recovery]], [[Factory Reset Protection|FRP]], [[Execute Disable Bit|NX/XD]], [[Intel Virtualization Technology for Directed I-O|VT-d]], [[Input-output memory management unit|IOMMU]], [[Extended Verification Module|EVM]]. Note that VT-d/IOMMU is itself ACPI-described, through the DMAR table — the mechanism that constrains device DMA is configured by the same firmware-supplied table set it would need to constrain. **Documented mediation modality:** firmware implants persisting across OS reinstall and disk replacement; option-ROM and DXE driver injection; rogue DHCP/PXE responder supplying a boot image; microcode and ACPI table substitution; boot-order manipulation to a controlled external device. **Evidence obtainable:** full flash image with hash compared against vendor reference, TPM event log and PCR values, NVRAM variable dump, DHCP server logs and lease records, [[FileAlyzer|FileAlyzer]] and UEFITool structural comparison. **Archive coverage:** the deepest single cluster in the processed material. `Scanned_20260730-1719`, PDF pages 44–55 and 73–75, including the page-75 Coreboot/Libreboot summary. The stated pattern — *openness, availability, and trust are different* — is the correct caution for this layer: open or downloadable firmware does not establish trustworthy provenance. --- ## Stage 4 — Embedded acquisition, storage, and forensic imaging **Resident authority:** whoever can attach to raw block devices, which is effectively whoever has physical access plus the right adapter. **Persistent identifiers:** [[GUID Partition Table|GPT]] GUIDs, filesystem UUIDs, [[eMMC|eMMC]] CID/CSD registers, [[MMC Block Device|mmcblk]] node topology, SMART attributes. **Entities:** [[U-Boot|U-Boot]], [[dd (Unix)|dd]], [[Guymager|Guymager]], [[Expert Witness Compression Format|EWF]] and [[libewf|libewf]], [[Safecopy|Safecopy]], [[Clonezilla|Clonezilla]], [[Partclone|Partclone]], [[TestDisk|TestDisk]], [[Autopsy|Autopsy]], [[The Sleuth Kit|The Sleuth Kit]], [[Scalpel|Scalpel]], [[xmount|xmount]], [[zuluMount|zuluMount]], [[Filesystem in Userspace|FUSE]], [[UDisks2|UDisks2]], [[ArchiveMount|ArchiveMount]], [[Snapper|Snapper]], [[DAR|DAR]], [[cpio|cpio]], [[Tenorshare 4DDiG|4DDiG]], [[GParted|GParted]], [[cfdisk|cfdisk]], [[ext4|ext4]], [[F2FS|F2FS]], [[Btrfs|Btrfs]], [[ZFS|ZFS]], [[exFAT|exFAT]], [[NTFS|NTFS]], [[Apple File System|APFS]], [[Universal Disk Format|UDF]]. **Documented mediation modality:** silent acquisition of an unattended device; hidden partitions and slack-space residence; firmware-level storage controller behavior invisible to the host OS; evidence alteration during non-write-blocked mounting. **Evidence obtainable:** hashed forensic images with acquisition metadata, mount and write-block logs, partition table history, deleted-record recovery with provenance. **Archive coverage:** heavy, and methodologically the strongest part of the corpus. `Scanned_20260730-1314`, pages 18–21 (raw embedded-storage imaging as a coherent U-Boot → eMMC → SSH → `dd` workflow); `Scanned_20260730-1706`, pages 10–18. Underlies the [[Continuity Architecture|reversibility-as-architecture]] pattern. ### Read-only filesystems are not the security boundary — verified boot is A recurring interpretive error worth recording formally, because it is easy to make and this index's stage discipline resolves it directly. **SquashFS on a read-only Android partition is ordinary.** [[Android Open Source Project|AOSP]] has long supported compressed read-only filesystems for `/system` and companion partitions, and the broader family — SquashFS with zlib, LZO, LZ4, XZ, or Zstd compression, and increasingly **EROFS**, which has largely displaced SquashFS on newer Android for random-read performance — exists to shrink immutable system images. Modern Android additionally uses **dynamic partitions** inside a `super` container mapped by `dm-linear`, and **APEX** modules that are loop-mounted filesystem images. Seeing compressed read-only filesystems mount during boot is therefore **consistent with an entirely stock device** and is not by itself evidence of anything. **The filesystem is Stage 4; the trust decision is at Stages 3 and 6.** Read-only-ness is a *property of the mount*, trivially defeated by remounting or by substituting the image. What actually establishes that a partition contains what the vendor shipped is **[[Android Verified Boot]] with dm-verity** — a Merkle hash tree over the partition, rooted in a `vbmeta` structure, itself verified by a bootloader chain anchored in fuses. **Compression format is irrelevant to integrity. The verification layer is everything.** Asking whether SquashFS is suspicious is asking a Stage 4 question about a Stage 3 property, and the reframing is what makes the question answerable. **Decisive, checkable state on Samsung devices.** This is one of the rare cases where the archive can obtain a hard answer rather than an impression: - **`ro.boot.verifiedbootstate`** — green means fully verified with the vendor key; yellow means verified with a user-supplied key; orange means the bootloader is unlocked and verification is off; red means verification failed. The corresponding boot-time warning screen shows the same state. - **`ro.boot.flash.locked`** and the OEM-lock and Knox status lines shown on the download-mode screen. - **The Knox warranty bit.** This is the strongest artifact available, because it is an **eFuse** — see the irreversible-state section at Stage 2. A value of `0x0` establishes that the device has never executed unofficial firmware. A value of `0x1` establishes that it has, permanently and unforgeably, though it does **not** identify who caused it or when, and owner experimentation trips it identically to anything else. - **`vbmeta` digest and AVB signature state**, and whether `vbmeta` was flashed with verification disabled. **On verbose bootloader output.** Samsung retail firmware does not normally print staged boot progress. Before treating verbosity as anomalous, exclude the mundane causes: the **SysDump service menu** (reachable via a dialer code) exposes a user-settable debug level that increases boot logging on stock firmware, and **engineering or factory bootloader binaries**, which do produce verbose output, sometimes reach retail channels or refurbished stock. A confirmed engineering bootloader on a retail device would be a genuinely notable finding; a raised debug level would not. The photographs should be read for **firmware build string, bootloader version, binary type (USER versus ENG), Knox and OEM-lock status, and verified-boot state**, all of which typically appear on the download-mode screen and settle the question far more directly than the filesystem names in the boot log. > **Resolves the notebook fragment `inode fs?`**, previously logged as too fragmentary to interpret. The question the fragment was reaching for is the right one, and it is the storage-layer instance of [[Identity Beneath Presentation|Identity Beneath Presentation]]. An **inode** (conventionally read as *index node*) is a filesystem data structure holding a file's metadata — mode, owner and group, timestamps, link count, size — and the pointers to its data blocks, whether as the direct/indirect pointer tree of ext2 and ext3 or the extent tree of [[ext4|ext4]]. The archivally significant property is what it **omits**: the inode does not store the filename. Names live in *directory entries*, which are themselves ordinary files mapping name → inode number. A rename is therefore a directory operation that does not touch the file; a hard link is a second name for one inode; the link count exists precisely because identity and name are decoupled. **The filename is presentation; the inode is identity.** This is the same structure the notebooks found in bundle identifiers beneath app names and model strings beneath retail branding, appearing one layer lower. **The inode does not federate — and this is the correction worth recording.** An inode number is scoped to a single filesystem instance and is unique only within it. Across two filesystems, inode numbers collide freely and carry no relationship whatsoever; POSIX identity therefore requires the pair `st_dev` + `st_ino`, never the inode number alone. Inode numbers are also **reused after deletion**, which is why network filesystems add a *generation number* to detect stale references. Treating a bare inode number as a global identifier is a textbook [[Identifier Collision|identifier collision]], and it is exactly the error class this archive exists to catch. **But the intuition that it reaches into cloud and networked storage is not baseless — the concept generalizes even though the artifact does not.** Distributed filesystems carry inode-derived identity across the network: [[Network File System|NFS]] file handles historically encode inode number plus generation plus device, and [[Ceph|CephFS]] assigns cluster-wide inode numbers from its metadata servers. Userspace mounts of remote storage via [[Filesystem in Userspace|FUSE]] — sshfs, s3fs, cloud-sync mounts — cause the kernel to present cloud objects *as though* they had inodes, but those numbers are **synthetic, driver-generated, and ephemeral**: they are a local fiction maintained to satisfy the [[Virtual File System|VFS]] interface, not a property of the remote object. True object storage ([[Amazon S3 Dual-stack Endpoint|S3]], [[DigitalOcean Spaces|Spaces]], [[Box|Box]], [[Dropbox|Dropbox]]) has no inodes at all: it is a flat keyspace where identity is bucket + key + version ID, ETags stand in for content verification, and directory hierarchy is a prefix convention rather than a structure. The generalization reaches its endpoint in content addressing — [[InterPlanetary File System|IPFS]] CIDs are derived from the content hash and therefore *are* globally unique without any coordinating authority, which is the logical conclusion of separating identity from name and location. **Inode → NFS file handle → object key plus version → content address** is one lineage of increasingly location-independent identity, and it belongs in [[Index - Technology and Product Lineage|Technology and Product Lineage]] as such. **The `mmcblk0` relationship is one of layering, not equivalence.** `/dev/mmcblk0` is a *block device node* representing the whole [[eMMC|eMMC]] medium; it sits **below** any filesystem. Inodes exist inside a filesystem created on a partition of that device. The full resolution chain for a single file on an embedded device runs: `/etc/hosts` (name) → directory entry → **inode number** → extent or block pointers → **filesystem block numbers** → partition offset on `/dev/mmcblk0p2` → **LBAs on `/dev/mmcblk0`** → the eMMC controller's **flash translation layer** → physical NAND pages, which the host can never address directly. Seven distinct identifier spaces, no two of which correspond one-to-one, each with a different resident authority. This chain is the clearest single demonstration of the stage discipline this index encodes, and it carries **three consequences that bear directly on the archive's forensic work**. First, the FTL means overwriting an LBA does not guarantee the underlying NAND page is erased: wear leveling, over-provisioning, and garbage collection leave stale physical copies that are unreachable through the block interface, so `dd` of a whole device is a complete image of what the *host* can see and not of what the *medium* retains. Second, eMMC exposes **hardware partitions distinct from the software partition table** — `mmcblk0boot0` and `mmcblk0boot1` commonly hold the bootloader, and `mmcblk0rpmb` is a replay-protected authenticated area used for anti-rollback counters and key material — so an acquisition of `mmcblk0` alone **silently misses the boot and RPMB regions**, which is precisely where Stage 3 concerns live. Third, inode-level identity has a specific persistence profile: it survives rename and move within a filesystem, and does not survive copy, migration, restore-from-file-level-backup, or reformat. Only image-level acquisition preserves it, which is a further argument for the archive's existing preference for hashed full images over file copies. --- ## Stage 5 — Peripheral, bus, and composite device identity **Resident authority:** whichever device class the peripheral currently claims to be — a claim the host generally accepts. **Persistent identifiers:** USB VID/PID, [[Universally Unique Identifier|UUID]], HID descriptors, [[Host Controller Interface|HCI]] addresses. **Entities:** [[USB Gadget Mode|USB gadget mode]], [[USB On-The-Go|USB OTG]], [[Raspberry Pi Zero W|Pi Zero W]], [[P4wnP1 A.L.O.A.|P4wnP1]], [[PoisonTap|PoisonTap]], [[USB Rubber Ducky|USB Rubber Ducky]], [[USBGuard|USBGuard]], [[USB Modeswitch|USB Modeswitch]], [[IODD|IODD]], [[Bootable Virtual Drive|bootable virtual drive]], [[Lightning Connector|Lightning]], [[Apple Accessory Protocol|Apple Accessory Protocol]], [[usbmuxd|usbmuxd]], [[libimobiledevice|libimobiledevice]], [[Apple File Conduit 2|AFC2]], [[iFuse|iFuse]]. **Documented mediation modality:** HID injection presenting as a keyboard; USB-Ethernet impersonation capturing the default route; composite gadgets presenting storage, HID, serial, and network roles simultaneously; malicious charging and docking infrastructure. **Evidence obtainable:** `udev` and connection logs, USB descriptor captures, mount and gadget-configuration history, physical inspection of cables and adapters. **Archive coverage:** explicit endpoint-access taxonomy at `Scanned_20260730-1314`, page 12, and programmable USB identity at `Scanned_20260730-1802`, pages 28–29. This is the archive's clearest articulation of [[Boundary Object|boundary objects]] — the same hardware presenting different identities at different boundaries. --- ## Stage 6 — Kernel, mandatory access control, and OS authority **Resident authority:** kernel, security module policy, init system, and holders of root or equivalent. **Persistent identifiers:** SELinux contexts, capability sets, [[Unix File Permissions|permission bits]], `utmp` records, kernel build strings. **Entities:** [[Security-Enhanced Linux|SELinux]], [[SELinux on Android|SELinux on Android]], [[AppArmor|AppArmor]], [[Polkit|Polkit]], [[systemd|systemd]], [[elogind|elogind]], [[OpenRC|OpenRC]], [[udev|udev]], [[D-Bus|D-Bus]], [[Kernel Extension|kernel extensions]], [[macOS Launch Daemon|launch daemons]], [[Root Account|root]], [[sudo|sudo]], [[su Command|su]], [[Sudo Group|sudo group]], [[sulogin|sulogin]], [[Safe Mode|safe mode]], [[pivot_root|pivot_root]], [[AUFS|AUFS]], [[utmp|utmp]], [[Android Rooting|rooting]], [[iOS Jailbreaking|jailbreaking]]. **Documented mediation modality:** loadable module and kext implants; policy relaxation that outlives its stated purpose; daemon substitution; privilege retention after an intended temporary escalation. **Evidence obtainable:** loaded-module lists, SELinux denials and policy diffs, daemon inventories with signature verification, `utmp`/`auth` logs, package-manager transaction history. **Archive coverage:** the jailbreak-to-administration chain at `Scanned_20260730-1235`, pages 4–10, which correctly identifies that package authority and filesystem access lead directly into MDM, observability, backup extraction, and legacy host access. This is a **capability-escalation observation**, not an incident record. --- ## Stage 7 — Alternate execution substrate **Resident authority:** hypervisor or host runtime, which is above the guest and generally invisible to it. **Entities:** [[QEMU|QEMU]], [[QCOW2|QCOW2]], [[UTM|UTM]], [[Xen|Xen]], [[Xen paravirtualization|Xen PV]], [[VirtualBox|VirtualBox]], [[VMware ESXi|ESXi]], [[libvirt|libvirt]], [[Virt-install|virt-install]], [[Virtual Machine Manager|virt-manager]], [[OpenNebula|OpenNebula]], [[Nutanix|Nutanix]], [[Citrix Hypervisor|Citrix Hypervisor]], [[Bochs|Bochs]], [[Limbo PC Emulator|Limbo]], [[Anbox|Anbox]], [[BlueStacks|BlueStacks]], [[Wineskin|Wineskin]], [[XQuartz|XQuartz]], [[X.Org Server|X.Org]], [[X2Go|X2Go]], [[Java Virtual Machine|JVM]], [[Java Platform Micro Edition|Java ME]], [[Blu-ray Disc Java|BD-J]], [[Xlet|Xlet]], [[iSH|iSH]], [[Image Reduction and Analysis Facility|IRAF]]. **Documented mediation modality:** the guest cannot attest the host; snapshot and memory capture from outside the guest; virtual device interposition; migration of a running system without in-guest indication. **Evidence obtainable:** hypervisor logs, snapshot chains, virtual hardware inventories, image provenance and hashes. **Archive coverage:** the [[Alternative Execution Environment|Alternative Execution Environment]] pattern, `Scanned_20260730-1659`, pages 12, 25–32, and 43–59. The archive's own framing — *an application's apparent platform is not its actual execution substrate* — is precisely the security-relevant statement of this layer. ### The virtualized pre-OS boundary — where Stage 3 folds into Stage 7 A guest operating system has a Stage 3, and it is **software owned by the host**. This is the single most consequential structural fact about virtualized systems and it is why these two stages must be read together rather than as separate concerns. **Guest firmware by platform.** [[QEMU|QEMU]]/KVM under [[libvirt|libvirt]] boots guests on **SeaBIOS** for legacy mode or **OVMF/edk2** for UEFI — and [[SeaBIOS|SeaBIOS]] already appears in this index at Stage 3 as a Coreboot payload, which is the point: the same artifact is bare-metal firmware in one context and a host-supplied file in another. [[VirtualBox|VirtualBox]] ships a BIOS derived from the [[Bochs|Bochs]] lineage plus an optional EFI firmware. [[VMware|VMware]] and [[VMware ESXi|ESXi]] supply a proprietary BIOS with EFI as the modern default. Microsoft **Hyper-V** splits explicitly: Generation 1 guests are BIOS with emulated devices, Generation 2 guests are UEFI-only with Secure Boot, synthetic devices, and no legacy boot path at all. **The 20 KB figure almost certainly names the El Torito boot image, not the ISO.** Optical boot works through the **El Torito** extension to ISO 9660: a boot catalog in the image points at a boot image, and in *no-emulation* mode that image can be a few kilobytes loaded to `0x7C00` — a raw chainloader whose only job is to reach something larger. Floppy-emulation mode instead presents a 1.44 MB image. So a ~20 KB artifact is best understood as **the first-stage payload inside the container**, while `isolinux.bin` and comparable [[SYSLINUX|SYSLINUX]]-family stages run somewhat larger. Distribution `boot.iso` and `mini.iso` netinstall images are the same idea one level up — a minimal local image whose entire purpose is to obtain the real system from elsewhere. **This is the same mechanism as Stage 3's network boot, arriving by a different road.** A tiny boot ISO and a BOOTP/PXE reply solve one problem: get a machine with no operating system to execute code fetched from somewhere else. **iPXE** — which the notebooks already record at the Coreboot payload page alongside SeaBIOS, `Scanned_20260730-1719` PDF page 75 — is the clearest case, because it chainloads over HTTP, HTTPS, iSCSI, ATA-over-Ethernet, and Fibre Channel over Ethernet, and can be delivered as a small ISO, embedded in a NIC option ROM, or built as a Coreboot payload. netboot.xyz is the packaged form of exactly this pattern. **Local small image, remote real system** is one continuous technique whose delivery vector — optical, USB, network, ROM, or virtual disk — is an implementation detail rather than a security boundary. **Why this matters for interception, stated carefully.** In virtualization the guest's entire pre-OS trust chain is host-side state: the firmware is a file, the boot order is a configuration field, and attaching or swapping an ISO on a running guest is a host operation that produces no in-guest indication beyond ordinary media-change events. A guest **cannot attest its own firmware**, because the thing it would attest is supplied by the party it would need to attest to. Guest Secure Boot (OVMF with the Secure Boot build, Hyper-V Generation 2 templates, VirtualBox's implementation) constrains what the guest loads *after* firmware hands off, and virtualized TPMs likewise root in host-managed state — both are real controls against in-guest compromise and neither is a control against the host. This is a **structural property of virtualization**, true of every correctly functioning hypervisor, and it is recorded here as an authority boundary rather than as an allegation about any system in this archive. **Evidence obtainable:** hypervisor configuration and revision history showing firmware type and boot order, attached-media logs with timestamps, ISO file hashes compared against distribution checksums and signatures, snapshot chains, guest firmware build identifiers as seen from inside the guest, and — the item most often missing — the host-side record of who could modify any of the above. --- ## Stage 8 — Package, signing, and distribution authority **Resident authority:** whoever decides what constitutes a legitimate installation on the device. **Persistent identifiers:** [[Bundle Identifier|bundle identifiers]], [[Android Package Name|package names]], signing certificates and hashes, [[Software Bill of Materials|SBOM]] entries. **Entities:** [[Android Application Package|APK]], [[XAPK|XAPK]], [[F-Droid|F-Droid]], [[Aptoide|Aptoide]], [[APKPure|APKPure]], [[APKMirror|APKMirror]], [[Uptodown|Uptodown]], [[Xiaomi GetApps|GetApps]], [[Cydia|Cydia]], [[Sileo|Sileo]], [[libhooker|libhooker]], [[checkra1n|checkra1n]], [[unc0ver|unc0ver]], [[Odyssey Jailbreak|Odyssey]], [[Taurine Jailbreak|Taurine]], [[Chimera Jailbreak|Chimera]], [[AltStore|AltStore]], [[iOS Sideloading|sideloading]], [[Install On Air|OTA install]], [[TweakBox|TweakBox]], [[Panda Helper|Panda Helper]], [[TutuApp|TutuApp]], [[AppCake|AppCake]], [[iOSGods|iOSGods]], [[Lucky Patcher|Lucky Patcher]], [[URL Scheme|URL schemes]], [[Storage Access Framework|SAF]], [[App Ops|App Ops]], [[Application Developer Attribution|developer attribution]], [[Software Supply-Chain Provenance|supply-chain provenance]]. **Documented mediation modality:** repackaged applications carrying additional capability; enterprise-certificate distribution outside review; typosquatted package names; dependency and update-channel substitution. **Evidence obtainable:** package ID plus signer plus hash plus store source plus installation timestamp — the five-tuple the archive already identifies as durable evidence. Also permission grant history and update provenance. **Archive coverage:** strong and unusually well-specified. `Scanned_20260730-1659`, pages 7–8, 13–15, 25–30, 38–39, and 43–44. Note the archive's own standing caution at this layer: an unofficial store's presence in a notebook records *investigation*, not installation. --- ## Stage 9 — Interface, launcher, and accessibility governance **Resident authority:** the software that mediates what the user can see, search, discover, and install — which is not cosmetic and is frequently a distinct commercial actor. **Entities:** [[Android Launcher|Android launchers]], [[Android Launcher3|Launcher3]], [[Nova Launcher|Nova]], [[Evie Launcher|Evie]], [[Lawnchair|Lawnchair]], [[Action Launcher|Action]], [[Total Launcher|Total]], [[Niagara Launcher|Niagara]], [[AIO Launcher|AIO]], [[APUS Launcher|APUS]], [[Launcher Governance|Launcher Governance]], [[Android System UI|SystemUI]], [[SpringBoard|SpringBoard]], [[Siri and Search|Siri and Search]], [[iOS Accessibility|iOS Accessibility]], [[AssistiveTouch|AssistiveTouch]], [[VoiceOver|VoiceOver]], [[ChromeVox|ChromeVox]], [[Assistive Technology Service Provider Interface|AT-SPI]], [[Accessibility as Alternate Systems Interface|Accessibility as Alternate Systems Interface]], [[Android Resource Overlay|resource overlays]], [[Tasker|Tasker]], [[Secure Settings Plugin|Secure Settings]], [[Shortcut|Shortcuts]]. **Documented mediation modality:** accessibility services as a general-purpose read-and-control channel over other applications; launcher telemetry and installation brokerage; overlay attacks; search and recommendation surfaces disclosing or substituting identity. **Evidence obtainable:** granted accessibility-service list, launcher package provenance, overlay inventory, default-app and intent-handler assignments. **Archive coverage:** distinctive. The insight that the interface layer *can disclose hidden identities and create alternate control channels* is developed independently across both platforms — `Scanned_20260730-1235`, pages 29 and 31, and `Scanned_20260730-1659`, pages 31–32, 54, and 68–69, including the [[APUS Group|APUS]] ecosystem investigation. --- ## Stage 10 — Local network, discovery, and administration **Resident authority:** gateway, mesh controller, and cloud-managed network plane — often three different parties. **Persistent identifiers:** [[Default Gateway|gateway address]], [[Subnet Mask|subnet]], [[Private IPv4 Address|private IPv4]], [[Link-local Address|link-local]], BSSID, [[Private Wi-Fi Address|private Wi-Fi address]] versus hardware MAC. **Entities:** [[Router Administration|router administration]], [[Router Administrator Interface|admin interfaces]], [[TP-Link Deco|TP-Link Deco]], [[Netgear Orbi|Orbi]], [[Mesh Wi-Fi|mesh]], [[Cisco Meraki MR30H|Meraki MR30H]], [[Cisco Meraki Systems Manager|Meraki SM]], [[NETGEAR Nighthawk M1 MR1100|MR1100]], [[Western Digital My Net N900|My Net N900]], [[EdgeRouter|EdgeRouter]], [[Simple Service Discovery Protocol|SSDP]], [[Discovery and Launch|DIAL]], [[Digital Living Network Alliance|DLNA]], [[Multicast DNS|mDNS]], [[DNS-Based Service Discovery|DNS-SD]], [[Apple HomeKit|HomeKit]], [[Bonjour Sleep Proxy|sleep proxy]], [[Port 5555|port 5555]], [[Android Debug Bridge|ADB]], [[scrcpy|scrcpy]], [[droidVNC-NG|droidVNC-NG]], [[Wireshark|Wireshark]], [[Packet capture|packet capture]], [[Zenmap|Zenmap]], [[Nikto|Nikto]], [[Port Scanning|port scanning]], [[ZoneMinder|ZoneMinder]], [[ONVIF|ONVIF]]. **Documented mediation modality:** gateway compromise yielding DNS and route control for every downstream device; ARP and NDP manipulation; exposed debug ports on the local segment; service advertisements disclosing device inventory to anyone on the link. **Evidence obtainable:** DHCP lease tables, ARP caches, controller logs, packet captures with timestamps, router configuration exports, discovery-protocol dumps. **Archive coverage:** extensive and methodologically careful. `Scanned_20260730-1650` develops the crucial distinction between a local router address and a public look-alike site, and between a private Wi-Fi address and a hardware MAC. See [[Discovery and Launch|discovery-record]] caution in the Pattern Ledger: a service advertisement is not proof of authorization or physical custody. --- ## Stage 11 — Transport, proxy, and name resolution **Resident authority:** resolver, proxy, VPN endpoint, and CDN edge — each of which sees plaintext or metadata the endpoints assume is private. **Entities:** [[Domain Name System|DNS]], [[Cloudflare DNS|Cloudflare DNS]], [[Quad9|Quad9]], [[Dynamic DNS|Dynamic DNS]], [[Network Address Translation|NAT]], [[Application Layer Gateway|ALG]], [[Session Traversal Utilities for NAT|STUN]], [[Session Initiation Protocol|SIP]], [[Session Description Protocol|SDP]], [[Real-time Transport Protocol|RTP]], [[RTP Control Protocol|RTCP]], [[Generic Routing Encapsulation|GRE]], [[Layer 2 Tunneling Protocol|L2TP]], [[xl2tpd|xl2tpd]], [[Point-to-Point Tunneling Protocol|PPTP]], [[Microsoft Point-to-Point Encryption|MPPE]], [[OpenVPN|OpenVPN]], [[NordVPN|NordVPN]], [[Tor|Tor]], [[Proxy Server|proxy]], [[Proxy Bypass|proxy bypass]], [[Shadowrocket|Shadowrocket]], [[Browser Interception|Browser Interception]], [[Proofpoint URL Defense|URL Defense]], [[Look-alike Domain|look-alike domains]], [[Domain Blocklist|blocklists]], [[Cloudflare|Cloudflare]], [[Anycast|anycast]]. **Documented mediation modality:** resolver substitution; TLS interception via installed trust anchors; captive-portal and rewriting proxies; look-alike domain capture of credentials; ALG state modification following protocol semantics across zones. **Evidence obtainable:** DNS answer history, certificate chains and CT log entries, installed root store inventory, proxy configuration and PAC files, timestamped routing observations. **Archive coverage:** developed across `Scanned_20260730-1659`, pages 33–39, and `Scanned_20260730-1650`. The archive's caution is exactly correct and worth restating: bind each hostname to process, timestamp, DNS/TLS history, and confidence. --- ## Stage 12 — Attribution and provenance **Resident authority:** none — this stage is *interpretive*, and is where reconstruction most often fails. **Entities:** [[Autonomous System Number|ASN]], [[Object Identifier|OID]], [[Private Enterprise Number|PEN]], [[Internet Assigned Numbers Authority|IANA]], [[Structure of Management Information|SMI]], [[Abstract Syntax Notation One|ASN.1]], [[IP Geolocation|IP geolocation]], [[Fully Qualified Domain Name|FQDN]], [[Top-level Domain|TLD]], [[Country-code Top-level Domain|ccTLD]], [[Network Attribution|Network Attribution]], [[Identifier Collision|Identifier Collision]], [[Maltego|Maltego]]. **Documented mediation modality:** not an interception layer but a **misattribution layer**. Shared hosting, CDN proxying, anycast, and identifier reuse all systematically break naive inference from address to actor. **Standing rules inherited from the archive:** ASN ownership is not physical location. A shared token is not proof of a system relationship. Page adjacency is not coordination. Cloudflare-proxied addresses do not identify an origin. Any attribution requires timestamped routing and DNS evidence. **Archive coverage:** `Scanned_20260730-1659`, pages 33–34 and 38–39; [[Index - Unresolved Names and Identifiers|Unresolved Names and Identifiers]] functions as this stage's register of failure-to-attribute, which is its most valuable property. --- ## Stage 13 — Enrollment, fleet, and enterprise authority **Resident authority:** the organization that claimed the device, potentially at first boot and potentially before the user ever held it. **Entities:** [[Mobile Device Management|MDM]], [[Samsung Knox Mobile Enrollment|KME]], [[Android Zero-touch Enrollment|zero-touch]], [[Samsung Knox E-FOTA|E-FOTA]], [[Hexnode Unified Endpoint Management|Hexnode UEM]], [[VMware Workspace ONE|Workspace ONE]], [[Microsoft Intune Company Portal|Intune]], [[Active Directory|Active Directory]], [[Microsoft Entra ID|Entra ID]], [[Enterprise Admins|Enterprise Admins]], [[Okta|Okta]], [[Auth0|Auth0]], [[OneLogin|OneLogin]], [[Security Assertion Markup Language|SAML]], [[Single Sign-On|SSO]], [[Access Token|access tokens]], [[Device Attestation|attestation]], [[Zero Trust Architecture|Zero Trust]], [[Google Advanced Protection Program|Advanced Protection]], [[HOME_CSC|HOME_CSC]], [[Android Provisioning|provisioning]]. **Documented mediation modality:** enrollment surviving factory reset; silent policy and certificate push; remote wipe and lock as a denial capability; approved-firmware gating that prevents patching; enrollment records outliving the organizational relationship that justified them. **Evidence obtainable:** enrollment records with claiming organization and date, MDM profile inventories, certificate stores, policy revision history, IMEI-to-enrollment registry lookups. **Archive coverage:** the factory-to-enterprise onboarding chain at `Scanned_20260730-1802`, page 5. Structurally the most important stage for the archive's central question, because it is the layer at which **authority over a device can be legitimately vested in a party the holder never chose**, through a mechanism that is invisible from the user interface and survives every reset the user knows about. ### Residual enrollment on secondary-market hardware — a standing alternative hypothesis **This must be considered and excluded before any secondary-market device is read as evidence of targeting.** Ex-corporate hardware moves in enormous volume through IT asset disposition channels onto the global secondary market, and **incomplete deprovisioning is a common, well-documented, entirely mundane failure**. A device sold, donated, or refurbished without proper release can arrive carrying: an active AMT provisioning record with the prior organization's certificates and Management Presence Server address; Active Directory or [[Microsoft Entra ID|Entra]] domain remnants; an [[Mobile Device Management|MDM]] profile or [[Samsung Knox Mobile Enrollment|KME]]/zero-touch registration still naming the previous claimant; an activated Absolute persistence module reporting to an account the new owner has never heard of; a BIOS supervisor password; asset tags; and a corporate image with certificates, proxy configuration, and VPN profiles intact. The consequence matters enormously for this archive: **residual enrollment produces very nearly the exact symptom set of deliberate targeting.** Unexplained management traffic, a device that phones an unfamiliar host, policy the possessor cannot alter, credentials in the certificate store with no explanation, and settings that survive a factory reset are all fully consistent with negligent asset disposal. They are also consistent with deliberate action. **The symptom does not discriminate**, and the discriminating evidence is the *date and identity of the enrollment* — an enrollment predating acquisition indicates inheritance, one postdating it indicates something else. **Practical requirement.** For any device in this archive acquired secondhand, refurbished, or through a channel other than first-hand retail purchase, record the acquisition date and channel alongside the enrollment date wherever both are recoverable, and treat the residual-enrollment hypothesis as live until the dates exclude it. Where enrollment records cannot be obtained, say so — an unexcluded alternative is not the same as a refuted one. This applies with particular force to business-class hardware such as ThinkPad, EliteBook, EliteDesk, Latitude, and OptiPlex lines, which are precisely the vPro and managed-fleet population and therefore both the most likely to carry residual enrollment and the most capable of the behaviors that enrollment produces. --- ## Stage 14 — Account, domain, and identity continuity **Resident authority:** registrar, mailbox provider, carrier, and every recovery channel — the layer where identity is actually held. **Entities:** [[Identity Continuity|Identity Continuity]], [[Account Recovery|Account Recovery]], [[Account Migration|Account Migration]], [[Account Transfer|Account Transfer]], [[Email Normalization|Email Normalization]], [[Email Migration|Email Migration]], [[Domain Portfolio Governance|Domain Portfolio Governance]], [[Domain Renewal|Domain Renewal]], [[GoDaddy|GoDaddy]], [[Mail Exchanger Record|MX records]], [[Google Workspace|Google Workspace]], [[Microsoft 365|Microsoft 365]], [[Telephone-number Login|telephone-number login]], [[Credential Ledger|Credential Ledger]], [[Certificate and Device Identity Ledger|Certificate and Device Identity Ledger]], [[Backup Ledger|Backup Ledger]], [[Continuity Ledger|Continuity Ledger]], [[Recovery Capability Matrix|Recovery Capability Matrix]], [[KeePass|KeePass]]. **Documented mediation modality:** recovery-channel capture as the highest-leverage path to everything else; registrar and MX redirection; expired domain acquisition reactivating historical mail routes; port-out attacks defeating SMS second factors. **Evidence obtainable:** registrar and WHOIS history, DNS zone change records, mailbox forwarding and alias configuration, login and recovery-attempt logs, support-ticket transcripts. **Archive coverage:** `Scanned_20260730-1659`, pages 3, 18–19, and 50–67; `Scanned_20260730-1719`, pages 13 and 22–23. The archive correctly treats recoverability as requiring account access, domains, contacts, payment, support, and device identity together — not merely data backup. --- ## Stage 15 — Governance, assurance, and evidentiary standing **Resident authority:** institutions that translate technical fact into accountable claim, and the evidentiary standards that determine whether a reconstruction is admissible or merely sincere. **Entities:** [[Security Operations Center|SOC (operations)]], [[System and Organization Controls|SOC (assurance)]], [[Chief Information Security Officer|CISO]], [[Security Governance|Security Governance]], [[Qualys VMDR|Qualys VMDR]], [[IBM QRadar|QRadar]], [[Syslog|Syslog]], [[Nagios|Nagios]], [[Digital Forensics|Digital Forensics]], [[Internet Crime Complaint Center|IC3]], [[Federal Bureau of Investigation|FBI]], [[United States Department of Justice|DOJ]], [[Fraud Reporting|Fraud Reporting]], [[Authority Matrix|Authority Matrix]], [[Ontology Engineering|Ontology Engineering]], [[Universal Object Interaction|UOI]], [[Programmable Object Interaction|POI]], [[Universal Access Grammar|Universal Access Grammar]], [[Epistemic Asymmetry|Epistemic Asymmetry]]. **Documented failure modality:** the **acronym collision** problem the notebooks identified independently — SOC, SoC, SSC, and SoS name incompatible domains, and unqualified use produces category errors that propagate silently through an analysis. Naming conflict is not superficial; domain must be represented explicitly. **Archive coverage:** `Scanned_20260730-1802`, pages 39–42. This stage is where the archive's own method lives, and it is the reason the technical stages above can be read as inquiry rather than assertion. --- ## Cross-stage residents — the out-of-band management plane Every entry above belongs to a stage. A small number of entities do not, and they are the reason single-layer defenses fail. **[[Intel ME|Intel ME]]/CSME with AMT is the archive's purest [[Boundary Object|boundary object]]**: it is silicon in the platform controller hub (Stage 2), firmware in a protected flash region with its own access permissions (Stage 3), a network endpoint that filters its own traffic ahead of the host stack (Stages 10–11), and an enterprise management authority (Stage 13) — **simultaneously, in one entity**. It is not *at* a layer; it is *across* them. This is the precise structural reason it feels unstoppable: a defense mounted at any single stage does not intersect it. ### What is accurate about the vPro-era architecture AMT runs on the Management Engine, a coprocessor executing independently of the main CPU and OS. It provides remote power control, KVM, serial-over-LAN, IDE redirection for remote boot, and remote secure erase of the primary storage device. It shares the host's physical network interface, and the ME claims its own ports ahead of the host stack. **CIRA** (Client-Initiated Remote Access) has the ME open an outbound tunnel to a Management Presence Server, which traverses NAT and firewalls in the direction they generally permit — and the archive already contains this artifact directly, as `F4 Start Intel CIRA` in the HP EliteDesk startup menu at `Scanned_20260730-1719` PDF page 37, adjacent to `F3 UEFI Drivers (3rd party option ROM mgmt)`. Intel EMA is the current successor. All of this is vendor-documented, designed behavior. ### Three corrections that must enter the record before this is cited **1. AMT's root of trust is the ME, not the TPM.** The common claim that AMT checks the TPM to verify platform integrity before permitting a remote connection is **incorrect**. AMT's firmware and its provisioned certificates live in the CSME region of the SPI flash, and the firmware executes on the ME using its own reserved memory. vPro *bundles* AMT, TPM, TXT, and VT-x/VT-d as complementary features; measured launch using TPM is **TXT**, a separate mechanism. AMT does not gate on TPM attestation. **This correction strengthens rather than weakens the underlying thesis**, because it means the management channel's trust anchor is a region the owner cannot read, rather than a TPM the owner could at least interrogate. It is compounded by **Intel PTT**, the firmware TPM implementation that runs *inside* the CSME — on PTT systems the TPM is not an independent second root of trust at all; it is a service of the management engine. **2. Wireless out-of-band was substantially weaker than the draft claims.** Vendor and management-suite documentation is consistent: AMT 2.5 and later can be managed out-of-band over wireless LAN **only while the system is powered on and the wireless interface is active**; in sleep states, out-of-band management requires **wired LAN and AC power**. In the powered-on case the host wireless driver cooperates in routing AMT traffic, though the ME can still receive management traffic if that driver fails. This is a driver-cooperative model, not the unconditional hardware mux the draft describes. AMT also supports DHCP only, not static addressing. **The strong, unconditional out-of-band capability was a wired-Ethernet property.** The physical radio kill switch on ThinkPad-era chassis genuinely defeated wireless AMT, which is why [[Purism|Purism]] and the [[Purism Librem 5|Librem]] line — both already in this archive — treat hardware kill switches as a security primitive rather than a convenience. **3. AMT over WiMAX is unverified and should not be asserted.** Centrino 2 (Montevina) offered optional WiMAX, and Intel shipped WiMAX/Wi-Fi combination adapters (Centrino Advanced-N + WiMAX 6250, Wireless-N + WiMAX 6150) in the same platform generation as vPro. But every AMT-supported wireless adapter list found so far names **Wi-Fi-only adapters** — Centrino Advanced-N 6205, 6235, Ultimate-N 6300, Dual Band Wireless-N/AC 7260 — and does not name the WiMAX combination parts. **Platform coexistence is not feature integration.** Record this as unresolved and require a vendor document naming AMT and WiMAX together, or an AMT wireless-profile configuration screen showing a WiMAX interface, before treating it as established. See [[Index - Unresolved Names and Identifiers|Unresolved Names and Identifiers]]. ### The documented failure case The capture thesis does not require speculation, because a fully documented instance exists. The Management Engine BIOS Extension is reachable by pressing CTRL-P during boot, and its default password on many shipped systems was `admin`. Where that default was never changed, an attacker with brief physical access could set their own MEBx password, enable remote access, and set user opt-in to none — after which the machine was remotely reachable over wired or wireless networks from the same segment, **below and invisible to the operating system, surviving OS reinstallation**. This was publicly reported in 2018 and carries a mundane mitigation: disable AMT in firmware if unused, and set a strong MEBx password if used. It is recorded here because it demonstrates the mechanism's reach using vendor-documented behavior and a default credential rather than any exotic capability. ### The honest limit of the thesis **"Near unstoppable" overstates it; "asymmetrically expensive to escape" is exact and more defensible.** Countermeasures exist and the notebooks already contain them: `me_cleaner` and the HAP/AltMeDisable bit neuter most ME functionality, [[Coreboot|Coreboot]] and [[Libreboot|Libreboot]] replace the firmware outright, [[Minifree|Minifree]] and [[Purism|Purism]] ship hardware with the ME removed or disabled and radios on physical switches, pre-2008 hardware predates the mechanism entirely, and [[Purism Librem 5|Librem 5]] and [[PinePhone|PinePhone]] isolate the baseband. The accurate statement is that **remediation requires exiting the ecosystem rather than repairing a device**. You cannot patch your way out; you must change what you own. That is a real and available path, and the archive's own hardware choices show it was already being taken. ### The ontological finding Across secure boot, the Management Engine, the baseband, and enterprise enrollment, the trust anchor is a key held by a vendor, a carrier, a silicon manufacturer, or a claiming organization. **In none of these systems is the possessor of the device a party to the trust model.** Ownership in the legal sense and authority in the cryptographic sense have been fully decoupled, and the decoupling is architectural rather than accidental — each mechanism was built for a defensible purpose, and no single one constitutes capture. What produces the effect is their **superposition**: many independently reasonable irreversibilities, rooted in different authorities, none of which includes the owner, all resident on the same board. This is the archive's [[Continuity of Identity Under Mediation|continuity of identity under mediation]] problem stated in hardware, and it is the strongest general claim this material supports. ## Actor classes and the authorization gap See [[Authorization Gap|Authorization Gap]] for the canonical statement of this interpretive rule. **This is the single most important interpretive principle in this index, and it should be read before any stage entry is used to support a claim.** Every mechanism catalogued above is used, in the ordinary course of business, by multiple distinct actor classes pursuing entirely different purposes. Mobile device management enrolls a corporate fleet and also enables an abusive installation on a family member's phone. A service tool restores RF calibration in a repair shop and also clones a handset. Lawful intercept architecture is a documented, standardized part of carrier infrastructure and also a capability whose scope is politically contested. Out-of-band management recovers a bricked laptop in a branch office and also reaches a machine below its operating system. **The mechanism does not vary. The authorization does.** ### The actor classes | Class | Typical mechanisms | Basis of authorization | |---|---|---| | Employer and enterprise IT | MDM, enrollment, AMT, E-FOTA, remote wipe | Device ownership, employment agreement, acceptable-use policy | | OEM, carrier, and platform | Firmware signing, subsidy lock, OTA update, app store review | Purchase terms, service contract, platform agreement | | State, under legal process | Standardized lawful-intercept interfaces, carrier records, device seizure and forensic acquisition | Statute, warrant, or equivalent legal instrument, varying by jurisdiction | | Commercial surveillance vendors | Exploit chains and implants sold to state and institutional customers | Contractual, with legality contested and jurisdiction-dependent | | Repair and refurbishment channel | Service tools, NV access, bootloader unlock, firmware reflash | Customer instruction and consent | | Criminal actors | Cloning, SIM swap, stalkerware distribution, credential theft | None | | Interpersonal and domestic | Shared accounts, family locators, device gifting with retained access, stalkerware | **Ambiguous by design** — frequently the hardest class to assess and among the most common in practice | ### The authorization gap **A technical artifact records the mechanism. It does not record the authorization.** An enrollment record shows that a device was claimed and by whom; it does not show whether the claim was agreed to. An installed profile shows a policy is in force; it does not show who consented. A management session in a log shows a connection occurred; it does not show under what instrument. This gap is not a deficiency in the evidence-gathering — **it is a property of the systems themselves**, which were built to record technical facts and were never built to record the legitimacy of the party invoking them. Three consequences follow, and they constrain every claim this archive can make. **Finding a mechanism establishes nothing about the actor class.** Discovering MDM enrollment, an AMT provisioning record, a modified NV item, or an unexpected certificate identifies *what happened*. It does not, alone, distinguish an employer from a carrier from a criminal from a former partner. Any inference to actor class requires independent evidence. **The decisive evidence is usually documentary rather than technical, and it is usually held by the party in question.** Whether an enrollment was authorized lives in an enrollment agreement, a purchase record, an employment file, or a court order — not in the device. And the organization whose authorization is being examined is generally the custodian of the record that would settle it. This is [[Observability Asymmetry|observability asymmetry]] in its most consequential form: the party with the most complete record has the least incentive to produce it, and the party seeking it has neither the access nor, ordinarily, the standing to compel it. **Tool and component provenance carries no weight regarding actor identity.** A service utility, a forum, a firmware image, or a silicon supplier is used identically by repair shops, enterprises, states, and criminals across every jurisdiction. The nationality of a tool's developer, the language of a forum, or the country of a component's fabrication establishes nothing whatsoever about who used it or why. **This is the archive's existing rule that ASN ownership is not physical location, applied to software and hardware supply rather than to routing, and it must be enforced with equal strictness.** It is also the specific inference this archive is most structurally exposed to, because a reconstruction assembled under threat naturally reaches for the most alarming available reading of a neutral artifact. ### Why this strengthens rather than weakens the archive Stating the authorization gap plainly is what converts this index from an accusation framework into an **analytical instrument**. A reader who is shown that the same mechanisms serve payroll administration, warranty repair, statutory process, and abuse — and who is then shown a specific artifact with its confidence tier and its unresolved questions — is in a position to evaluate. A reader shown only the alarming reading is being asked to trust the author, which is the one thing this archive has consistently declined to request. The mechanisms are real, extensively documented, and more powerful than most people understand. **That is true independently of who used them in any particular case, and the two claims should never be merged.** ## Cross-stage properties **Actor class is not readable from the artifact.** See the authorization gap above. At every stage, the same mechanism serves administration, commerce, legal process, repair, crime, and domestic control. Any stage entry used to support a claim about *who* must be paired with independent, usually documentary, evidence. **Irreversibility is symmetric.** Every mechanism that makes a device resistant to an attacker makes it equally resistant to its owner. Permanent write-protect bits, blown fuses, anti-rollback counters, and one-time-programmable RPMB keys do not evaluate intent — they evaluate operations. A locked bootloader defeats malware persistence and defeats forensic acquisition; anti-rollback blocks a downgrade exploit and blocks restoring a trusted older image; secure erase protects a lost laptop and destroys evidence. **Any claim in this archive about a hardware protection should state both directions**, because the mechanism itself does not distinguish them and an analysis that reports only one direction is describing half the artifact. **Descent of control.** Authority increases as the stage number decreases: firmware outranks kernel, kernel outranks package, package outranks interface. A defense at Stage 9 cannot constrain an actor at Stage 3. This is the vertical reading of the Pattern Ledger's *control descends through the stack*. **[[Translation Boundary|Translation boundaries]] are failure boundaries.** Every adjacent stage pair is a translation, and continuity fails at translations rather than within layers. Carrier/device (1↔2), firmware/OS (3↔6), image/hypervisor (4↔7), package/interface (8↔9), and account/device (14↔13) are the archive's already-identified boundary set. **Identifier persistence is stage-dependent.** An identifier's evidentiary weight depends on which stage assigns it and which operations preserve it. A launcher package name survives nothing; an **inode number survives rename and in-place move but not copy, migration, file-level restore, or reformat**; an eMMC CID survives a factory reset; an FCC ID survives the device's entire life; an enrollment record may survive the owner's relationship with the organization that created it. Any continuity claim must state the stage its identifier came from. **Scope must be stated with every identifier.** Persistence answers *how long*; scope answers *how far*. An inode number is unique only within one filesystem and requires `st_dev` to disambiguate; an IMEI is globally unique by allocation; a private IPv4 address is unique only within its subnet; an ASN is globally unique but names an administrative entity rather than a location; an IPFS CID is globally unique by construction because it is derived from content. **Collision risk is a property of scope, and every unresolved identifier in this archive should carry both.** See [[Identifier Collision|Identifier Collision]]. **[[Stage Folding Under Virtualization|Stages fold under virtualization and emulation]].** The stage ladder describes a physical machine. When a system is virtualized, the guest's Stages 2 through 6 become **host-side data** — firmware is a file, storage is an image, the network adapter is a configuration object — and the whole lower ladder collapses into the host's Stage 7. The practical rule: **for any claim about a guest, state whether the evidence originated inside the guest or on the host**, because in-guest evidence is subject to the host and cannot establish anything about it. The same folding occurs, less completely, under containerization and under vendor frameworks that present a synthetic platform to applications. **Small local image, remote real system.** BOOTP/PXE replies, tiny El Torito chainloaders, netinstall `boot.iso` images, and iPXE ROMs are one technique with several delivery vectors. Delivery medium — optical, USB, network, option ROM, virtual disk — is an implementation detail; the boundary that matters is that a machine with no operating system is executing code obtained from a source it cannot authenticate. Stage 3 and Stage 7 both instantiate it. **Vertical scale invariance.** The same identity-and-policy grammar recurs from a database row to a fleet to an institution, which is why this index and the [[Index - Pattern Ledger|Pattern Ledger]] are two projections of one structure rather than two subjects. ## Open work - Assign every entity in [[Index - Technology and Product Lineage|Technology and Product Lineage]] a stage number, and flag any entity that resists single-stage assignment as a [[Boundary Object|boundary object]] for separate treatment. - **Unresolved — modem service tool and forum recollection.** An owner-supplied recollection of a website permitting direct reconfiguration of a device's non-volatile memory and hardware parameters is currently **unmatched to any artifact**. Candidate identifications include DFS CDMA Tool, CDMA Workshop, and the 4PDA forum, but no candidate should be normalized into the record on recollection alone, and secondary claims about any tool's developer nationality should be treated as unverified until checked against a registration record or archived site. Recovery is unusually tractable: these were licensed products and registered forums, so a purchase receipt, license email, payment record, bookmark, or screenshot in the wider corpus would settle it — and a dated license purchase would additionally serve as a chronology anchor. **Per the authorization gap, tool nationality and forum language establish nothing about actor identity**, and this entry must not be used to support any such inference. - **Unresolved — Russian-manufactured CDMA baseband radios.** An owner-supplied assertion associates Russian-made CDMA basebands, described as state and private security radios, with supply-chain bit-locking of NAND, UFS, and eMMC. The **bit-locking half is technically well-founded** and is documented at Stage 2. The **attribution half is not currently supported**: the baseband market is dominated by Qualcomm, MediaTek, Samsung, HiSilicon, UNISOC, and formerly Intel and [[Sequans Communications|Sequans]], and no significant Russian baseband silicon industry is established in available sources, though Russian CDMA-450 networks did operate. Treat as **unresolved pending the original artifact** — a chip marking, FCC or regulatory grantee record, firmware string, teardown photograph, or procurement document. Do not normalize a manufacturer, a nationality, or an actor from the current wording. Record separately from the write-protect findings so a failure of the attribution claim does not contaminate the mechanism claim. - **Resolved — Heimdall / Heimdallr collision guarded.** [[Heimdallr|Heimdallr]] remains the Apple crash-log-context label associated with [[CrashCapture|CrashCapture]]; [[Heimdall|Heimdall]] is the distinct open-source Samsung download-mode flashing tool. Both notes now carry explicit disambiguation. - Link the Stage 3 Odin analysis back to `Scanned_20260730-1650` PDF page 5 and forward to the Stage 2 fuse material, so the page-5 open lead — *record device model, binary revision, bootloader lock, Knox state, anti-rollback level, and exact firmware package* — is satisfied by a single procedure rather than restated per notebook. That lead is now answerable and should be closed when the devices are available. - Create the remaining entity notes for **SquashFS**, **EROFS**, **dm-verity**, **vbmeta**, **dynamic partitions and `super`**, **APEX**, **Knox warranty bit**, **Samsung download mode**, **anti-rollback level / binary revision**, and **SysDump**. [[Android Verified Boot|Android Verified Boot / AVB]], [[Heimdall|Heimdall]], [[Security-Enhanced Linux|SELinux]], [[ext4|ext4]], [[F2FS|F2FS]], [[Samsung Odin|Samsung Odin]], and [[Android Open Source Project|AOSP]] now have canonical targets. - Create entity notes for **Intel AMT**, **Intel CSME**, **CIRA / Management Presence Server**, **Intel EMA**, **Intel PTT**, **Intel TXT**, **Intel Boot Guard**, **me_cleaner and the HAP bit**, **eFuse / one-time-programmable memory**, **eMMC extended CSD write protection**, **UFS**, **anti-rollback counter**, **baseband processor**, and **Absolute / Computrace persistence**. [[Intel ME|Intel ME]] and CIRA have direct notebook backing at `Scanned_20260730-1719` PDF page 37. - **Correct any archive text asserting that AMT depends on the TPM.** AMT's credentials reside in the CSME flash region; TPM-based measured launch is TXT, a distinct mechanism; and Intel PTT implements the TPM inside the CSME rather than beside it. - Create entity notes for **System Management Mode / SMI**, **Intel Boot Guard**, **AMD Platform Secure Boot**, **PCI Option ROM**, **ACPI Machine Language**, **WPBT**, **DMAR**, and **POST checkpoint codes**, none of which have vault targets. The HP EliteDesk startup menu at `Scanned_20260730-1719` PDF page 37 is existing notebook backing for option-ROM management and [[Intel ME|Intel ME]]/CIRA. - **Add a platform-generation field to every firmware claim in the archive.** Verification status changed materially around 2013 with Intel Boot Guard and AMD PSB; an undated assertion that firmware is unverified is not interpretable. Where a device's generation is unknown, record it as unresolved rather than assuming either answer. - Create entity notes for **El Torito**, **iPXE**, **OVMF/edk2**, **Hyper-V**, **netboot.xyz**, **isolinux**, and **Trivial File Transfer Protocol**, all referenced in this index without existing vault targets. iPXE has notebook backing already at `Scanned_20260730-1719` PDF page 75 and should be linked from [[SeaBIOS|SeaBIOS]] and [[Coreboot|Coreboot]] as a sibling payload. - Record, for every virtual machine appearing anywhere in the archive, **which firmware it booted and whether evidence about it came from inside the guest or from the host**. Under the stage-folding rule, in-guest evidence cannot speak to host-side state. - **Resolved:** the notebook fragment `inode fs?`, previously logged as unresolvable, is closed by the Stage 4 identity-resolution chain. Update [[Index - Unresolved Names and Identifiers|Unresolved Names and Identifiers]] to move it from open to resolved, citing this index. - Audit every past acquisition in the archive for **eMMC hardware-partition coverage**: confirm whether `mmcblk0boot0`, `mmcblk0boot1`, and `mmcblk0rpmb` were captured alongside `mmcblk0`, since bootloader and anti-rollback state live there and a whole-device `dd` does not reach them. - Record the **inode → NFS file handle → object key plus version → content address** progression in [[Index - Technology and Product Lineage|Technology and Product Lineage]] as a location-independence lineage. - Add a scope column alongside persistence for every identifier in [[Index - Unresolved Names and Identifiers|Unresolved Names and Identifiers]], since collision risk is a function of scope. - **Resolved:** the pre-OS network-boot entry is BOOTP, together with its descendant DHCP and the PXE profile built on both. No unresolved-identifier record is required. - **Unresolved — Samsung tablet SquashFS boot observation with verbose bootloader imagery.** Owner-supplied observation that normal boot appeared circumvented, with photographs of a verbose bootloader showing staged SquashFS mounting. **The filesystem observation alone does not support the reading**: compressed read-only filesystems are standard on Android read-only partitions, and per Stage 4 the integrity question belongs to verified boot rather than to the filesystem format. **The verbose bootloader output is the more interesting artifact** and should be worked first. Resolve by recording, from the download-mode screen and device properties: firmware build string, bootloader version, binary type (USER versus ENG), Knox warranty bit value, OEM-lock and FRP state, `ro.boot.verifiedbootstate`, and `vbmeta` state. Exclude the mundane causes — a raised SysDump debug level, and engineering or factory bootloader binaries reaching retail or refurbished channels — before treating verbosity as anomalous. Bind to specific device models in [[Index - Device Inventory|Device Inventory]]; the existing entry for Samsung tablets associated with [[Samsung Knox Mobile Enrollment|KME]], zero-touch, and [[Samsung Knox E-FOTA|E-FOTA]] at `Scanned_20260730-1802` page 5 records unresolved models and may or may not refer to these devices. Evaluate against the residual-enrollment hypothesis at Stage 13 if the devices were acquired secondhand or refurbished. - **Unresolved — two Lenovo devices with apparent Nottingham, England reconfiguration.** Owner-supplied observation; the basis for the Nottingham association is **not yet recorded and should be captured before anything else**, since the artifact behind the impression determines its weight entirely. Candidate sources include a BIOS asset-tag or owner-string field, a registered-organization registry value, a recovery-partition or OEM image brand, a saved network profile or certificate, an MDM or domain remnant, a service or ITAD sticker, a purchase or auction listing, or shipping documentation. No Lenovo manufacturing, configuration, or refurbishment facility in Nottingham was located in available sources; Nottingham does host several large employers with substantial managed laptop fleets, which makes a **UK ex-corporate ThinkPad on the secondary market unremarkable rather than remarkable**. Evaluate against the residual-enrollment hypothesis at Stage 13 before any other reading, and record acquisition date and channel alongside any enrollment date. These devices are also the **pending source of the WiMAX firmware photographs**, and ThinkPads of the relevant generation genuinely shipped Intel WiMAX combination adapters, which makes that claim more plausible on this hardware than on most — the two questions should nonetheless be resolved separately. Per the authorization gap, a geographic association establishes nothing about actor identity. - **Pending owner production — WiMAX firmware boot photographs.** Bryant McGill states photographs exist of firmware exposing WiMAX boot capability. On production, read them against the Stage 3 resolution criteria: whether the entry sits in a **boot device list** (establishes the capability) or a **radio enable/disable menu** (does not), plus vendor, model, firmware version and date, exact entry wording, and any POST option ROM banner. Bind the artifact to a specific device in [[Index - Device Inventory|Device Inventory]] and, if confirmed, update the Stage 3 note, the Stage 1 WiMAX slot, and [[Index - Technology and Product Lineage|Technology and Product Lineage]]. If confirmed, this is a notable finding and should be written up as such rather than buried in an index cell. - Add WiMAX/802.16 source material when a notebook containing it is processed; the Stage 1 entry is currently a forward slot with no notebook backing. If a source shows WiMAX in a boot context, record whether it evidences a *firmware-selectable boot device* (Stage 3) or a *bootstrap carried across a WiMAX-served network* (Stages 10–11), and capture the board, firmware version, and boot-menu state before assigning the stage. - **Created:** [[Network Boot Trust|Network Boot Trust]], covering BOOTP/DHCP/PXE/ProxyDHCP/HTTP Boot as one family and preserving the distinction between a firmware-selectable boot device and a bearer that merely carries bootstrap traffic. - Populate the *archive coverage* line for each stage with explicit confidence tiers rather than prose, in preparation for migration to a normalized evidence store. - Add a Stage 16 for **agentic and machine-to-machine authorization**, which the [[Universal Object Interaction|UOI]]/[[Programmable Object Interaction|POI]] material anticipates and which has no current representation in the vault. ## Scanned_20260730-1806 stage coverage | Stage | Notebook evidence | Interpretation | |---|---|---| | Stage 3 — firmware and boot authority | PDF pages 6 and 16–17 | EFI research and Motorola build/fingerprint baseline; bootloader lock and verified-boot state remain missing | | Stage 4 — storage and filesystem authority | PDF pages 4–13 | ShadowProtect, HFS, registry hives, external drives, Victoria HDD, S.M.A.R.T., formats, archives, and compatibility research | | Stage 5 — operating-system authority | PDF pages 2, 4, and 16–17 | LineageOS agenda, KolibriOS/Symbian comparison, Android 10/API 29 environment | | Stage 6 — runtime and framework authority | PDF pages 16–18 | ART, Dalvik user-agent identity, APEX runtime, Java boot class path, Dagger, GWT, and JSR 305 | | Stage 7 — application authority | PDF pages 19–27 | App managers, manifests, activities, package flags, browsers, FileProvider, developer identity, and package provenance | | Stage 8 — package, signing, and distribution authority | PDF pages 18–27 | APK internals, F-Droid, repositories, forks, tracker definitions, signatures, installer/source questions | | Stage 9 — interface and attention authority | PDF pages 20–25 | Intent resolver, visible app labels, color/icon legends, long-click actions, and system/user REDACTED | | Stage 13 — enrollment, fleet, and enterprise authority | PDF page 26 | Carrier package and privileged shared-UID/core-app observations; no enrollment record is established | **Authorization gap:** system status, shared UID, carrier branding, foreign provenance, tracker signatures, and a “Surveillance” heading are not proof of interception or malicious control. Preserve capability, runtime behavior, signer, installer, build baseline, and authorization separately. ## Scanned_20260730-1230 stage coverage | Stage | Notebook evidence | Interpretation | |---|---|---| | Stage 0 — source and evidence integrity | PDF pages 1, 3, and 29–30 | Duplicate label captures and two physical package panels support identity validation; scan-to-original comparison remains necessary | | Stage 1 — physical and regulatory identity | PDF pages 1, 13–18, 21, and 23–37 | Serial, model, FCC/Canadian, PCB, battery, adapter, charger, appliance, and breaker labels form the notebook's strongest evidence layer | | Stage 2 — radio and subscriber identity | PDF pages 12–14, 17–18, 21, and 37 | EID, IMEI/MEID, ICCID, MAC, LTE, and radio identifiers are separated across device, interface, and subscription scope | | Stage 3 — firmware and boot authority | PDF pages 18–19, 21, 25, and 37 | Hardware revision/model evidence exists, but firmware, bootloader, verified-boot, BIOS, and update history are largely absent | | Stage 4 — storage and acquisition authority | PDF pages 1, 23, 25, and 29–30 | Original Mac Pro flash specification and server/stick-PC presence are known; live storage, encryption, images, and acquisition history are missing | | Stage 5 — operating-system authority | PDF pages 10, 18–19, and 25 | Credential-adjacent device hints and product families exist, but OS edition/build and administrative state are unresolved | | Stage 10 — local network administration | PDF pages 1, 25, and 37 | MAC/interface identities could support DHCP or inventory correlation; no router configuration or authorization record is preserved | | Stage 11 — carrier and external network access | PDF pages 12–14, 17–18, 21, and 37 | Cellular identities and carrier variants exist; account, SIM assignment, service state, and traffic evidence do not | | Stage 14 — account and identity continuity | PDF pages 2, 4–10, 33, and 36 | Recovery, financial-account, contact, and credential records; secrets remain redacted and are outside operational use | **Authorization gap:** possession of a label, identifier, credential notation, carrier-capable device, or closed-account record does not establish interception, unauthorized access, actor identity, or compromise. This notebook primarily strengthens inventory and continuity layers. ## Scanned_20260730-1946 stage coverage | Stage | Notebook evidence | Interpretation | |---|---|---| | Stage 0 — source and evidence integrity | PDF pages 10–11 and 17–18 | Duplicate close-up aids transcription; mobile-tool lists lack acquisition hashes, timestamps, and reproducible case records | | Stage 1 — physical and regulatory identity | PDF pages 1, 3, 8–11, and 20–22 | Field notebook, USB/FPGA interfaces, handheld families, and removable-media mechanisms | | Stage 3 — firmware and boot authority | PDF pages 3, 8–12, and 20–21 | DFU, iPXE, custom firmware, Dingux, NTLDR, disk overlays, WinPE, and U3 virtual CD-ROM | | Stage 4 — storage and filesystem authority | PDF pages 3, 7, 12, and 20–21 | FUSE/iFuse, compression dependencies, FAT16, disk overlays, XZ, and virtual optical media | | Stage 5 — operating-system authority | PDF pages 2, 5, 7–12 | AOSP, Wayland/XWayland, z/OS, Rosetta 2, Dingux, BeOS, Xenix, NetWare, and Windows PE | | Stage 6 — runtime and framework authority | PDF pages 2, 17–18 | dyld, runtime injection/hooking, Frida, Cycript, Cydia Substrate, Xposed, and Magisk | | Stage 7 — application authority | PDF pages 5 and 17–18 | Deliberately vulnerable applications, decompilers, scanners, pinning bypass, and attack-surface tooling | | Stage 8 — package, signing, and distribution authority | PDF pages 2, 6–7, 17–20 | Package managers, APK rebuild/decompile, signing/sideloading, installers, dependencies, XZ, and U3 distribution | | Stage 10 — local network administration | PDF pages 3–6 | Aircrack-ng, remote controllers, Wi-Fi fuzzing, IPVS, Bluetooth, and endpoint steering | | Stage 12 — transport, proxy, and trust enforcement | PDF pages 6 and 17–18 | Zscaler Client Connector, Burp, ZAP, SSL Kill Switch, tunnels, and USB SSH | | Stage 14 — account and identity continuity | PDF pages 13–15 | GUID/UUID, banking/PIN contingency disclosure, and credential-centered mesh; secrets fully redacted | | Stage 15 — governance and institutional authority | PDF pages 13 and 16 | Public health, financial systems, industrial infrastructure, and warfare interpreted through dual-use governance | **Authorization gap:** a tool list, vulnerability-training app, remote-control product, RT Buddy label, or infrastructure diagram does not prove installation, interception, compromise, actor identity, or unified coordination. Pegasus heuristics alone mean nothing as attribution proof; preserve the documented CrashCapture/Heimdallr log resources and build a reproducible evidence chain. ## Scanned_20260730-1913 stage coverage | Stage | Notebook evidence | Interpretation | |---|---|---| | Stage 0 — source and evidence integrity | PDF pages 18–20, 27, 36, 43, 58, 64–65, 70, and 82–84 | Notices, schedules, receipts, correspondence, and travel artifacts provide dates and counterparties; scan-to-original custody still matters | | Stage 1 — physical and regulatory identity | PDF pages 32, 56, and 81 | Broadcom hardware identifier and device setup/repair references; exact unit identities remain incomplete | | Stage 10 — local network administration | PDF pages 39–41 and 61 | Router/gateway, Wi-Fi, private-address, and administration notes; credentials remain redacted | | Stage 11 — transport, proxy, and name resolution | PDF pages 3, 37, 41–42, 61, 66, 71, and 90 | DNS/SPF, privacy front ends, carrier provisioning, and cloud endpoint history | | Stage 12 — attribution and provenance | PDF pages 28, 30, 42, 53, 68–69, and 88 | Influence, intelligence, media, and hidden-network clusters require separation of adjacency, capability, event, and actor evidence | | Stage 13 — enrollment, fleet, and enterprise authority | PDF pages 24, 47, and 56 | Android Enterprise planning and macOS MDM payloads; configuration names do not prove unauthorized management | | Stage 14 — account, domain, and identity continuity | PDF pages 3, 5, 24, 35, 37, 42, 56, 59–62, 66, 71, 76–77, 79, and 85 | Account migration, recovery, billing, and carrier identities; all secrets remain segregated | | Stage 15 — governance and evidentiary standing | PDF pages 18–20, 30, 43–45, 58, and 82–84 | Disputes, alliance research, treaty interpretation, correspondence, receipts, and travel records | **Authorization gap:** a profile name, MDM payload, account record, private address, media list, intelligence-alliance note, or public IP does not prove unauthorized control, interception, actor identity, coordination, or present system state. ## Scanned_20260730-1845 stage coverage | Stage | Notebook evidence | Interpretation | |---|---|---| | Stage 0 — source and evidence integrity | PDF pages 39–43 and 63–67 | Insurance, travel, account, legal, court, and institutional records; credentials and phone numbers remain redacted | | Stage 7 — application authority | PDF pages 16, 20–24, 34–35, 38, 42–43, and 49 | Social, analytics, Apple, marketing, and productivity applications; listing does not prove installation or authorization state | | Stage 11 — transport, proxy, and name resolution | PDF pages 5–7, 15–19, and 64 | SFTP, domains, DNS apex, NS1, VPN, web security, and hosting controls | | Stage 12 — attribution and provenance | PDF pages 14, 25–33, and 67 | Anomaly triage, identity disputes, company-history graph, complaints, and authoritative institutional repositories | | Stage 14 — account, domain, and identity continuity | PDF pages 5–8, 18, 20–33, 42, 60–66, and 68 | Root/admin, email/domain roles, federation, Apple/Google aliases, SIM/OTP, recovery, legal accounts, and final role separation | | Stage 15 — governance and evidentiary standing | PDF pages 3–4, 12, 27, 36, 39–43, and 63–68 | Platform governance, official credentials, government identity, insurance/travel, courts, public-health/science repositories, and domain-role governance | **Authorization gap:** an account label, block state, missing photograph, certificate term, phone factor, or complaint plan does not establish unauthorized access, compromise, actor identity, or institutional coordination. Page 25's identity labels remain allegations pending independent records. ## Scanned_20260730-2016 stage coverage | Stage | Notebook evidence | Interpretation | |---|---|---| | Stage 0 — physical object, label, and supply chain | PDF pages 1 and 43 | Worn Piccadilly covers establish the complete physical source boundary; original custody history remains to be recorded | | Stage 1 — radio, spectrum, and access network | PDF pages 3, 16, 19, 24, 29, and 42 | Google Voice, Google Fi, Visible, Mint, SIM/eSIM, hotspot, and geographically assigned telephone identities | | Stage 9 — interface, launcher, and accessibility governance | PDF pages 5, 14, 33, and 38–39 | Instagram prompt, Twitter metrics/roles, Clubhouse, and device/global-goals interfaces shape attention and public identity | | Stage 11 — transport, proxy, and name resolution | PDF pages 2–3, 17, 19, 21–25, 30, and 41 | Email and domain namespaces, cloud telephony, carriers, privacy mail, registrar identity, and routing dependencies | | Stage 12 — attribution and provenance | PDF pages 26, 37, and 39–41 | Contact attempts, a historical hacked-account statement, account-role labels, and unresolved ownership require dated provider records | | Stage 14 — account, domain, and identity continuity | PDF pages 2–25 and 30–42 | The notebook's dominant layer: aliases, credentials, recovery, carriers, banking, brokerage, social accounts, proofing, wallets, and migration | | Stage 15 — governance, assurance, and evidentiary standing | PDF pages 10–13, 32, 34–37, and 41 | Authorized-user status, collections, climate/public-purpose work, regulated accounts, loyalty identity, and institutional proofing | **Authorization gap:** a saved credential, phone mapping, device name, account label, “hacked” notation, wallet phrase, or provider adjacency does not prove present authority, interception, compromise mechanism, actor identity, balance, transaction, or coordination. All secrets remain redacted and outside operational use. ## Scanned_20260730-1830 stage coverage | Stage | Notebook evidence | Interpretation | |---|---|---| | Stage 0 — source and evidence integrity | PDF pages 7, 9, 16, and 19 | Repeated event cards, explicit dates, sparse fragments, and one redacted phone contact; copied-source provenance remains incomplete | | Stage 11 — transport, provider, and collection position | PDF pages 2–4 and 18 | Five Eyes/ECHELON sharing, PRISM downstream collection, Room 641A infrastructure, and compelled service providers | | Stage 12 — attribution and provenance | PDF pages 1–4 and 9–16 | Crossfire/Mueller/Durham and multiple collection systems require separation of institutional capability, authority, event, and actor | | Stage 14 — selector, repository, and query identity | PDF pages 6–16 | ANI, CDRs, targeting restrictions, U.S.-person identifiers, reverse targeting, querying, retention, and dissemination | | Stage 15 — governance, legal authority, and evidentiary standing | PDF pages 5–18 | FISA/FISC, USA FREEDOM, amici, probable cause, certifications, ex parte procedure, provider orders, compliance, and sunset | **Authorization gap:** an alliance, agency, program codename, provider relationship, selector category, court order, or compliance opinion does not establish that a particular person was targeted, acquired, queried, disseminated, or acted upon. ## Scanned_20260730-1825 | Stage | Notebook evidence | Boundary or significance | |---|---|---| | Stage 0 — source and evidence integrity | PDF pages 2, 7, 9, and 22 | Documentary-file insight, explicit dates, one redacted telephone number, and a contemporaneous journal record | | Stage 5 — operating-system and platform authority | PDF pages 1 and 11 | HarmonyOS and Oracle Linux define environments in which devices and workloads act | | Stage 9 — interface, attention, and representation | PDF pages 1–5 and 14–15 | Social feeds, account-following, conferences, Google interests, cosplay, skins, AR, and VR shape discovery and represented identity | | Stage 11 — transport, cloud, and isolation | PDF pages 11–12 | OCI, autonomous database, serverless/dedicated deployment, private endpoints, and shared-tenancy boundaries | | Stage 12 — attribution and provenance | PDF pages 1–5, 13, and 17–19 | Account adjacency, scientific identification, and corporate lineages require claim-specific provenance | | Stage 15 — governance and conclusion authority | PDF pages 2–3, 6–7, 16, and 20–22 | Financial jurisdiction, underwriting, relational rules, social-impact organization, and interruption determine who may act or conclude | **Authorization gap:** platform proximity, a followed account, shared conference space, vendor marketing, or a notebook relationship line does not prove access, control, employment, coordination, or interception. In pages 20–22, the relevant “interception” is explicitly conversational: a speaker's subject is redirected before transmission is complete. ## Scanned_20260730-1958 | Stage | Notebook evidence | Boundary or significance | |---|---|---| | Stage 0 — physical object and provenance | PDF pages 1, 6, 21, 26, 32, 35, 43, 46, 49, and 60 | Physical notebook, model labels, device families, and printed colophon; most unit-level serial/custody data remain absent | | Stage 1 — radio and access network | PDF pages 8, 26, and 32 | IMEI, Nighthawk 2.4/5 GHz modes, WPA/WPA2, Bluetooth Low Energy, and wearable discovery | | Stage 3 — pre-OS firmware and boot | PDF pages 35 and 44–45 | Intel MEBx, Intel RST/RAID option ROM, Easy2Boot, and grub4dos hotkeys | | Stage 6 — OS authority and services | PDF pages 3–5 | KDE/Akonadi/KIO, Xfce/xfdashboard, and Cockpit software-environment attribution | | Stage 7 — alternate execution substrate | PDF pages 5 and 34 | GNOME Boxes, KVM, and EVE-NG virtualization/network laboratory | | Stage 9 — interface and presentation | PDF pages 3–5 and 49 | Desktop components, browser/resource abstraction, and Nexus 5/Pixel 3 `blueline` label mismatch | | Stage 10 — local network and administration | PDF pages 4, 26, 34, and 38 | Cockpit, link-local address, mobile-router configuration, and Google administration | | Stage 11 — transport, cloud, and name resolution | PDF pages 9–17, 31, 38, and 50–51 | Owned domains, registrar control, hosted mail, DigitalOcean/Vultr, WHMCS, and historical domain lineage | | Stage 12 — attribution and provenance | PDF pages 3–6, 35, 46, 49, and 60 | Gray/[PERSON REDACTED] distinction, device-label translation, managed-device provenance, and source ownership ambiguity | | Stage 13 — enrollment and enterprise authority | PDF pages 7, 38, and 46 | Apple Business Manager, Google Admin, and CHISD Chromebook management | | Stage 14 — account, domain, and identity continuity | PDF pages 7–43 and 49–51 | Densest notebook layer: recovery mailboxes, phones, platforms, domains, registrars, vaults, backups, and administrators | | Stage 15 — governance and evidentiary standing | PDF pages 28–29, 40, and 53–54 | XRP/regulatory research, civic software, public institutions, escalation contacts, and trust notation | **Authorization gap:** a saved account, visible management banner, business-identity date, firmware menu, device codename, contact name, or redacted credential does not establish present authority, compromise, actor identity, transaction, deployment, or coordination. ## Scanned_20260803-1201 | Stage | Notebook evidence | Boundary or significance | |---|---|---| | Stage 0 — source and evidence integrity | PDF pages 1–24, 65–80; supplemental assets | Numbered envelopes, signatures, repeated object photographs, receipts, labels, REDACTED, and custody tokens; full physical custody manifest remains incomplete | | Stage 1 — physical and regulatory identity | PDF pages 5–7, 19–23, 65–70, 78–80 | ThinkPad/type/serial, Samsung memory, Lenovo FRU, Yoga return, REDACTED REDACTED, and valet token | | Stage 2 — payment and transaction identity | PDF pages 11–18, 28–46, 56, 65–76 | ATM/EMV fields, temporary debit, PO Box payment, savings/store cards, and questioned check; secrets redacted | | Stage 4 — storage and component authority | PDF pages 5–7 | Removable RAM physically isolated; storage media and forensic acquisition history absent | | Stage 12 — attribution and provenance | PDF pages 7–24, 47–50, 75–80 | Signed statements, source labels, institutional contacts, check annotation, REDACTED, and valet artifact require proposition-level corroboration | | Stage 14 — identity and continuity | PDF pages 1–4, 25–26, 38, 41–76 | Business contacts, corporate filing, PO Box, telecom, merchant, banking, family, and professional identity anchors | | Stage 15 — governance and evidentiary standing | PDF pages 41–49, 56, 59–64, 77–80 | USPS identity rules, police/FBI records, professional credentials, REDACTED access, and custody systems distribute institutional authority | **Authorization gap:** a receipt, signed statement, card, key, REDACTED, case number, check, or custody token does not by itself prove authorization, misconduct, final transaction outcome, present account state, or actor identity. This notebook primarily strengthens provenance and continuity rather than a technical interception claim. ### Devonshire backyard addendum | Stage | Added evidence | Boundary or significance | |---|---|---| | Stage 0 — source and evidence integrity | PDF page 27 plus [[Addendum - Devonshire Backyard Map and Router Discovery]] | Visible map separated from later owner-supplied interpretation and discovery account | | Stage 1 — physical device identity | Backpack inside garbage can beyond the fence behind the shed; concealed router powered and running | Exact hardware identifiers, photographs, uplink, and custody remain unresolved | | Stage 10 — local network administration | SSIDs `RedRider` and `REDACTED` | Broadcast names establish observed wireless identities, not administrator or ownership identity | | Stage 12 — attribution and provenance | Map found in [PERSON REDACTED]'s small book; `REDACTED` SSID | Object location and network names are evidence facts within the firsthand account, not automatic proof of who placed or operated the router |