[RELEASE] Chromecast with Google TV Bootloader Unlock

Search This thread

npjohnson

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

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

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

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

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

Code:
 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
 
  • Like
Reactions: galaxys
D

Deleted member 11959327

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

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

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

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

Senior Member
Jun 23, 2019
69
25
47
Honor 50

Attachments

  • IMG_20221017_124511.png
    IMG_20221017_124511.png
    111.4 KB · Views: 95
D

Deleted member 11959327

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

npjohnson

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

Deleted member 11959327

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

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

Deleted member 11959327

Guest
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

Recognized Developer
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.
 
Last edited:
D

Deleted member 11959327

Guest
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

Recognized Developer
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?
 
D

Deleted member 11959327

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

arb-lock-variable.jpg


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

npjohnson

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

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

Deleted member 11959327

Guest
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

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

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