yashsingh1/xdaforums huggingface dataset:
[Google TV General] :
Is drm operation entirely perfect for you on all apps with these .ta files (in the link) and the newest factory build?

It is okay for me on some apps but blippy on others. But I'm still running the original bootloader that came on the device. OP mentioned awhile back that the .ta files have to match the bootloader. I'll update the bootloader if that will fix it otherwise I'd prefer to leave the original bootloader.

But it is even blippy running entirely the original factory build on the device. It took multiple online signatures in global and secure settings (anomaly_config and config_update_certificate) in order to get past wraith and for adb or usb mass storage to be in any way functional on the running OS. They went the extra mile to lock this device down from any external access until it's associated with a google account.

During all of this, I did manage to get the url to the full ota for the newest build if anyone needs it for anything. I sort of hate running factory on this device and I'm probably going to put lineage back on it.
[Google TV General] npjohnson:
Updating the bootloader will lock your BL. Even if it is unlocked.
[Google TV General] :
I meant only updating it to a different pre-mitigation version of the bootloader, not to the current version of the bootloader or to any version of the bootloader that is not a pre-mitigation version of the bootloader.

The device I'm working with came from the factory with build QTS1.200625.002.A5/6686931 of the OS and version 01.01.200713.082523 of the bootloader. I've never changed this bootloader during the entire history of using this device.

What I meant by updating is that, for example, I'd consider updating my factory bootloader version to a later pre-mitigation bootloader version that would allow the teetz files to work when my factory version of the bootloader doesn't seem to work with them. I don't mean work with the newest teetz files, I mean work with the old teetz files that are being patched into the later builds in order to allow these builds to run with the older pre-mitigation bootloader.

If all pre-mitgation versions of the bootloader are the same, or if there are different versions of the pre-migitation bootloader but they all work the same with the teetz files, then of course there would be no point in changing the bootloader from 01.01.200713.082523 to some other pre-migitation version of the bootloader.
[Google TV General] :
The device I refer to above was mfg 9/20. Today I just opened a sealed box for a device that was mfg 11/20. Dumped the bootloader and it is the same version as described above. So I'm guessing that this version of the bootloader was the newest and last of the pre-mitgation bootloaders, unless some OTAs from that time contained a newer version of the pre-migiataion bootloader.
[Google TV General] npjohnson:
same version, expected.

09/20 build is the latest unpatched.

MFG dates through December are safe and unpatched, and any device MFG before that didn't update to the Feb update.

02/21 update patched _existing_ systems fuse password.

Devices shipped from 12/20 onward have passwords set from factory.

There is only one earlier (04/20 iirc) bootloader, but I have yet to come across it.
[Google TV General] :
uh oh. our unpatched android 10 bootloaders may have a limited life span for running stock, if the reports are true.

Chromecast with Google TV (4K) is getting updated to Android 12 soon

The Chromecast with Google TV is getting updated to Android 12, finally bringing a major update to the device for the first time.

9to5google.com
[Google TV General] npjohnson:
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.
[Google TV General] :
Did the tee applets that work with the unpatched bootloader remain exactly the same across ota updates until they stopped working? Or is there some build that has the best and last version of the tee applets that work with the original bootloader? From which build are they pulled from for integration with the newer builds?

Yes, I imagine that the 12 update must be a full ota. Here is the full ota for qts1.220504.008/8726984, should it be the last 10 build, for posterity's sake;

qts1.220504.008/8726984, full ota:
(reminder: this ota contains dangerous bootloader)

h..ps://android.googleapis.com/packages/ota-api/package/46e6458da2b9c2ab9db121307c2a1ccbfd725062.zip
[Google TV General] npjohnson:
Only _that exact_ build's TEE apples work.

That is note the last Q build, it is the last full OTA, the last OTA is incremental.
[Google TV General] :
I don't understand. Which build does "_that exact_" refer to?

There is an incremental ota with a build newer than qts1.220504.008?

What is its build fingerprint?

The link I provided contains qts1.220504.008, and is a full ota. I know of no newer build, incremental or otherwise.
[Google TV General] npjohnson:
I mean the exact build the TEE applets shipped.

And huh, maybe I am confused, you appear to be right about that being a full OTA. Wonder why no one shared that to be made into an edited factory image until now. lol.
[Google TV General] GroundControl2MT:
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?
[Google TV General] npjohnson:
it is disabled. Not sure why this has happened. Try re-running the exploit?
[Google TV General] GroundControl2MT:
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?
[Google TV General] npjohnson:
Try the repair script
[Google TV General] :
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
[Google TV General] npjohnson:
I'll lyk, but it's likely I have the best news I've had in a long time.
[Google TV General] volkodav1975:
For those whose bootloader is blocked, does this new item not work?
[Google TV General] :
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.
[Google TV General] :
The oem unlocking toggle in developer options is a case of form over function. In this case there is probably no function.
[Google TV General] npjohnson:
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.

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).
[Google TV General] :
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.
[Google TV General] npjohnson:
TvSettings

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)

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

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.

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.
[Google TV General] :
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?

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.
[Google TV General] npjohnson:
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.

they may have custom stuff stacked atop for that board, but google doesn't.
[Google TV General] :
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.
[Google TV General] npjohnson:
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?
[Google TV General] :
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?

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.
[Google TV General] npjohnson:
Correct.

Correct

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

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

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.

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

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.
[Google TV General] npjohnson:
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.
[Google TV General] :
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?
[Google TV General] npjohnson:
It's only when the bootloader detects an upgrade. Env is pulled to default values to pick up new values from installed bootloader.
[Google TV General] :
It is there anything different about how this works on sabrina as compared to dopinder?

Dopinder takes ota updates without any change to the lock value. But even if the lock value were changed, burn mode is only a button press away.

Suppose, on a sabrina device running android 12, tvsettings worked perfectly insofar as the operation and respect of the oem toggle in dev options. Would a sabrina device's pre-ota lock value be retained? And if it weren't, would it be bricked because there would be no usb access via burn mode nor bootrom mode? Assuming, of course, that the particular sabrina device had modifications that weren't undone by the ota.
[Google TV General] npjohnson:
To be completely candid:

The "it relocks on update" is a suspicion based on the code. You can take a look and decide for yourself.

None of us tried it as, well, it could make Sabrina useless for development lol. If someone is brave enough to flash 12 BL on an unlocked one and it works let me know!
[Google TV General] UNG7896:
guys do know what is step of unlocking bootloader ? , i updated it android 12 hoping i can turn back android 10
[Google TV General] npjohnson:
You can't.

You're out of luck, sadly.
[Google TV General] :
boreal is on sale. the android build and bootloader style are very different than sabrina's, given the newer generation SoC. google might not have messed with uboot's control of the lock variable on android 12 for sabrina, but for boreal it might be a different story;

Spoiler content hidden.

boreal is an a/b device. my device came with "b" set as the active slot, containing this build;

google/boreal/boreal:12/STT1.220417.001.A7/8608242:user/release-keys

the "a" slot contains, at least in the non-dynamic partitions, an eng build;

google/boreal_fct/boreal:12/STT1.220503.001.F2/8546046:eng/dev-keys

I haven't confirmed if super contains the rest of the eng build partitions. The a/b system has distinct bootloader partitions (bootloader_a & bootloader_b).

The device will update and overwrite the "a" slot during setupwraith.

adnl (burn mode) is disabled, except to the extent that a dnl connection can be made for bootrom mode.

I burned a whole friday evening and I'm already bored with boreal.
[Google TV General] npjohnson:
you're _kidding_ me.

I have a boreal - let me try this - all we need to do is make android rescue party to swap slots back on locked bootloader - but god damn that would be an impressive **** up on Google's part.

And as for ADNL, you can get chip-id, that's about it.

Where was the RX on boreal? I looked around briefly but didn't find it.
[Google TV General] :
See attached image. RX is on the left.

I can change the active slot. I didn't because I was concerned that if arb is implemented, the bootloader in bootloader_a might be older, and then boreal would be reduced to spitting out only a single line string instead of booting up. Do you happen to know how a device behaves when arb detects an older bootloader?

There is also rma mode in the environment that apparently can, in combination with switch_bootmode, switch slots;

check_rma=if gpio input GPIOD_10; then echo FDR button pressed; if test ${active_slot} = _a; then setenv rma_slot _b; else setenv rma_slot _a; fi; tcpc start; usb start; if size usb 0 boot.img && itest ${filesize} <= 0x4000000 && load usb 0 ${loadaddr} boot.img ${filesize} && store write ${loadaddr} boot${rma_slot} 0 ${filesize} && size usb 0 vendor_boot.img && itest ${filesize} <= 0x4000000 && load usb 0 ${loadaddr} vendor_boot.img ${filesize} && store write ${loadaddr} vendor_boot${rma_slot} 0 ${filesize} && size usb 0 dtbo.img && itest ${filesize} <= 0x200000 && load usb 0 ${loadaddr} dtbo.img ${filesize} && store write ${loadaddr} dtbo${rma_slot} 0 ${filesize} && size usb 0 vbmeta_system.img && itest ${filesize} <= 0x100000 && load usb 0 ${loadaddr} vbmeta_system.img ${filesize} && store write ${loadaddr} vbmeta_system${rma_slot} 0 ${filesize} && size usb 0 vbmeta.img && itest ${filesize} <= 0x100000 && load usb 0 ${loadaddr} vbmeta.img ${filesize} && store write ${loadaddr} vbmeta${rma_slot} 0 ${filesize}; then setenv active_slot ${rma_slot}; setenv boot_part boot${rma_slot}; setenv vendor_boot_part vendor_boot${rma_slot}; if test ${rma_slot} = _a; then setenv slot-suffixes 0; else setenv slot-suffixes 1; fi; setenv use_external_avb_key 1; setenv bootargs ${bootargs} androidboot.rma=true; run recovery_from_flash; fi; fi;

check_rma is executed last in preboot:

preboot=run bcb_cmd; run upgrade_check;run init_display;run storeargs;bcb uboot-command;run switch_bootmode;run check_rma;

I might try changing the active slot after I dump out the rest of super. Neither fatwrite nor ext4write are enabled in uboot, so it is slow going.
[Google TV General] npjohnson:
wait, it has u-boot _shell_?

If so, this is going to be easy lol.
[Google TV General] :
Not obtained by normal implementation via keyboard interruption during boot, but by reliably and quickly repeatable fault interruption. I'll send details by direct message.

I thought so too, but I've already tried a lot of stuff. If you can do it in a few seconds, I'll be very embarrassed.
[Google TV General] UNG7896:
this latest android 12 update problem on Chromecast will also occur on tv like sony Google tv ?
[Google TV General] npjohnson:
Maybe?
[Google TV General] GroundControl2MT:
Hey so I was able to get into fastboot with the repair script back in October. I re-ran through the whole set up, But nothing changed. I am still unable to get past the 'G' boot logo. I've been retrying the repair.sh script today and I am unable to get it to go into fastboot at all. Although when I bought this cwgtv I successfully exploited it and disabled updates using the script, I think it somehow updated. Is there anyway for me to check what bootloader version I have?
[Google TV General] Aapat:
Hello,

Thank you for discovering this exploit! I was able to unlock my bootloader, flash the newer modified factory image to prevent the setup auto-update, lineage recovery, and Magisk. However when I go through the initial device setup, my device gets to the update screen and indicates it's downloading an update.

Is this expected behavior with the modified factory image flashed? I ended up unplugging my device right as the update process started, and reran the unlock script to prevent a possible update.