A secure boot bypass in Chromecast with the Google TV (CCwGTV)’s 1080p revision. This bypass sort of involves two issues, a hardware fault injection and a software logical bug, and this is due to mitigations and efforts Google has made since the exploit chain that was released against the 4K model previously.

eMMC Fault Injection In order to get a u-boot shell, they needed a delay during bootloader execution. Google has made this more difficult in software by setting CONFIG_AUTOBOOT_DELAY=-2. What they discovered was that by shorting the embedded MultiMedia Card’s (eMMC) DAT5 pin at a specific time in the boot, they could have the boot process pause to allow a u-boot shell like before.

Logic bug in update functionality Another attack Google mitigated was the attacker changing the lock environment variable value to one that disabled signature checks in the boot process. To protect against this, Google now only allows the lock environment variable to be changed on development boards, which is checked via One-Time Programmable (OTP) fuses. Luckily, the researchers discovered a bug in the update functionality where it can disable Android Verified Boot (AVB), or more specifically set a flag that allows AVB verification errors to pass through and still return a success code.

This is because the AVB check had an if condition, if (is_device_unlocked() || !strcmp(upgradestep, "3")), which if true would set the AVB_SLOT_VERIFY_FLAGS_ALLOW_VERIFICATION_ERROR flag. It’s suspected this is a logical operator misuse where OR shouldn’t have been used here. This is significant because upgradestep ultimately comes from the upgrade_step environment variable, which attackers can control with a u-boot shell. By simply setting upgrade_step=3, AVB can be bypassed with no indication the boot integrity has been subverted.

Persistence Another interesting thing they noticed is that the Bootloader Control Block (BCB) was not checked or signed. The BCB is basically passed directly into the u-boot shell, and so by placing the setenv upgrade_step 3 command in ther , they could disable AVB on the subsequent boot. The init script would just continuously set that variable up for each sequential boot to root the device persistently.