Android's Verified Boot Chain: How dm-verity and AVB Actually Detect Tampering

Somewhere between pressing a phone's power button and seeing the lock screen, a chain of signature checks either passes silently or fails loudly. Most people never think about it. That is kind of the point.

In this post

1. What verified boot is and why it exists
2. Boot is not one step, it is a relay race
3. dm-verity: checking the system partition, block by block
4. AVB: the layer that replaced ad-hoc verification with something standardized
5. What actually happens when something does not match
6. Why yellow is not the security downgrade people assume
7. Where this stops helping you
8. Why this matters even if you never think about it

Verified boot is one of the most important security mechanisms on a modern Android device, and it is also one of the least visible. Nothing in the normal user experience points to it. There is no settings screen, no notification, no prompt. It runs silently at every boot and either succeeds without comment or fails with a warning most users will never see. That invisibility is by design, but it also means most people have no idea what the mechanism does or why it matters.

What verified boot is and why it exists

Verified boot is a system that cryptographically checks each stage of the boot process before handing control to the next one. The goal is to ensure that the software running on the device is the software that was intended to run, and that nothing has been modified between the factory and the moment the user turns the device on.

The threat models it addresses are specific. A device that has been physically accessed by someone with malicious intent, a device that has been tampered with in transit between the manufacturer and the buyer, or a device that has had its firmware modified by malware with sufficient privileges to persist across reboots. In all of these cases, the goal is to prevent a compromised system from booting as if nothing had happened, and to give the user a visible indication that something is wrong if it does.

Without verified boot, a device that has been tampered with at the firmware level could boot normally, look normal, and run whatever code the attacker had placed on it, with no way for the user to know. Verified boot closes that specific gap.

Boot is not one step, it is a relay race

Every time a device powers on, several distinct pieces of software hand control to each other in sequence. The relay begins with a piece of read-only boot ROM burned into the chip, then a bootloader, then the boot partition holding the kernel and initial ramdisk, and eventually the full Android system.

Verified boot is the practice of each stage cryptographically checking the next one before handing off control, rather than blindly trusting whatever happens to be sitting in that partition. The chain of trust is unbroken from the hardware to the operating system, with each link verifying the next.

The chip's boot ROM is the anchor. It is immutable, burned in at manufacturing, and it holds or trusts a certificate for the key used to verify the bootloader. If that first check fails, most devices simply refuse to continue. This is why a corrupted or malicious bootloader typically results in a bricked-looking device rather than a compromised one that boots anyway. The system would rather not boot at all than boot into an untrusted state.

dm-verity: checking the system partition, block by block

Once the bootloader trusts the kernel, the kernel still has to trust the system partition it is about to mount. This is where dm-verity comes in. It is a device-mapper target in the Linux kernel that sits between the block device and the filesystem, checking each block read against a hash tree built at build time.

Any block that does not match its expected hash gets treated as corrupted, and depending on configuration, the read either fails or the device flags it and, on newer setups, refuses to continue booting into a modified system state. The behavior is deliberate: there is no way to silently return corrupted data to the caller, because the entire purpose is to make corruption or tampering visible rather than hidden.

This is a genuinely elegant piece of engineering. It does not hash the whole partition every boot, which would be painfully slow. It builds a Merkle tree once, at image-build time, so verifying any individual block only requires walking a short path up that tree rather than re-hashing gigabytes of data on every read. The root of that Merkle tree, a single 32-byte hash, is what actually gets signed. Everything else derives its trust from that one value.

Why the Merkle tree approach matters: a device can verify the integrity of its entire system partition on every boot without paying a full re-hashing cost. Only the blocks actually read need to be verified, and each one only requires a handful of hash computations to check against the root. This is what makes block-level verification practical at boot time, rather than a theoretical protection that would slow startup to an unusable crawl.

AVB: the layer that replaced ad-hoc verification with something standardized

Android Verified Boot, usually just called AVB, is Google's more structured successor to earlier, more fragmented verification schemes. Rather than each partition having its own bespoke verification logic, AVB defines a common structure called vbmeta that stores the root hashes and signatures for multiple partitions in one place, itself signed by a single key.

The bootloader checks vbmeta first, and vbmeta in turn vouches for everything downstream. This design has several practical advantages. It centralizes the trust decision in one signed structure, making it easier to reason about what is and is not trusted. It also supports rolling keys, which allow a device's verification keys to be rotated or replaced under controlled conditions, for example during a legitimate system update or a planned key compromise recovery.

Google's own AVB specification, kept in the Android source tree, documents the exact structure and rolling-key mechanisms in more depth than any summary can do justice to. For anyone implementing verified boot on a custom device or auditing an existing one, reading the specification directly is worth the time.

What actually happens when something does not match

This is where a lot of casual explanations get vague, so it is worth being specific. AVB defines several boot states, not just pass or fail:

State	What it means	What the user sees
Green	Every partition verified against the device's original, locked root of trust	Normal boot, no visible indication
Yellow	Verification succeeded, but against a custom key the user has explicitly installed	Orange triangle warning on some devices, otherwise normal boot
Orange	The bootloader is unlocked; verification either not happening or against a user-controlled key	Boot warning screen on most devices, boot proceeds
Red	Verification actively failed	Boot may halt entirely, depending on device policy

The nuance most discussions skip is that yellow is not less secure in the way people assume. A yellow state with a locked bootloader and a deliberately, knowingly installed custom key still gives tamper-evidence. If someone modifies the custom ROM without the user's knowledge afterward, verification against the user's own key still catches it. What is lost relative to green is not detection, it is the guarantee that the key itself has not been swapped by someone with physical or exploit-based access to the device.

The distinction between yellow and orange matters more than most explanations suggest. Yellow means the bootloader is still locked and verification is still active, just against a key the user chose rather than the manufacturer's. Orange means the bootloader is unlocked and verification is effectively not happening in any meaningful sense, because whoever modified the partition could also have re-signed it with their own key. The security posture of these two states is very different, even though both involve a non-manufacturer key.

Why yellow is not the security downgrade people assume

A common misconception is that any departure from the stock green state weakens the device's security. In practice, the specific state matters significantly, and yellow is often chosen deliberately by users who want a signed custom ROM with the bootloader still locked.

In that configuration, the device still refuses to boot if the ROM has been modified without re-signing against the user's key. Tamper-evidence remains intact. What is different is who holds the signing key and what happens if that key is compromised. In the green state, the manufacturer's key is used, and the manufacturer has infrastructure and policies around its protection. In the yellow state, the user's own key is used, and the security of that key depends entirely on how the user protects it.

For most users choosing a yellow configuration, the trade-off is acceptable. They gain the ability to run a custom ROM with a locked bootloader, and they accept the responsibility of managing their own signing key. It is a deliberate choice, not a degradation.

Where this stops helping you

Verified boot has clear boundaries, and understanding them prevents overestimating what it provides.

None of this checks whether the original software was good software. A stock system image, correctly signed, passing every single AVB and dm-verity check with flying colors, can still ship with a tracker-laden preinstalled app or a genuinely bad security decision baked into the OS itself. Verified boot only confirms that what is running is what was signed, not that what was signed deserved to be trusted in the first place.

Rooting removes this protection almost entirely on most devices, because gaining root typically requires modifying the system partition, which breaks the hash tree the moment it happens. That is covered from a different angle in an earlier piece on this blog about the actual security trade-offs of rooting, if the fuller picture on that specific decision is useful.

Verified boot also does nothing at all about anything that happens after boot completes. Malware installed as a regular app, a phishing page loaded in a browser, a malicious permission grant approved without reading, none of these are affected by verified boot because the boot process has already finished by the time any of them becomes relevant. It is a boot-time integrity guarantee, full stop, not a general malware defense.

A useful way to think about it: verified boot is a narrow but deep guarantee. It covers a specific window (boot time) and a specific threat (tampering with the software that runs), and it covers both thoroughly. It does not cover the much broader surface of post-boot activity, and expecting it to would be misplacing trust in the wrong control.

Why this matters even if you never think about it

Most people will never see a boot warning in their entire time owning a phone, and that is exactly the outcome this system is built to produce. The value is not in a scary warning screen. It is in the fact that a stolen or physically accessed device becomes drastically harder to silently compromise at the firmware level and hand back to its owner as if nothing happened.

That is a specific, narrow threat model. Evil-maid attacks, supply chain tampering, physical access scenarios. But it is a real one, and it is quietly running underneath essentially every Android device sold in the last several years, checking its own integrity a few dozen times before the lock screen ever appears.

For developers building on Android, the practical implication is that verified boot is a foundation worth relying on rather than duplicating. Apps that assume the underlying system has not been tampered with can build on that assumption for the vast majority of devices. For users making decisions about rooting or custom ROMs, the implication is that verified boot is one of the concrete things being traded away, and the trade-off deserves explicit consideration rather than being treated as a formality.

Conclusion

Verified boot is the kind of security mechanism that works best when nobody has to think about it. The chain of trust from boot ROM to bootloader to kernel to system partition is long, the cryptographic machinery supporting it is sophisticated, and the result is a device that either proves its own integrity at every boot or warns the user in a way that cannot be easily suppressed.

The limits of the protection are as important as the protection itself. Verified boot does not make a device secure in general. It makes one specific class of attack, silent firmware-level tampering, dramatically harder and more detectable. That is a narrower claim than a lot of security marketing implies, but it is a claim that holds up under scrutiny, and it is quietly operating on every Android device that has shipped in recent years.

Key Takeaways

• Verified boot cryptographically checks each stage of the boot process before handing control to the next
• The boot ROM anchors the chain of trust and cannot be modified after manufacturing
• dm-verity checks the system partition block by block using a Merkle tree built at image time
• AVB standardizes verification through the vbmeta structure, replacing per-partition bespoke logic
• Boot states include green, yellow, orange, and red, each with distinct security implications
• Yellow with a locked bootloader is not the same as orange with an unlocked one
• Verified boot does not protect against malware installed after boot or bad software that was correctly signed
• Its main value is preventing silent firmware-level tampering on physically accessed devices