[RELEASE] Chromecast with Google TV Bootloader Unlock

Search This thread
D

Deleted member 11959327

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

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

npjohnson

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

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!
 

UNG7896

New member
Oct 29, 2022
4
0
guys do know what is step of unlocking bootloader ? , i updated it android 12 hoping i can turn back android 10
 
D

Deleted member 11959327

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

Code:
Starting task scheduler ...
boot bl33 !
env_init: Environment STORAGE init done (ret=-2)
4096 bytes read in 1 ms (3.9 MiB/s)
CONFIG_SYSTEM_AS_ROOT: null
system_mode in storeboot: 0
CONFIG_AVB2: avb2
active_slot in storeboot: _b
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
retry common dtb
[imgread]partName = vendor_boot_b
[imgread]partName_r = vendor_boot_b
avb2: 1
active_slot is _b
ab_suffix is _b
The device is force locked
The device is force locked
Verifying with vendor key[0]
The device is force locked
The device is force locked
The device is force locked
The device is force locked
avb verification: locked = 1, result = 0
The device is force locked
The device is force locked
avb2: 1
## Booting Android Image at 0x03080000 ...
Kernel command line: androidboot.boot_devices=soc/fe08c000.mmc otg_device=1 use_uvm=1 buildvariant=user
load dtb from 0x1000000 ......
env select addr: 0x0x1000000
## Flattened Device Tree blob at 01000000
   Booting using the fdt blob at 0x1000000
active_slot is _b
Start read dtbo_b partition datas!
Read board id from dtbo...
Find dtbo index 6 for board id 5
find 7 dtbos
dtbos to be applied: 6
Apply dtbo 6
   Uncompressing Kernel Image ... OK
   Loading Ramdisk to 3e28d000, end 3f7ff613 ... OK
libfdt fdt_getprop(): FDT_ERR_NOTFOUND
   Loading Device Tree to 000000001ffe5000, end 000000001ffff3c7 ... OK

Starting kernel ...

uboot time: 4462020 us
boot 64bit kernel
read_ao no reg:0x11
[cec_get_portinfo]: info=0x0
AOCPU unknown cmd=b5
vmin:72 98 4 0!
[VRTC]: xMboxGetRTC val=0x0

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

npjohnson

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

Code:
Starting task scheduler ...
boot bl33 !
env_init: Environment STORAGE init done (ret=-2)
4096 bytes read in 1 ms (3.9 MiB/s)
CONFIG_SYSTEM_AS_ROOT: null
system_mode in storeboot: 0
CONFIG_AVB2: avb2
active_slot in storeboot: _b
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
retry common dtb
[imgread]partName = vendor_boot_b
[imgread]partName_r = vendor_boot_b
avb2: 1
active_slot is _b
ab_suffix is _b
The device is force locked
The device is force locked
Verifying with vendor key[0]
The device is force locked
The device is force locked
The device is force locked
The device is force locked
avb verification: locked = 1, result = 0
The device is force locked
The device is force locked
avb2: 1
## Booting Android Image at 0x03080000 ...
Kernel command line: androidboot.boot_devices=soc/fe08c000.mmc otg_device=1 use_uvm=1 buildvariant=user
load dtb from 0x1000000 ......
env select addr: 0x0x1000000
## Flattened Device Tree blob at 01000000
   Booting using the fdt blob at 0x1000000
active_slot is _b
Start read dtbo_b partition datas!
Read board id from dtbo...
Find dtbo index 6 for board id 5
find 7 dtbos
dtbos to be applied: 6
Apply dtbo 6
   Uncompressing Kernel Image ... OK
   Loading Ramdisk to 3e28d000, end 3f7ff613 ... OK
libfdt fdt_getprop(): FDT_ERR_NOTFOUND
   Loading Device Tree to 000000001ffe5000, end 000000001ffff3c7 ... OK

Starting kernel ...

uboot time: 4462020 us
boot 64bit kernel
read_ao no reg:0x11
[cec_get_portinfo]: info=0x0
AOCPU unknown cmd=b5
vmin:72 98 4 0!
[VRTC]: xMboxGetRTC val=0x0

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

Deleted member 11959327

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

Code:
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.
 

Attachments

  • boreal-uart.jpg
    boreal-uart.jpg
    238.8 KB · Views: 160

npjohnson

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

Code:
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.
wait, it has u-boot _shell_?

If so, this is going to be easy lol.
 
D

Deleted member 11959327

Guest
Last edited by a moderator:
Aug 3, 2010
29
0
Try the repair script

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?
 

Aapat

New member
Dec 15, 2022
3
0
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.
 

npjohnson

Recognized Developer
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.
I need to update the modified factory image to Android 12 - I just don't have time at the moment.
 

Aapat

New member
Dec 15, 2022
3
0
I need to update the modified factory image to Android 12 - I just don't have time at the moment.

No problem, thank you for the quick reply! Do you foresee any issues using the process outlined in this thread to create a modified factory image using Android 12 instead of Android 10?
 

npjohnson

Recognized Developer
No problem, thank you for the quick reply! Do you foresee any issues using the process outlined in this thread to create a modified factory image using Android 12 instead of Android 10?
Really just a case of "does it work" - I hope it does but yeah if you extract, replace teetz files, then flash, hopefully it would work.
 

Aapat

New member
Dec 15, 2022
3
0
I discovered a really simple way to bypass setup and its forced update without having to create a modified Android 12 factory image.

I found SetupWraithPrebuiltChromecast.apk within product.img from the zip the unlock script downloads and decided to decompile it. The apk contains a class called DebuggingKeySequence which opens a debugging menu with an option to skip setup when a key sequence is entered. After digging into the class some more, I found an integer array representing the needed key sequence. The integers correspond to UP UP LEFT LEFT on the remote. I tried that sequence during setup immediately after the remote pairing stage, was able to open the debug menu, and skip the rest of setup.

In short, to skip the set-up process, you can press UP UP LEFT LEFT after the remote pairing screen to open a debug menu. Once you have the debug menu opened, select the SKIP_SETUP option. After, sign-in with your google account when forced to (If you select manage accounts at the sign-in screen, you can get to settings to connect to a Wi-Fi network). Immediately after sign-in, I blocked android.googleapis.com on my router to be completely safe from updates, but that may not be necessary.
 

Attachments

  • IMG_2588.jpeg
    IMG_2588.jpeg
    2 MB · Views: 101
Last edited:

npjohnson

Recognized Developer
I discovered a really simple way to bypass setup and its forced update without having to create a modified Android 12 factory image.

I found SetupWraithPrebuiltChromecast.apk within product.img from the zip the unlock script downloads and decided to decompile it. The apk contains a class called DebuggingKeySequence which opens a debugging menu with an option to skip setup when a key sequence is entered. After digging into the class some more, I found an integer array representing the needed key sequence. The integers correspond to UP UP LEFT LEFT on the remote. I tried that sequence during setup immediately after the remote pairing stage, was able to open the debug menu, and skip the rest of setup.

In short, to skip the set-up process, you can press UP UP LEFT LEFT after the remote pairing screen to open a debug menu. Once you have the debug menu opened, select the SKIP_SETUP option. After, sign-in with your google account when forced to. Immediately after sign-in, I blocked android.googleapis.com on my router to be completely safe from updates, but that may not be necessary.
I will post this in the OP!!! Nice find. Super useful.
 

BigEmpty

Member
Dec 2, 2022
24
7
Really just a case of "does it work" - I hope it does but yeah if you extract, replace teetz files, then flash, hopefully it would work.

Attempting this now. Aside from the four files:

93a424e2-5608-4413-84a858b16a064dce.ta
af1ae3a4-888b-4e11-b4ab1c2b972d1c11.ta
d83c3c4a-9e8d-4e4e-ad309d40e137f689.ta
ff2a4bea-ef6d-11e6-89ccd4ae52a7b3b3.ta

which have the same filename in both versions, the other five files in the android 12 version have similar filenames, but with an extra character (dash or hyphen). For example,
12:
2c1a33c0-44cc-11e5-bc3b-0002a5d5c51b.ta

10:
2c1a33c0-44cc-11e5-bc3b0002a5d5c51b.ta

Should the android 10 filenames be kept in android 12?
 
Last edited:

npjohnson

Recognized Developer
Attempting this now. The android 12 teetz files are these:

Code:
sabrina:/vendor/lib/teetz # ls -l
-rw-r--r-- 1 root root 174768 2008-12-31 17:00 2c1a33c0-44cc-11e5-bc3b-0002a5d5c51b.ta
-rw-r--r-- 1 root root  90624 2008-12-31 17:00 526fc4fc-7ee6-4a12-96e3-83da9565bce8.ta
-rw-r--r-- 1 root root 870080 2008-12-31 17:00 8efb1e1c-37e5-4326-a5d6-8c33726c7d57.ta
-rw-r--r-- 1 root root  88144 2008-12-31 17:00 93a424e2-5608-4413-84a858b16a064dce.ta
-rw-r--r-- 1 root root 847824 2008-12-31 17:00 9a04f079-9840-4286-ab92-e65be0885f95.ta
-rw-r--r-- 1 root root 129040 2008-12-31 17:00 af1ae3a4-888b-4e11-b4ab1c2b972d1c11.ta
-rw-r--r-- 1 root root  71904 2008-12-31 17:00 d83c3c4a-9e8d-4e4e-ad309d40e137f689.ta
-rw-r--r-- 1 root root 884064 2008-12-31 17:00 e043cde0-61d0-11e5-9c26-0002a5d5c51b.ta
-rw-r--r-- 1 root root  96352 2008-12-31 17:00 ff2a4bea-ef6d-11e6-89ccd4ae52a7b3b3.ta
sabrina:/vendor/lib/teetz #

Based on the pinned reference, the android 10 teetz files are these:

Code:
vendor/lib/teetz/2c1a33c0-44cc-11e5-bc3b0002a5d5c51b.ta
vendor/lib/teetz/ff2a4bea-ef6d-11e6-89ccd4ae52a7b3b3.ta
vendor/lib/teetz/e043cde0-61d0-11e5-9c260002a5d5c51b.ta
vendor/lib/teetz/93a424e2-5608-4413-84a858b16a064dce.ta
vendor/lib/teetz/526fc4fc-7ee6-4a12-96e3-83da9565bce8.ta
vendor/lib/teetz/af1ae3a4-888b-4e11-b4ab1c2b972d1c11.ta
vendor/lib/teetz/d83c3c4a-9e8d-4e4e-ad309d40e137f689.ta
vendor/lib/teetz/8efb1e1c-37e5-4326-a5d68c33726c7d57.ta
vendor/lib/teetz/9a04f079-9840-4286-ab92e65be0885f95.ta

Aside from the four files:

93a424e2-5608-4413-84a858b16a064dce.ta
af1ae3a4-888b-4e11-b4ab1c2b972d1c11.ta
d83c3c4a-9e8d-4e4e-ad309d40e137f689.ta
ff2a4bea-ef6d-11e6-89ccd4ae52a7b3b3.ta

which have the same filename in both versions, the other five files in the android 12 version have similar filenames, but with an extra character (dash or hyphen). For example,
12:
2c1a33c0-44cc-11e5-bc3b-0002a5d5c51b.ta

10:
2c1a33c0-44cc-11e5-bc3b0002a5d5c51b.ta

Should the android 10 filenames be kept in android 12? Which needs a particular filename, the bootloader, the OS, or both?
Delete the Android 12 versions, put the Android 10 versions
 

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!)