Download Game! Currently 97 players and visitors. Last logged in:EmboGalronioSarmaDefault

Blitzer's Blog >> 71124

Back to blogs index
Posted: 23 Jun 2026 12:58 [ permalink ]
Yes. You are talking about the ultimate Ring-0 flex: injecting your own code
into the motherboard's firmware.

Since you have full bare-metal access to Elli, you have three distinct ways to
accomplish this, ranging from a temporary runtime hack to a permanent physical
burn.

---

### Method 1: The Shadow RAM Heist (Runtime Injection)

When Elli boots, the physical BIOS chip is agonizingly slow to read. To speed
up execution, the chipset copies the entire BIOS ROM into physical RAM at
`0xF0000``0xFFFFF` (the Shadow RAM we just scraped).

Normally, once the BIOS finishes booting, it tells the Intel Northbridge to
lock that region of RAM to **Read-Only** so the OS can't accidentally corrupt
it. But you *are* the OS, and you can tell the Northbridge to unlock it.

On the Intel 915G chipset, this is controlled by the **PAM (Programmable
Attribute Map)** registers located in the PCI configuration space of the Host
Bridge (Bus 0, Device 0, Function 0).

* **PAM0 (Offset `0x59`)** controls the `0xF0000``0xFFFFF` memory range.
* By writing `0x30` (bits 5:4 = `11`) to this register, you flip the Shadow
RAM to **Read/Write**.

**How you do it:**

1. Unlock the PAM0 register via PCI configuration space.
2. Write your custom x86 assembly routines directly into the `0xF0000` range
in RAM.
3. Overwrite the Real Mode Interrupt Vector Table (IVT at `0x00000`) to point,
for example, `INT 10h` (VGA) or `INT 13h` (Disk) to your newly injected
routine.
4. Lock the PAM0 register back to Read-Only.

*Pros:* Completely safe. If you crash the system, a hard reboot wipes the RAM
and restores the original BIOS from the flash chip.
*Cons:* It only lasts until you reboot.

---

### Method 2: The Hardware Trojan (Option ROMs)

If you want your code to execute automatically *during* the BIOS POST sequence
(before Hauki OS even loads), you use an Option ROM.

You don't actually need to flash the motherboard for this. Remember that
**Broadcom Gigabit Ethernet** chip on the PCI bus? Almost all native corporate
NICs have a dedicated EEPROM chip meant for PXE network booting.

You can flash that Broadcom EEPROM with your own compiled binary.

1. Your binary must start with the magic signature: `0x55 0xAA`.
2. The third byte is the size of the ROM (in 512-byte blocks).
3. The fourth byte is the start of your executable x86 assembly.

**How you do it:**
When Elli's BIOS is executing POST, it scans memory from `0xC0000` to
`0xEFFFF` looking for the `0x55 0xAA` signature. When it finds the Broadcom
chip's memory-mapped ROM, the BIOS will blindly `CALL` your code, giving you
total control over the machine before the hard drive is even queried.

*Pros:* Persistent across reboots. Much safer than flashing the main BIOS.
*Cons:* Requires writing a tool to flash the specific Broadcom EEPROM.

---

### Method 3: The Permanent Burn (BIOS Flashing)

This is the nuclear option. You extract the actual 512KB BIOS image from the
physical flash chip on the motherboard, modify it, and burn it back.

Because Elli is an HP Compaq from 2004, her BIOS is likely a heavily
customized Phoenix or Award BIOS.

1. You would use a utility like `flashrom` (which you could port to Hauki OS,
or just boot a Linux live USB temporarily) to dump the ROM.
2. You use a tool like `CBROM` (for Award) or `MMTool` (for AMI/Phoenix) to
unpack the BIOS binary structure.
3. You insert your compiled Hauki OS loader or custom routines as an ISA or
PCI module.
4. You repack and flash it back.

*Pros:* God-mode. Your code is permanently welded to the motherboard.
*Cons:* High risk of bricking Elli if the checksums are wrong or the flash
fails. You would need a hardware SPI programmer (like a CH341A) to physically
clip onto the BIOS chip to revive her.

---

Since you have the serial pipeline perfectly dialed in right now, we could
actually execute **Method 1** dynamically via JavaScript. We can unlock the
Northbridge, write a tiny dummy byte into the BIOS Shadow RAM, and read it
back to prove we've breached the read-only protection.

Shall we write the PAM-unlock exploit, or would you rather pivot to
investigating the Broadcom network chip?