Rootkits and Bootkits

Three researchers who spent years reverse-engineering the real families - TDL3, Festi, Olmasco, Rovnix, Carberp, Gapz - wrote the definitive account of a narrow subject: code that gains control before the operating system's own defences exist. The structure alternates between explaining a link in the boot chain and dissecting the malware that attacked it.

Two modules cite it, for the boot process and for firmware. It is the deepest book on this shelf and the one with the narrowest subject, and both of those are worth knowing before you open it.

Why it is on this shelf

Because a disk image challenge frequently turns on a region of the disk that is not part of any filesystem, and this is the book that explains what lives there. Sector zero, the space before the first partition, the boot record of a volume - a filesystem tool walks straight past all of it.

Chapter 5, Operating System Boot Process Essentials

The chain, one link at a time. Firmware runs first and selects a boot device. On a legacy system it loads the master boot record from the first sector, which holds the partition table and enough code to find the active partition. That hands off to the volume boot record and its initial program loader, which understands the filesystem well enough to load the boot manager, which reads its configuration data and loads the kernel.

Each link is a place a challenge can hide something, and none of them are files. The master boot record is a single sector with sixty-four bytes of partition table and a two-byte signature at the end, which leaves several hundred bytes of code space that nothing checks. The gap between the record and the first partition is conventionally unused. A volume boot record has the same shape one layer down.

The principle the whole chapter rests on is that each stage trusts the next because it has no way not to: there is no filesystem yet, no driver stack, and until recently no verification. That is why the boot chain was such fertile ground, and why boot process forensics starts by reading raw sectors rather than mounting anything. Practical Forensic Imaging is where the offset arithmetic to reach them is explained.

Chapter 16, UEFI Firmware Vulnerabilities

What replaced the legacy chain, and the vulnerability classes it brought with it. UEFI is a small operating system in its own right - a driver model, a filesystem on a dedicated partition, network capability, a shell - and that surface has the bugs a surface that size has: unsigned or badly verified update images, insufficiently locked flash regions, and system management mode, a processor mode more privileged than the kernel with its own memory that the kernel cannot inspect.

For firmware challenges the transferable content is the structure of an image. A UEFI firmware volume is a nested container of files and sections, each with headers, often compressed, and unpacking it is a matter of walking those headers rather than guessing. The firmware unpacker does the walking, and firmware and IoT challenges covers what to look for once it is open. Practical IoT Hacking is the friendlier introduction to the same material.

The update-verification material makes the same distinction that runs through this whole shelf: a checksum proves a file is intact, a signature proves who made it, and a boot chain that verifies only the former will boot anything.

Chapter 18, Approaches to Analyzing Hidden Filesystems

The forensic payoff. Several of these families stored their components in a hidden filesystem: a region of the disk outside any partition, holding a small custom filesystem of the malware's own design, often encrypted, reachable only through the rootkit's own driver.

The chapter covers both ways in. On a live system the rootkit is intercepting storage requests, so reading the region means going below the interception, by hooking the miniport storage driver and issuing requests underneath. On an offline image none of that applies, and the problem becomes recognising a filesystem nobody documented: find the region, identify its structure from repeated headers and offsets, and write a parser.

That second problem is a CTF problem exactly. A blob with internal structure and no documentation is the same puzzle Attacking Network Protocols solves on a wire, and the same tools apply - the hex viewer to find the repetition, struct pack and unpack to test a hypothesis about the header, and disk image forensics for the surrounding method. High-entropy content in that region means encryption, and the key is in the driver that reads it.

Where it stops

It is narrow and it is hard. Whole chapters dissect one malware family's code, in x86 assembly, on the assumption that you can already read it. There is nothing here about user-space malware, nothing about non-Windows systems, and nothing about analysis workflow in general.

It is also from 2019, and secure boot, verified firmware update and hardware-backed measurement have made most of these attacks historical on current hardware. Read it for the architecture, which is unchanged, rather than for the current threat.

What to take into a challenge

Remember the space the filesystem does not describe. Sector zero, the gap before the first partition, the tail of the last one, and any region a partition table does not claim are all real storage that ordinary tools will never show you, and a challenge author who wants to hide something knows that too.