Temporary [UNLOCK][ROOT][TWRP][MAGISK][...] FireTV 2nd gen Cube (raven)

[Pro-me3us]

Magisk: Zygisk & Modules are now working, available shortly in Magisk Canary build, and eventually in Magisk v25.2 when it's released.

The updated Magisk patched boot image is attached below, unzip and put into the images folder of your boot menu folder
magisk_boot_7242-2906.zip for FireOS 7242/2906+
magisk_boot_7212-1333.zip for any version earlier than 7242/2906

To patch your own boot.img, install the latest Magisk Canary build. Check "recovery mode" and leave VBmeta unchecked.

Leave both "recovery mode" and VBmeta unchecked if you want to create a Magisk boot image to flash to the boot partition. I don't recommend this, since it will only be possible to boot the Cube with the exploit, after doing that ("bash menu" option 9).

===================
Magisk Modules
With Magisk & Modules we can make system modifications without actually touching the system partition.

One example is App Systemitizer, which can make any user app into a system app to gain extra privileges. Make Wolf Launcher a system app, so that it can remain the default launcher after re-enabling Amazon Launcher. With Amazon Launcher enabled in the background, all search functions from Wolf Launcher work again.

There is MagiskHide Props Config to modify the build prop, and many more modules to checkout. These modules will only take effect while booting with Magisk, and not affect regular booting without the exploit loaded.

===================
FireTV 2nd gen Cube Firmware
I've posted a list to all the OTA firmware links that we have. Full firmware bins are the most useful but for now I'm also including partials. If anyone has any URLs not already listed there, please share. Thanks to @roligov for provinding many of these.

 

[goapy]

Is it known if the payload to burn the efuse is contained merely in the bootloader, like it apparently is for the ccwgtv?

Is the bootloader version for any particular raven os version tied to the particular matching raven os system?

For example, would the bootloader from PS7242/3516 work with the remainder of PS7285/2877?

It seems that if it was desired to obfuscate the nature of how the efuse is burned, this would be best accomplished if the payload was contained within the bootloader, or the same would be true if burning the efuse requires a privilege level that is easiest to accomplish within the bootloader.

All of this is a long way of asking if the newest os can be run with a slightly older bootloader in order to avoid burning the efuse. Even if this would cause some sort of hash check to fail that could be overcome by the exploit.

 

[Pro-me3us]

Is it known if the payload to burn the efuse is contained merely in the bootloader, like it apparently is for the ccwgtv?

I'm sure there are multiple ways of dealing with efuses, and Amazon may not choose the same path as Google. The Cube bootloader has the code to burn the eFuse, but it doesn't initiate the process. I loaded the bootloader from 7273/2622 on a Cube with an older FireOS firmware version, without triggering the eFuse to disable DFU.

Is the bootloader version for any particular raven os version tied to the particular matching raven os system?

There is a fair amount of flexibility. The exploit in the OP uses Bl2 from 7273/2625, Bl33 from 7204, and the rest from 7212/1333. And that bootloader loads on both new and old Cube firmwares. This is because a number of signature checks have been disabled. If you are asking if 7273+ will boot from the current modified bootloader, possibly, it would have to be tested. It's always possible that some new change could make the current modified bootloader fail.

For example, would the bootloader from PS7242/3516 work with the remainder of PS7285/2877?

Hard to say until tested.

It seems that if it was desired to obfuscate the nature of how the efuse is burned, this would be best accomplished if the payload was contained within the bootloader, or the same would be true if burning the efuse requires a privilege level that is easiest to accomplish within the bootloader.

All of this is a long way of asking if the newest os can be run with a slightly older bootloader in order to avoid burning the efuse. Even if this would cause some sort of hash check to fail that could be overcome by the exploit.

Possibly, I'd just be guessing if I said yes or no My impression is that Amazon has been pushing out updates more frequently the last 6-8 months. And I'm not seeing / hearing about much changing on the user side. The more changes, the more likely backwards compatibility breaks.

 

[goapy]

Thanks. Is it incorrect that there was a transition from android 7 based fire os to android 9 based fire os starting with 7273?

 

[Pro-me3us]

Thanks. Is it incorrect that there was a transition from android 7 based fire os to android 9 based fire os starting with 7273?

FireTV's use:
FireOS5 - based on Android 5.1
FireOS6 - based on Android 7.1.2
FireOS7 - based on Android 9.0

Amazon doesn't transition their Fire devices from one major OS version to another. So if you buy a FireTV with FireOS6, you can be confident that it will remain on FireOS6 (Android 7) until you stop using it.

The first gen Cube was and is still on FireOS6. The 2nd gen Cube was released with FireOS7 (Android 9). Amazon needs to keep FireOS somewhat compliant to Android guidelines to make it easier for Android developers to port their apps to FireOS. Mixing Android versions might muddy that?

Our operating system, Fire OS 7, is based on Android 9 (Pie) and API level 28, making it compatible with existing Android apps, without additional engineering effort.

FireOS8 was just released and is based on Android10 and Android11. But I'm assuming it's mostly Android 11, with some features missing/not working. Currently FireOS8 is only available on one or two Fire Tablets. None of the FireTV devices on the market today will ever see FireOS8.

 

[Sus_i]

Amazon doesn't transition their Fire devices from one major OS version to another. So if you buy a FireTV with FireOS6, you can be confident that it will remain on FireOS6 (Android 7) until you stop using it.

Sometimes they do major updates, like the fireOS3 (android 4.x) to fireOS5 update for the first fireTV box and the stick... Same for the 2018 fireHD8 tablet (karnak) which jumped from fireOS 6 to 7.

 

[goapy]

The 2nd gen Cube was released with FireOS7 (Android 9). Amazon needs to keep FireOS somewhat compliant to Android guidelines to make it easier for Android developers to port their apps to FireOS.

What's the significance of "raven:7.0" and "raven:9" in the build fingerprint?

For example, in the ota archive for PS7273/2625, in META-INF\com\android\metadata, the build fingerprint is:

Amazon/raven/raven:7.0/PS7273/2625N:user/amz-p,release-keys

Whereas, in the ota archive for PS7279/2766, in META-INF\com\android\metadata, the build fingerprint is:

Amazon/raven/raven:9/PS7279.2766N/0023253929472:user/amz-p,release-keys


The location of "7.0" and "9" is typically where the android version is indicated in non-fireos android build fingerprints. What does it mean here? If it just refers to the fireos version, why did it change from 7 to 9? Because the fireos version changed from 7 to 9 between these two releases? And if so, both are still android 9?

 

[Pro-me3us]

What's the significance of "raven:7.0" and "raven:9" in the build fingerprint?

Oh I see, I hadn't noticed that. The third gen FireSticks have also moved from using v7 to v9. I'm not entirely sure, perhaps Amazon is shifting their fingerprinting scheme to match regular Android devices.

FireOS version numbers are falling further and further behind Android just from a marketing perspective. To the layman FireOS8 is three versions behind Android11, and even more primitive looking compared to this year's Android13 (or iOS15). Maybe we are seeing the beginning of Amazon shifting towards an Android numbering scheme.

The SDK API level is still level 28 before and after the fingerprint numbering change, which leads me think the change is just superficial.