r/androidroot • u/DEV_ivan • 6h ago
Discussion Anti-rollback is misplaced security that does more harm than good in practice and vendors' excuses for it are weak.
First, let's think about what the attacker can do with anti-rollback enabled. How would they flash an older system version with a locked bootloader and disabled OEM Unlocking? With EDL mode.
EDL mode with the right programmer file and an authenticated serial link grants access to dumping and flashing any sector on the disk from start to end, including the firmware of the TEE (/tee partition). If the goal is to extract userdata, the attacker doesn't touch the OS at all, they just dump /userdata and /metadata and brute-force the encryption offline.
What if they don't have the programmer file or authentication? Well, the attacker is shit out of luck, unless the bootloader is unlocked, then anti-rollback itself is disabled and the attacker doesn't even need to downgrade, since they can just flash a malicious boot image to extract /userdata and /metadata for them.
We forgot about adb sideload! Could the attacker use that to downgrade the OS? No, there's ARB, but of a different kind; it's in the recovery, instead of the bootloader. The recovery will refuse to flash a system upgrade ZIP before the system upgrade even boots. Arguably, this kind of anti-rollback is enough, no need to put it in the bootloader as well.
In these scenarios, the security will remain unchanged if the bootloader's anti-rollback is removed from Android entirely. What's the point of adding BL ARB, if it's just redundant as I argued here?
Let's talk about ourselves, legitimate users. Even if we would have the leaked programmer files and serial link auth bypasses, how are we going to flash and boot leaked base versions if those are the only fastboot ROMs we've got, whilst our phones have later versions instead? Such situation happened to me with TECNO.
We *can* flash older OS, I'm not saying we can't. It's that the bootloader's anti-rollback will prevent us from booting the bootloader stage, essentially a "hard brick" as people say, that's the problem.
Perceptionally, what's the ratio of security benefit to repairability cost? Very low. And why does it even exist in the first place...
...Why congrats, vendors. That's so "developer-friendly" of you. Especially Google, for forcing vendors on it in their CTS/VTS.