[RELEASE] Chromecast with Google TV Bootloader Unlock

Search This thread

npjohnson

Recognized Developer
When I installed a uart header in one of my sabrinas last year, I used this image from the unlock writeup as reference for the serial connections:

View attachment 5703681

and installed the uart header thusly:

View attachment 5703683

Today I was booting ubuntu on sabrina and trying to interrupt uboot (fred has bootdelay set at non-zero value). I couldn't interrupt uboot.

It turns out that I had RX connected to the wrong location. It actually is here:

View attachment 5703691

The correct tx/rx locations also correspond to these locations on the edge connector:

View attachment 5703695

Please excuse this post if this info has been mentioned previously.
Yeah, that photo I posted is slightly wrong.

Sorry about that! Happy you got it fixed.
 
D

Deleted member 11959327

Guest
Here. Contains only the updated partitions. If the super.img does not work, let me know and I'll upload the dynamic partitions separately.

The link expired. Would you repost QTS1.220504.008 with the patched .ta files?
 
Last edited by a moderator:
D

Deleted member 11959327

Guest
Using the alternate uboot that enables burn mode (with uboot loaded) is also a cumbersome way just to edit a single variable.
 
Last edited by a moderator:

retyre

Senior Member
Jan 14, 2011
311
319
Central FL
Using the alternate uboot that enables burn mode (with uboot loaded) is also a cumbersome way just to edit a single variable.
Link fixed. I don't think anyone figured out how to disable SUW at first boot. If it sees the latest build installed, it lets setup continue without updating. Hence the hoop-jumping to create an updated super.img for every new update.

There might be at least two pre-mitigation bootloaders (2006x and 2009x, June and Sept. 2020, I think).

If you're able to interrupt U-Boot, can you not use setenv to set the env variable?
 
D

Deleted member 11959327

Guest
Link fixed. I don't think anyone figured out how to disable SUW at first boot. If it sees the latest build installed, it lets setup continue without updating. Hence the hoop-jumping to create an updated super.img for every new update.

Got it, thanks. For OTAs that happen beyond the setup, has something been done to stop those? If so, what is it?

If you're able to interrupt U-Boot, can you not use setenv to set the env variable?

Do you mean a uboot that is provided in one of the bl33 replacements that have to be loaded via the usb download mode exploit, like sabrina.bootloader.burnmode.bin? Because I don't think that stock uboot is interruptible. But I will check again.
 
Last edited by a moderator:

retyre

Senior Member
Jan 14, 2011
311
319
Central FL
Got it, thanks. For OTAs that happen beyond the setup, has something been done to stop those? If so, what is it?

Do you mean a uboot that is provided in one of the bl33 replacements that have to be loaded via the usb download mode exploit, like sabrina.bootloader.burnmode.bin? Because I don't think that stock uboot is interruptible. But I will check again.
I just block "android.googleapis.com" at the device level (using AdAway). This blocks the Google Play Store (GPS), so I disable AdAway on-demand if I have to access GPS. That would be a strong reason not to block it at the router level because every Android device in the household will then be locked out of GPS.

Since you posted the correct UART pinout above, I thought you were already using an interruptible U-Boot. You're not?
 
D

Deleted member 11959327

Guest
I can use an interruptible uboot from the various supplied bl33 images used with the exploit, but for an ordinary OS boot I'd use the stock uboot, because I'd be booting with the factory bootloader.

The uboot used with the exploit is considerably different than the factory uboot for this particular device, at least in terms of the console output during the boot sequence.

Edit: Booting sabrina.bootloader.burnmode.bin only shows a 1 byte environment. This could be because the style of boot is usb boot, and maybe the env part could be loaded if mmc was reset or selected. Booting fred's ubuntu bootloader does show a full enviroment, but also one that has been partly altered for booting ubuntu. I was reluctant to try a saveenv command, even if it would have saved to the emmc, which I don't know if it would have.
 
Last edited by a moderator:

volkodav1975

Senior Member
Jun 23, 2019
69
25
47
Honor 50
I don't think anyone figured out how to disable SUW at first boot.
I succeeded, if I understood correctly what you mean.
When I got my Sabrina, I foolishly plugged it into the TV and accidentally let it update. But when the reboot went on, I was able to get into Recovery by pressing the button and it was clear that the version was still the same, unfortunately I thought for a long time and did not know how to manage it with the button, so I could not reset it. Alas, this is how I lost the opportunity to get an unlock, but I knew for sure then that if I knew about the short and long presses of the button, then I could reset the update. (Forgive me if I wrote something incomprehensibly, I'm through a translator)
 
D

Deleted member 11959327

Guest
Link fixed.

There might be at least two pre-mitigation bootloaders (2006x and 2009x, June and Sept. 2020, I think).
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.
 

npjohnson

Recognized Developer
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.
Updating the bootloader will lock your BL. Even if it is unlocked.
 
D

Deleted member 11959327

Guest
Updating the bootloader will lock your BL. Even if it is unlocked.

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.
 
Last edited by a moderator:
D

Deleted member 11959327

Guest
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.

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.
 

npjohnson

Recognized Developer
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.
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.
 

npjohnson

Recognized Developer
uh oh. our unpatched android 10 bootloaders may have a limited life span for running stock, if the reports are true.

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.
 
D

Deleted member 11959327

Guest
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;

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

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

npjohnson

Recognized Developer
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;

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

h..ps://android.googleapis.com/packages/ota-api/package/46e6458da2b9c2ab9db121307c2a1ccbfd725062.zip
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.
 
D

Deleted member 11959327

Guest
Only _that exact_ build's TEE apples work.

I don't understand. Which build does "_that exact_" refer to?

That is note the last Q build, it is the last full OTA, the last OTA is incremental.

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.
 

npjohnson

Recognized Developer
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.
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.
 
Aug 3, 2010
29
0
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?
 

Top Liked Posts

  • There are no posts matching your filters.
  • 16
    Introduction:

    This is an exploit chain intended to allow one to run a custom OS/unsigned code on the Chromecast with Google TV (CCwGTV).

    This uses a bootROM bug in the SoC by security researcher Frederic Basse (frederic).

    Frederic also did a great amount of work to temporarily boot a custom OS from USB here.

    Security researchers Jan Altensen (Stricted) and Nolen Johnson (npjohnson) took the vulnerability and provided tools and customized a u-boot image to take advantage of the provided secure-execution environment to fully bootloader unlock the device.

    Disclaimer:

    You are solely responsible for any potential damage(s) caused to your device by this exploit.

    FAQ:

    - Does unlocking the bootloader void my warranty on this device?
    Probably, assume so. Or just flash stock and lock your bootloader before RMA. The exploit itself leaves no traces.

    - Does unlocking the bootloader break DRM in any way?
    Nope, just like unlocking a Pixel device officially.

    - Can I OTA afterwards?
    NO - It will re-lock your bootloader, and if you've made any modifications, brick you pretty hard. If you manage to do this, re-running the exploit won't be possible either, as a BootROM password is set on any update newer than

    - Can I use stock?
    Yes, but only if you flashed the newer patched factory image offered up in the script.

    - Can I go back to stock after installing custom OS's?
    Yeah, totally, here's a "Factory Image" I made in the style of Pixel Factory Images. The patch level of this build is 2021-08-05. The tool offers to put you on a newer firmware, it's highly recommended to do so.

    - Can I re-lock the bootloader?
    If you flashed the factory image above, sure, but you run the risk of not being able to unlock again.

    - I've run the exploit 10 times and it isn't working yet!
    Swap USB ports/cables, and keep trying, for some people it takes one attempt, for some it takes a lot of attempts.

    Requirements:
    • Chromecast With Google TV (sabrina) without USB password mitigation¹
    • Either a USB A to C, or a C to C cable
    • A PC running some flavor of 64-bit GNU Linux
    • `libusb-dev` installed
    • `fastboot` & `mke2fs` installed from the SDK Platform tools
    ¹: The USB password mitigation has been enabled on units manufactured in December 2020 and after. For units manufactured before, the mitigation was enabled by software update in February 2021. To discern this, look at the MFP date on the bar-code sticker on the bottom of your device's box. If you've powered it on and OTA'd, your firmware version needs to be below the February 2021 patch level. It's not possible to disable/change the password since it's burnt into the chip (efuses).

    Instructions:

    Follow the detailed and up-to-date instructions over at our Github repo, and maybe give the writeup a read/share on social media!

    Post-unlock:
    • The script asks if you want to flash LineageOS Recovery, or a Magisk patched boot image, so enjoy those!
    • At the moment, there are no ROMs for the device, but Android builds in the form of LineageOS are coming soon™. Builds of that will be posted in this forum once ready, and I'll link them here.

    Credits:
    • Nolen Johnson (npjohnson): The writeup, helping debug/develop/theorize the unlock method
    • Jan Altensen (Stricted): The initial concept, u-boot side unlock implementation, debugging/developing the unlock method, and being a wealth of information when it comes to Amlogic devices
    • Frederic Basse (frederic): The initial exploit and the AES key tip
    Special Thanks:
    • Ryan Grachek (oscardagrach): Being an awesome mentor, teaching me a fair chunk of what I know about hardware security, and being a massive wealth of knowledge about most random things.
    • Chris Dibona: Being an awesome advocate of OSS software and helping ensure that we got all the source-code pertinent to the device.
    • Pierre-Hugues Husson (phh): For pointing me down the Amlogic road to begin with by letting me know Google had decided to make the ADT-3 bootloader unlockable.
    • XDA users @p0werpl & @JJ2017, who both helped experiment and find a combination of images that allowed us to skip the forced OTA in SUW.
    3
    wow im glad i left mine unplugged
    2
    Alright, here you go:


    Opening it up, this seems to be a partial OTA that takes the device from QTS1.210311.008 to QTS1.210311.036.
    Perfect. Thx. Will aim to look this weekend.
    2
    I've updated the g12 thread to support sabrina - the beta LineageOS builds for it are live!

    If you want to come back from them, just re-run unlock.sh and select to flash the factory image.
    2
    Thanks OP - script worked a treat on an (unused) unit, MFG: 07/2020.
    Any advice on blocking / disabling the OTA updates? Can't see any instructions searching around (and not much use it until that hurdle cleared!)