[RELEASE] Chromecast with Google TV 4K (sabrina) Bootloader Unlock

[npjohnson]

Hi,

I am having an issue with my newly unlocked ccwgtv. I ran through the unlock script, selected disable updates, flashed the modified image and installed the recovery. I went to use it today and it is stuck on the 'G' while booting up? I was under the impression that OTA was disabled via the unlock script. Is my device bricked permanently?

it is disabled. Not sure why this has happened. Try re-running the exploit?

 

[GroundControl2MT]

it is disabled. Not sure why this has happened. Try re-running the exploit?

I had tried about a dozen times and it hasn't booted into fastboot again. there are two kinds of out comes from running the unlock script

 libusb_bulk_transfer[820]: transferred=0
libusb_bulk_transfer[821]: transferred=0
libusb_bulk_transfer[822]: transferred=0
- exploit: sending last transfer to overwrite RAM...
libusb_bulk_transfer: transferred=140
- exploit: done.
[LUSB][AMLC]dataSize=16384, offset=65536, seq 0
[LUSB]requestType=0
[LUSB]ERR(L1016):Fail in down data, want 16384, but -110
[LUSB]ERR(L1187):fail in download, sequence 0

 libusb_bulk_transfer[821]: transferred=0
libusb_bulk_transfer[822]: transferred=0
- exploit: sending last transfer to overwrite RAM...
libusb_bulk_transfer: transferred=140
- exploit: done.
[LUSB][AMLC]dataSize=16384, offset=65536, seq 0
[LUSB]requestType=0
[LUSB]before wait sum
[LUSB]check sum OKAY
[LUSB][AMLC]dataSize=49152, offset=344064, seq 1
[LUSB]requestType=0
[LUSB]before wait sum
[LUSB]check sum OKAY
[LUSB][AMLC]dataSize=16384, offset=229376, seq 2
[LUSB]requestType=0
[LUSB]before wait sum
[LUSB]check sum OKAY
[LUSB][AMLC]dataSize=49152, offset=245760, seq 3
[LUSB]requestType=0
[LUSB]before wait sum
[LUSB]check sum OKAY
[LUSB][AMLC]dataSize=49152, offset=294912, seq 4
[LUSB]requestType=0
[LUSB]before wait sum
[LUSB]check sum OKAY
[LUSB][AMLC]dataSize=16384, offset=65536, seq 5
[LUSB]requestType=0
[LUSB]before wait sum
[LUSB]check sum OKAY
[LUSB][AMLC]dataSize=1586176, offset=81920, seq 6
[LUSB]requestType=0
[LUSB]before wait sum
[LUSB]check sum OKAY
[LUSB]BL2 END, waiting TPL plug-in...

I assume the second one is what I want to see, but it will not boot to fastboot afterwards on either outcome. How would I boot it into recovery?

 

[npjohnson]

I had tried about a dozen times and it hasn't booted into fastboot again. there are two kinds of out comes from running the unlock script

 libusb_bulk_transfer[820]: transferred=0
libusb_bulk_transfer[821]: transferred=0
libusb_bulk_transfer[822]: transferred=0
- exploit: sending last transfer to overwrite RAM...
libusb_bulk_transfer: transferred=140
- exploit: done.
[LUSB][AMLC]dataSize=16384, offset=65536, seq 0
[LUSB]requestType=0
[LUSB]ERR(L1016):Fail in down data, want 16384, but -110
[LUSB]ERR(L1187):fail in download, sequence 0

 libusb_bulk_transfer[821]: transferred=0
libusb_bulk_transfer[822]: transferred=0
- exploit: sending last transfer to overwrite RAM...
libusb_bulk_transfer: transferred=140
- exploit: done.
[LUSB][AMLC]dataSize=16384, offset=65536, seq 0
[LUSB]requestType=0
[LUSB]before wait sum
[LUSB]check sum OKAY
[LUSB][AMLC]dataSize=49152, offset=344064, seq 1
[LUSB]requestType=0
[LUSB]before wait sum
[LUSB]check sum OKAY
[LUSB][AMLC]dataSize=16384, offset=229376, seq 2
[LUSB]requestType=0
[LUSB]before wait sum
[LUSB]check sum OKAY
[LUSB][AMLC]dataSize=49152, offset=245760, seq 3
[LUSB]requestType=0
[LUSB]before wait sum
[LUSB]check sum OKAY
[LUSB][AMLC]dataSize=49152, offset=294912, seq 4
[LUSB]requestType=0
[LUSB]before wait sum
[LUSB]check sum OKAY
[LUSB][AMLC]dataSize=16384, offset=65536, seq 5
[LUSB]requestType=0
[LUSB]before wait sum
[LUSB]check sum OKAY
[LUSB][AMLC]dataSize=1586176, offset=81920, seq 6
[LUSB]requestType=0
[LUSB]before wait sum
[LUSB]check sum OKAY
[LUSB]BL2 END, waiting TPL plug-in...

I assume the second one is what I want to see, but it will not boot to fastboot afterwards on either outcome. How would I boot it into recovery?

Try the repair script

 

[Deleted member 11959327]

FWIW - Android 12 with Android 10 TEE applets and bootloader boots on deadpool - so I bet Sabrina will be the same.

The good news is this will surely be a full OTA image, so it will be easy to get a custom stock image built once people get me the update URL.

It is a full ota. How easy will it be to get a custom stock image?

It is worth spending some time to be sure the new build, apart from the bootloader, doesn't have any new method(s) to mess anything up?

stte.220621.019.A2/9082754, full ota:
(reminder: this ota contains dangerous bootloader, and who knows what else?)

h..ps://android.googleapis.com/packages/ota-api/package/f42e640142aef0a1cae86082cff738f919a5ca43.zip

 

[npjohnson]

It is a full ota. How easy will it be to get a custom stock image?

It is worth spending some time to be sure the new build, apart from the bootloader, doesn't have any new method(s) to mess anything up?

stte.220621.019.A2/9082754, full ota:
(reminder: this ota contains dangerous bootloader, and who knows what else?)

h..ps://android.googleapis.com/packages/ota-api/package/f42e640142aef0a1cae86082cff738f919a5ca43.zip

I'll lyk, but it's likely I have the best news I've had in a long time.

 

[volkodav1975]

I'll lyk, but it's likely I have the best news I've had in a long time.

For those whose bootloader is blocked, does this new item not work?

 

[Deleted member 11959327]

it's likely I have the best news I've had in a long time.

ooh, how tantalizing!

the "best news" would have to be something like the fuse burning routines being left out of the new s bootloader, or a new exploit that could liberate the currently imprisoned devices.

there are some bug reports already for stte.220621.019.A2/9082754, so there will probably be another ota soon.

in case you want to manage your news announcement accordingly, unless the "best news" is not sabrina specific.

 

[Deleted member 11959327]

For those whose bootloader is blocked, does this new item not work?

The oem unlocking toggle in developer options is a case of form over function. In this case there is probably no function.

 

[npjohnson]

For those whose bootloader is blocked, does this new item not work?

This was the news - I reported the non-unlockable status and was told it was just a bug that would be fixed, even had relevant CL's on AOSP Gerrit.

Looks like they messed something else up, which is greaaaaaaat.

ooh, how tantalizing!

the "best news" would have to be something like the fuse burning routines being left out of the new s bootloader, or a new exploit that could liberate the currently imprisoned devices.

there are some bug reports already for stte.220621.019.A2/9082754, so there will probably be another ota soon.

in case you want to manage your news announcement accordingly, unless the "best news" is not sabrina specific.

The oem unlocking toggle in developer options is a case of form over function. In this case there is probably no function.

see above, am sad atm. Maybe they'll get it right on the next OTA.

This was all related (the fact this wasn't unlock able ever) to a bug in TVSettings where it didn't check for the OEM unlock prop but instead checked for the presence of an frp partition (an invalid case).

 

[Deleted member 11959327]

(the fact this wasn't unlock able ever) to a bug in TVSettings where **it** didn't check for the OEM unlock prop but instead checked for the presence of an frp partition (an invalid case).

When you say "where **it** didn't check for the OEM unlock prop", what is it? Something on the OS side?

Even if the OEM unlock prop was properly checked (instead of checking for the presence of an frp partition), how would the bootloader ever recognize any of this unless it was specifically coded to do so?

It seems to me that this oem unlocking toggle in developer options is meaningless unless the bootloader is crafted to observe the toggle, even when the toggle is properly functioning. For various reasons, the bootloaders on phones are so crafted, but the bootloaders on certified tv boxes are not.

Every new certified android tv box running android 11+ has this oem unlocking toggle in developer options. Including models by skyworth and sei. But none of the bootloaders on these devices observe it. The devices that can be bootloader unlocked do it regardless of the setting.

The bootloaders (and uboot) on the skyworth and sei devices running android 11+ are somewhat modified to prevent bootloader unlocking, but the ccwgtv bootloader is modified even more. My guess is that the current bootloader for sabrina totally ignores whatever value the "lock" environment variable contains, so it is unlikely that sabrina's bootloader would ever respect the oem unlocking logic, even if that logic worked perfectly, because the code to do so is purposely not in the bootloader.

If I'm missng how the oem unlocking toggle would work on a certified tv box, please clue me in.

 

[npjohnson]

When you say "where **it** didn't check for the OEM unlock prop", what is it? Something on the OS side?

TvSettings

Even if the OEM unlock prop was properly checked (instead of checking for the presence of an frp partition), how would the bootloader ever recognize any of this unless is was specifically coded to do so?

The bootloader has all the code to check the unlock_abillity flag, which is set by the OEM unlock toggle, which on Android 10 was greyed out by the presence of an FRP partition, instead now, it is greyed out by ro.oem_unlock_abillity=0 (which Sabrina on both 10 and 12 sets to 1, indicating they intended it to be unlock able)

It seems to me that this oem unlocking toggle in developer options is meaningless unless the bootloader is crafted to observe the toggle, even when the toggle is properly functioning. For various reasons, the bootloaders on phones are so crafted, but the bootloaders on certified tv boxes are not.

Incorrect. U-boot source is very similar to Deadpool's and does respect these properties.

Every new certified android tv box running android 11+ has this oem unlocking toggle in developer options. Including models by skyworth and sei. But none of the bootloaders on these devices observe it. The devices that can be bootloader unlocked do it regardless of the setting.

Don't know where you're getting this. They do. I have several SEI boards that are unlock able. With that said, there was a _bug_ in pre-android 12 that meant If you didn't have an frp partition tvsettings would never allow you to.

The bootloaders (and uboot) on the skyworth and sei devices running android 11+ are somewhat modified to prevent bootloader unlocking, but the ccwgtv bootloader is modified even more. My guess is that the current bootloader for sabrina totally ignores whatever value the "lock" environment variable contains, so it is unlikely that sabrina's bootloader would ever respect the oem unlocking logic, even if that logic worked perfectly, because the code to do so is purposely not in the bootloader.

If I'm missng how the oem unlocking toggle would work on a certified tv box, please clue me in.

Sabrina doesn't at all ignore the lock value - take it from the guy who released the unlock (or check out u-boot source yourself).

All this said, I had a conversation with Google engineers - the above is all accurate - the only piece that is un-clear is why the toggle shows (not greyed) but still isn't activatable.

 

[Deleted member 11959327]

Sabrina doesn't at all ignore the lock value - take it from the guy who released the unlock (or check out u-boot source yourself).

I know that the genesis version of the sabrina bootloader respects the env lock value, obviously, because that is how your unlock works.

But are you sure that the current version does also? Is the u-boot source for the version of u-boot in sabrina's newest bootloader also published?

Don't know where you're getting this. They do. I have several SEI boards that are unlock able.

Yes, most SEI boards are unlockable. One that is (sort of) not unlockable, and the device that I'm most familiar with, is the sei700 described in the previously linked tweet by Sean Hoyt. Sean reports that this device is not bootloader unlockable. But in actuality this perceived unlockability it is a bit of an illusion. The bootloader tests for buildtype (user or userdebug) and only allows unlocking on the latter buildtype.

But the oem unlocking toggle has no effect on this device. If the bugs that you reported fix this, I wonder how all of the tests sei's bootloader does for buildtype will interact with the toggle once it is working.

 

[npjohnson]

I know that the genesis version of the sabrina bootloader respects the env lock value, obviously, because that is how your unlock works.

But are you sure that the current version does also? Is the u-boot source for the version of u-boot in sabrina's newest bootloader also published?

The current version has the same functions, I've got it open in a disassembler right now. I've poked about source, we should see it soon, but according to them "no real changes to 12 u-boot"
And for what it's worth - on genesis bootloader versions still respect that value. The most up to date 10 bootloder does too.

All they did to "fix" this was bottom password.

Yes, most SEI boards are unlockable. One that is (sort of) not unlockable, and the device that I'm most familiar with, is the sei700 described in the previously linked tweet by Sean Hoyt. Sean reports that this device is not bootloader unlockable. But in actuality this perceived unlockability it is a bit of an illusion. The bootloader tests for buildtype (user or userdebug) and only allows unlocking on the latter buildtype.

But the oem unlocking toggle has no effect on this device. If the bugs that you reported fix this, I wonder how all of the tests sei's bootloader does for buildtype will interact with the toggle once it is working.

they may have custom stuff stacked atop for that board, but google doesn't.

 

[Deleted member 11959327]

The current version has the same functions, I've got it open in a disassembler right now. I've poked about source, we should see it soon, but according to them "no real changes to 12 u-boot"

So, all that is lost by the pw mitigation is write access to the env partition via usbdl mode?

Therefore, by manually updating the env partition using external writes to the emmc, the current bootloader would be unlocked? The device could then even run the old original bootloader because the last value in the lock variable enforces arb?

I guess there is one way to find out. I will give it a try on my mitigated sabrina.

 

[npjohnson]

So, all that is lost by the pw mitigation is write access to the env partition via usbdl mode?

Therefore, by manually updating the env partition using external writes to the emmc, the current bootloader would be unlocked? The device could then even run the old original bootloader because the last value in the lock variable enforces arb?

I guess there is one way to find out. I will give it a try on my mitigated sabrina.

I think you're confused a bit.

We didn't write the env partition via usbdl.

We used a bottom vulnerability that relied on there being no USB password to load a modified BL2, which loaded a modified u-boot, which set the env flag by hand and wrote to env partition.

We could in theory update the env partition from OS, but that's harder than it sounds as there's verifications and such surrounding validly writing it. Plus we don't have root access, so it's moot.

And no the device couldn't run the original bootloader, fuses were burned on the update, we can't disable ARB persistently, only by booting a modified BL2 via USB temporarily.

Not sure how you'd test it without local root access?

 

[Deleted member 11959327]

I think you're confused a bit.

I think you're confused a bit about my being confused a bit.

We didn't write the env partition via usbdl.

We used a bottom vulnerability that relied on there being no USB password to load a modified BL2, which loaded a modified u-boot, which set the env flag by hand and wrote to env partition.

Of course you didn't write to the env partition directly using usbdl code or scripts.

But if it were not for the the entry vector the usbdl exploit gave you, you couldn't have done all of the other stuff described in the second paragraph above.

So, what was cut off by the pw mitigation was that entry vector.

Another entry vector is physically writing to the emmc externally.

And no the device couldn't run the original bootloader, fuses were burned on the update, we can't disable ARB persistently, only by booting a modified BL2 via USB temporarily.

Yes, you and fred disabled the arb feature in bl2. But suppose the lock value was already 10000000, would that only prevent an older version of the bootloader from being flashed, it wouldn't also effectively disable arb?

If the lock variable can't disable arb, but only prevents an older bootloader from being flashed, then you're correct.

But if the current bootloader otherwise observes the lock variable, writing a good env partition (w/ valid crc) should unlock the bootloader.

I don't really think it would work. I think the newest bootloader would revert any changes to the lock variable back to a locked value.

 

[npjohnson]

I think you're confused a bit about my being confused a bit.

Of course you didn't write to the env partition directly using usbdl code or scripts.

But if it were not for the the entry vector the usbdl exploit gave you, you couldn't have done all of the other stuff described in the second paragraph above.

Correct.

So, what was cut off by the pw mitigation was that entry vector.

Correct

Another entry vector is physically writing to the emmc externally.

You mean desoldering MMC, hooking up externally, and writing a valid CRC'd env partition? Yes, that should, in fact, work.

Yes, you and fred disabled the arb feature in bl2. But suppose the lock value was already 10000000, would that only prevent an older version of the bootloader from being flashed, it wouldn't also effectively disable arb?

The lock status has nothing to do with the ability to run older bootloaders. It's a higher-level layer. ARB on BL33 is enforced by BL2, hence the need to patch BL2.

If you unlock the bootloader, you can run _older boot images_, yes, but not older bootloaders.

The `unlock_abillity` status dictates:
* Can the user OEM unlock the device via fastboot

The `lock` status dictates:
* Can partitions on the device be flashed from fastboot
* Are signature checks enforced by BL33 on the boot image

If the lock variable can't disable arb, but only prevents an older bootloader from being flashed, then you're correct.

It can't, if you unlock successfully, you can then _flash_ an older bootloader, but it will not boot due to ARB - and the fact that older boot loaders have incremented EFUSE values.

But if the current bootloader otherwise observes the lock variable, writing a good env partition (valid crc) should unlock the bootloader.

It does, and yeah, if you can desolder and interface with the MMC, yup, should work fine.

I don't really think it would work. I think the newest bootloader would revert and changes to the lock variable backed to a locked value.

You can even look at boreal source code for 12, which is released, or disassemble current Sabrina 12 u-boot, the functions are still there, and it still read out/respect the `lock` value, and `unlock_abilllity` values.

Again, all of this is superseded by the fact that - I talked to several of the Googler's surrounding this, and they acknowledged it was intended to be unlockable upon release, but that they weren't sure why the CC team hadn't made that the case - at which point was discovered it was a bug in tvsettings.

 

[npjohnson]

I think you're confused a bit about my being confused a bit.



Of course you didn't write to the env partition directly using usbdl code or scripts.

But if it were not for the the entry vector the usbdl exploit gave you, you couldn't have done all of the other stuff described in the second paragraph above.

So, what was cut off by the pw mitigation was that entry vector.

Another entry vector is physically writing to the emmc externally.



Yes, you and fred disabled the arb feature in bl2. But suppose the lock value was already 10000000, would that only prevent an older version of the bootloader from being flashed, it wouldn't also effectively disable arb?

View attachment 5738351

If the lock variable can't disable arb, but only prevents an older bootloader from being flashed, then you're correct.

But if the current bootloader otherwise observes the lock variable, writing a good env partition (w/ valid crc) should unlock the bootloader.

I don't really think it would work. I think the newest bootloader would revert any changes to the lock variable back to a locked value.

Poked my google contact, they verified what I said, and released the OSS 12 code, I diff'd it to deadpool here: https://github.com/npjohnson/androi...08e60c6fbc2cd47f1c3ded75eb45c5d3f7e9769cfdf71

Net difference of like, 25 lines of unimportant code, a ton of license changes, and changes for non-sabring platforms.

 

[Deleted member 11959327]

Poked my google contact, they verified what I said, and released the OSS 12 code, I diff'd it to deadpool here: https://github.com/npjohnson/androi...08e60c6fbc2cd47f1c3ded75eb45c5d3f7e9769cfdf71

Net difference of like, 25 lines of unimportant code, a ton of license changes, and changes for non-sabring platforms.

Thanks. Looks like you're correct. That's a great reference. Would be nice if other mfg released so quickly.

One concern I still have is that, as you note at the top of this thread, ota-updating from the genesis bootloader "will re-lock your bootloader":

- Can I OTA afterwards?
NO - It will re-lock your bootloader,

Which code in the bootloader does this re-locking? Does it do it explicitly, or indirectly by something like reverting to the defenv_reserv environment during the ota? Is it done just during the ota, or perhaps at every boot?

 

[npjohnson]

Thanks. Looks like you're correct. That's a great reference. Would be nice if other mfg released so quickly.

One concern I still have is that, as you note at the top of this thread, ota-updating from the genesis bootloader "will re-lock your bootloader":



Which code in the bootloader does this re-locking? Does it do it explicitly, or indirectly by something like reverting to the defenv_reserv environment during the ota? Is it done just during the ota, or perhaps at every boot?

It's only when the bootloader detects an upgrade. Env is pulled to default values to pick up new values from installed bootloader.