coolelectronic blog

home | github | fediverse

Breaking chromeOS's enrollment security model: A postmortem

<- prev postnext post ->

Hello! This is the true finale to the enrollment bypassing saga, make sure to read the other parts.

Also! this is a story, not a guide. if you want a guide for unenrollment, see this!

The tsunami (fog 2.0)

As per the normal mercury rituals, OlyB was scanning chromium code search one night and found this commit, which immediately set off alarms. If you remember from part 5, we were able to circumvent the forced blocking of devmode by disabling the hardware write protection and setting GBB flags. This commit, once released in an update would stop you from disabling hardware write protect entirely when the chromebook was enrolled. This breaks normal RMA shims too funnily enough which they later realized and also unfortunately makes repairing enrolled chromebooks much more difficult/impossible if you have to legitmately do repairs and don’t have access to the official manufacturer factory toolkit, which is very difficult to get into.

Since we saw the commit as it was added, it hadn’t been released yet and we had some time to prepare, you could still set the gbb flags from last part before you updated and you would permanently be able to unenroll whenever you wanted to, and note that e-halcyon has nothing to do with write-protection and still works, without any need to take apart your chromebook.

To summarize, once updated to R114 and enrolled:

So, what even is write protection?

Let’s start with the basics. On every computer, chromebooks being no exception, the boot process starts with the motherboard firmware. On ChromeOS, this is where booting recovery images and from the internal storage starts from, it’s the root of the trust model. So if it was able to be arbitrarily written to by anything, that would be pretty bad, wouldn’t it?? As such, writing to the firmware is protected under certain conditions. That’s what write-protection means, at the lowest level. However this is google we’re talking about, so things get a lot more complicated, and write-protection ends up meaning a couple different things.

On modern chromebooks, the write-protected portion of the firmware is unlocked by the cr50, either when the battery is unplugged (which requires disassembling the chromebook), or using the RMA open method (which requires codes that you need certification from a manufacturer to obtain). As of the recent patch, the cr50 will refuse to unlock the write protection on the firmware when enrolled.

But what if we were able to bypass the cr50, and unlock the write protection anyway? Let’s get even lower level.

the pencil bypass

Note: This article lists pins 3 and 4 as the ones you need to bridge to disable write protect, but this is a mistake. You actually need to bridge pins 3 and 8 for this to happen. Read the datasheet for the Winbond flash chip for more information.

If you open up the back of the chromebook, you can actually see the individual chips for the cr50 and firmware rom.
While the cr50 is weird proprietary google stuff, the firmware is handled by an off-the-shelf SOIC-8 chip. You can even flash it externally with a ch341a, more or less the same way you would flash an arduino. But that’s not what we’re interested in here. the schematic for the SOIC-8 chip where the firmware is stored Anyway, here’s the schematic for the rom chip used in most chromebooks. The pin that has the text “WP” is what controls whether write-protection is enabled on the chip itself. If you look very closely at the board, you might even be able to see the trace running from the cr50 to the write-protection pin. When the pin is connected to a power line, write protection is on. When the pin is connected to ground, write protection is off.

Can you see where I’m going with this?

Fortunately for us, the WP pin and ground pins are directly next to eachother. If you were to short them together with… oh, let’s say a pencil… an image showing the SOIC-8 chip and the pins you need to short to disable WP Then there would be absolutely nothing stopping you from doing whatever you want to the firmware.

The GBB flags are stored in a partition of firmware typically protected from writing. So from the sh1mmer bash shell, making sure the pins are properly shorted with the connecting instrument of your choice, run /usr/share/vboot/bin/set_gbb_flags.sh 0x8000 and the command will succeed, writing directly to the SOIC-8 chip and allowing you to boot into devmode, where you can fully remove enrollment. As it’s a hardware level bypass, this is virtually unpatchable (outside of rotating the rma shim keys).
Even though you can write directly to the firmware, the cr50 still thinks write-protection is enabled, so any scripts that check if you have write-protection enabled will say that you do (raw rma shims will still act as if you have WP on)

I shouldn’t have to say this but yes, sticking random metal objects into sensitive chips on your chromebook is a very bad idea, if you choose to do this be very careful.

With mitigation patches applied to chromeos, google considers unenrollment via sh1mmer fully patched and will likely never roll the keys to make the image itself unbootable, so E-Halcyon will remain bootable forever and you’ll be able to unenroll whenever you want with the pencil method on the boards affected by sh1mmer.

Still, the clock is ticking. Newly released chromebooks won’t be affected by sh1mmer, and the ones that are affected will slowly fall out of relevance

So have fun while it lasts, because google will probably never mess up as badly ever again.
And no, this isn’t a joke or elaborate troll, it does actually work

Credits