Accessing the Hardware

Other than being a glorified calculator, software does one thing very well: It moves data from one place to another. In fact, moving data is sometimes more important than calculating data. No self-respecting power user would ignore the speed at which data can move: bus speeds, drive speeds, CPU speeds. It's all about moving data as quickly as possible.

Most of the hardware on the computer can be controlled with software via moving data and instructions to and from a microchip. Most hardware devices have a microchip that can be addressed somewhere.

Hardware Addresses

To move data to and from a microchip requires an address. Typically these addresses are known ahead of time and are hard-wired into the system. The address bus consists of many small wires, some of which are wired to each microchip. So, by specifying an address to write to in memory, you are really selecting a microchip.

Once selected, the microchip reads data from the data bus. This microchip then controls the hardware in question. Figure 8-2 illustrates how a microchip is selected by the address bus, and data is then read from the data bus.

Figure 8-2. The address bus selects a hardware controller chip; data is then read.

Most hardware has some sort of controller chip that exposes an addressable memory location, sometimes called a port. Reading and writing to a port may require special opcode instructions: Some processors have special instruction sets that must be used for communicating with ports.

On the x86 architecture, ports are accessed using the in and out instructions (to read from and write to the port, respectively). However, some chips are memory-mapped, and can be accessed using the more common move instructions (mov on the x86).

Regardless of the instruction used, an address will be required. This is how the motherboard will know where to route your data.

Addressing hardware can be complex. Just knowing an address is not enough. The following sections explain some of the challenges.

Accessing Hardware Is Not Like Accessing RAM

Hardware can behave strangely in that it doesn't operate like normal RAM. If you write to an address and then read from that address, the value you just wrote is not guaranteed to be read, even though you are using the same address for both operations. The read operation might be treated entirely differently than the write operation. This is because of latching.

Internal to the chip, a latching mechanism may select between two different registers depending on whether the operation is a read or a write. In Figure 8-3, a write operation writes to Register 2, while a read operation reads from Register 1.

Figure 8-3. Latching between two registers for read or write operations.

Timing Considerations

If you are writing to a flash chip, you must be aware that each write operation can take a short time to complete. If you write in a tight loop, you might find that, say, only every fifth byte actually takes the write operation. This is because you aren't waiting long enough for the write to complete before you move to the next byte. Usually a controller or flash-memory chip will require a short time before it will accept the next instruction. This time is usually measured in microseconds.

With the Windows kernel, you can use the KeStallExecutionProcessor call to stall for a given number of milliseconds.

The I/O Bus

The I/O controller chipset is the heart and soul of the machinery. Understanding how these chips operate is the key to getting to any piece of hardware on the system. The CPU (or multiple CPUs) usually share a single bus with the main memory (RAM). But add-on cards and peripheral hardware usually connect via a separate bus, and the only way to get to that other bus is via a controller chip (see Figure 8-4).

Figure 8-4. A bridge chip controls access to a secondary, peripheral bus.

Several buses can be accessed:

• the PCI bus

• the AGP bus

• the APIC bus

• the EISA and ISA bus

• the HyperTransport bus

• the LPC bus

• the Frontside bus

• the I2C bus

Some devices on the bus are able only to respond to requests initiated by the CPU. Other devices can initiate requests independent of the CPU. A device that initiates a request is sometimes called an initiator. Some devices "snoop" all transactions occurring on the bus. A device will "snoop" when it has a local memory cache and it needs to detect whether the cached memory address is being modified. For example, the main memory typically acts as the target of requests, does not initiate requests, and never snoops the bus. A CPU will act as the initiator of requests and will also snoop the bus in case another CPU or PCI device alters some cached memory.

Figure 8-5 illustrates a typical motherboard layout. This offers a basic template, but it is not the only way motherboards are configured. Specialized multifunction chips may replace large parts of the motherboard. For example, the Intel I/O Controller Hub (ICH) chips are known as "kitchen sink" I/O controllers because they do so much. They connect to the PCI bus; can handle USB, IDE, and audio; and may connect to an additional LPC (low pin count) bus.

Figure 8-5. A typical motherboard layout.

When exploring a system's buses, remember that every controller chip will translate a memory address on one bus into a totally different address on the next bus. Each bus has a bus-specific way of handling addressing. If you initiate a transaction from a device, it will likely need to be in the format expected on the bus to which that device attaches.

Accessing the BIOS

For the most part, the BIOS is used only to boot the computer. Modern operating systems make limited use of the functions provided by a BIOS. After bootstrapping and identifying the hard drives, the BIOS transfers control to the boot block on the boot-up device. The boot block takes control and boots the main operating system.

Modern BIOS chips are flashable, which means they can be updated using software. A famous virus, CIH, was designed to destroy the BIOS on a computer. This was incredibly destructive and expensive for people whose machines were infected with the virus. At the time of this writing, there are no public rootkits that infect the BIOS. However, the BIOS would be an interesting place to put a rootkit.

Accessing PCI and PCMCIA Devices

There is a lot of good stuff attached to PCI and PCMCIA buses, including wireless cards, network interfaces, and external drives. PCI devices can have their own on-board BIOS software. Putting a rootkit into a PCI BIOS is an interesting idea. Another idea is to use a device that can be inserted (such as a PCMCIA card or a USB key) and that modifies main memory to insert a rootkit.^[2]

^[2] This has been demonstrated to work with the Firewire port on some operating systems. At the time of this writing, some research is beginning to be released publicly regarding this approach.

Clearly there is a lot of complexity to the hardware environment more than perhaps is expected. There is also a lot of potential for hardware-level rootkit development: This subject could easily become a book of its own! To help you get started with hardware, we explore a simple example that works with the keyboard controller chip.