A wiper overwrote a disk's first sector: why is the machine dead but the data is not?

## Two different things are being destroyed A destructive payload can attack **the data** or **the machine's ability to start**, and they are not the same target. Confusing them leads to the two classic wrong answers: "the disk was wiped, everything is gone" when almost nothing is gone, and "it still boots from rescue media, so we are fine" when the file contents were shredded. ## What actually lives at the front of a disk On an MBR-partitioned disk, logical block address 0 is 512 bytes laid out as roughly 440 bytes of bootstrap code, a 4-byte disk signature, two null bytes, a 64-byte partition table of four 16-byte entries, and the two-byte `0x55AA` marker. That single sector is the entire map. Each 16-byte entry says where a partition starts and how long it is; without it, the operating system sees a device with no volumes on it, and legacy firmware has no code to jump to. GPT-partitioned disks are laid out differently and, importantly, redundantly: LBA 0 carries a protective MBR, LBA 1 the primary GPT header, the following sectors the partition entry array — and a **backup header and entry array live in the last sectors of the disk**. A payload that only stamps on the front of a GPT disk has destroyed one of two copies of the map. That redundancy is a real difference in outcome between two disks hit by the same code. ## Escalating levels of damage Roughly in increasing order of what it costs the victim: 1. **Boot code and partition table only.** The host will not start. Volumes are unreadable until the map is reconstructed. File contents are entirely intact. 2. **Filesystem metadata.** Overwriting or encrypting the structures that name files and list their clusters — the master file table on NTFS, inode tables and superblocks on ext-family filesystems — leaves the data blocks on the platter with nothing pointing at them. Carving fragments back is possible in principle and is not a plan for a fleet. 3. **Bulk overwrite of the device.** A pattern written across the whole disk. Now the data really is gone, and this is the slow option — which is exactly why a payload that wants an estate down within a minute of triggering does not choose it first. Mature destructive payloads often combine them: trash the boot path so the host is down immediately and cannot be interrupted, and grind through file contents in the background for as long as the host survives. ## Why the operator picks the cheap target A destroyer is buying downtime per second of execution. Writing a few kilobytes at fixed offsets on every reachable host is the highest damage-per-byte operation available, it needs no enumeration of what is valuable, it finishes before anyone can react, and it scales to an estate through whatever push mechanism the operator already has. Data destruction is the expensive follow-on. Reading the damage this way — cheap-first, then grind — also predicts what you will find on hosts that were powered off partway: a broken boot path and a mostly intact filesystem. ## What it means for the victim The loss on a boot-path-only wipe is **time and people**, not information: hundreds of endpoints that each need to be re-imaged, on an estate whose imaging infrastructure may itself be down. That is a materially different conversation from "our data is gone" and it is worth getting right early, because the two produce completely different outage estimates and completely different messages to the people waiting on the systems. The control class that removes what this technique depends on is also different from the one that answers data loss. This technique needs (a) code executing with raw device write access, which on a normal host means administrator or root, and (b) a way to reach every host at once. Take away the second and the payload stops being an estate-wide event even when it works perfectly on one machine. ## The boundary How you reconstruct a partition table, what firmware does before handing over control, and how a boot loader chain is repaired are operating-system topics with their own depth. What belongs here is the adversary's calculation: which structure to hit, in what order, for the most downtime per second of execution — and what each choice predicts about whether the bytes are still there.