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

Search This thread

Pro-me3us

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

zygisk.png
modules.png

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.
 

Attachments

  • magisk_boot_7212-1333.zip
    8.9 MB · Views: 13
  • magisk_boot_7242-2906.zip
    8.9 MB · Views: 14
Last edited:
  • Like
Reactions: goapy

goapy

Senior Member
Dec 30, 2021
156
39
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

Member
May 12, 2022
15
20
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.
 
  • Like
Reactions: goapy

goapy

Senior Member
Dec 30, 2021
156
39
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

Member
May 12, 2022
15
20
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.
 
Last edited:

Sus_i

Senior Member
Apr 9, 2013
1,664
710
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. ;)
 
  • Like
Reactions: Pro-me3us

goapy

Senior Member
Dec 30, 2021
156
39
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?
 
Last edited:
  • Like
Reactions: Pro-me3us

Pro-me3us

Member
May 12, 2022
15
20
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.
 
  • Like
Reactions: Sus_i and goapy

Top Liked Posts

  • There are no posts matching your filters.
  • 9
    boot_menu.png

    This release temporarily enables access to all the system features on the Fire TV 2nd gen Cube. This includes unrestricted U-boot & fastboot commands, Amlogic burn mode, TWRP, FireOS with ADB root and selinux permissive, Magisk support, and booting alternative OS's from USB. As this tool is non-persistent, it will need to be reloaded from a connected computer after any reboot.



    Setup-01.jpeg


    NOTE: FireOS < 7.2.7.3 required

    NOTE: This process does not require you to open your Fire TV 2nd gen Cube


    What's needed:
    • linux installation or live-system (Ubuntu 20+ recommended)
    • micro-USB cable
    • device to put Cube into device firmware upgrade (DFU) mode [read below]
    equipment1.jpeg



    libusb is needed to for your linux installation to detect the Cube over USB.
    • sudo apt-get install libusb-1.0-0
    To automatically set the proper udev rules for Amlogic install Khadas utils:
    1. sudo apt-get install libusb-dev git
    2. sudo apt-get install git
    3. git clone https://github.com/khadas/utils
    4. cd utils
    5. ./INSTALL


    Entering the Cube's DFU mode
    To get into DFU mode we need to pass a '[email protected]' command, to the Cube's Amlogic s922x SOC, through the I2C bus accessible via the HDMI port. This was first described in the FireFU exploit for the 1st gen Cube. Since then there are a few more options for devices to accomplish this:



    Instructions
    1. Download "raven_boot.zip" and the images zip that corresponds to your Cube FireOS version.
      "images_7242-2906.zip" for FireOS 7242/2906+
      "images_7212-1333.zip" for any version earlier than 7242/2906
    2. Unzip "raven_boot.zip", and then the images zip into the "raven_boot/images" directory. Open a terminal window in the raven_boot directory.

    3. Power off the Cube
    4. Connect the HDMI dongle / board (DFU entry device) to the Cube's HDMI port, and computer to the Cube's micro-USB port.
    5. Power on the Cube, type 'lsusb' in the terminal. Confirm 'ID 1b8e:c003 Amlogic, Inc.' is listed, indicating the Cube is in DFU mode.
    6. Reconnect the Cube and TV with HDMI cable.
    7. Type 'bash menu' in the terminal, and choose your boot mode.
    To switch boot modes, repeat steps 3-7.

    Magisk.png
    root_access.png


    For bash menu option 3) booting with Magisk support, install the Magisk Manager APK (v25+ recommended) from within FireOS. https://github.com/topjohnwu/Magisk/releases, ignore the notice about required additional steps.

    IMPORTANT: This exploit is non-persistent and will require reconnecting your computer after a reboot. The exploit is run entirely in memory, and will not modify your Cube. DO NOT FLASH ANY MODIFIED IMAGES, OR INSTALL MAGISK through TWRP! This will cause an authentication error / soft brick when rebooting without the exploit present.


    About the exploit
    This exploit is based on a vulnerability in the Amlogic bootrom that allows for us to run unsigned code in the following boot stage (Bl2). To pause the automatic boot up process, before the Cube's saved Bl2 is loaded, we rely on Amlogic's device firmware upgrade mode (DFU). In DFU, only the boot code from the s922x SOC (Bl1) has been loaded into memory. We now use the vulnerability to load our modified Bl2, breaking the 'chain of trust', and disabling secure boot so that we can make modifications to the bootloader downstream. The last stage of the bootloader is U-boot (Bl33) which hands off the startup process to the boot.img. U-boot is modified to unlock any restrictions on u-boot and fastboot commands, giving us full access to system features. We can then use fastboot boot to load our modified boot images (TWRP, magisk-patched boot.img), into memory without modifying the Cube.

    Visit GitHub for a more in depth write-up and resources used in this project

    Contributors
    @Zenofex
    @npjohnson
    @zeewox
    @Pro-me3us

    Additional thanks to
    @tchebb - a bottomless encyclopedia of Amlogic knowledge, answering countless questions & troubleshooting
    @k4y0z - helping get TWRP and Magisk working
    @roligov - providing photos, additional FireOS updates, and testing
    4
    Otherwise I'll modify the sot23 version that I have coming tomorrow, replacing the sot23 at24cs02 with an 8-lead version that I can pull from some waste board.

    I did ^this^ because the 8-lead version that I ordered still hasn't arrived yet. See before/after images below. It was a success and I was able to get the exploit running.

    While swapping out the eeprom, I noticed that the ddc (display data channel) pair of lines was terminated in the plug, even though this edid emulator device supports passthrough. The ddc pair carries at least two kinds of data, edid and hdcp.

    Presumably ddc is terminated because otherwise there would be a serial wire device conflict on the i2c bus at address 0x50, since both the edid emulator device and the sink would each have a eeprom (or prom) at that address.

    But since for dfu usage the address is changed to 0x52, I figured the ddc lines could be reconnected and the 0x52 serial device could just ride on a passthrough i2c bus. So, I wired the sda and scl lines as passthrough lines.

    I hoped that this would mean that I could repeatedly use the exploit over time without swapping hdmi connections for every reboot. And it does do that. But it also takes a power cycle in order boot to dfu mode from an actively running OS. Booting any of the other images, such as fastboot, twrp, etc., do not require a power cycle and reboot straight to dfu mode with the passthrough device installed.

    So, it is still more convenient to just cycle power rather than swap hdmi plugs.

    As far as testing the exploit itself, I've only spent an hour so far. The included magisk patched boot image does work, although when I tried to boot a magisk patched boot image that I patched myself (using the original image on the device as a source), it did not boot. All of the provided boot images do work, and are all very useful.
    2
    Thanks for this! So far I've only confirmed old enough firmware (PS7229/1856) and installed a uart header. Seems I will have to wait a while to get a working hdmi plug for dfu access.

    While looking at the uart log, I noticed that u-boot is interruptible prior to boot, which is a little unusual. But every u-boot command is disabled, even "help"!

    I noticed some text about a one time override code of some sort. Did you find any additional information about this code while working on the bootloader?

    Would it not be possible to just flash a patched bootloader, much like is described at the site you've referenced? Is the stock bootloader encrypted? If so, were the relevant keys extracted?

    What about ≥ 7.2.7.3 kills this exploit? Is dfu access lost? If not, what else prevents it from working? I wouldn't think that dfu could be lost, since it is in rom, unless an efuse can disable it?
    2
    While looking at the uart log, I noticed that u-boot is interruptible prior to boot, which is a little unusual. But every u-boot command is disabled, even "help"!

    I noticed some text about a one time override code of some sort. Did you find any additional information about this code while working on the bootloader?
    On the stock bootloader Amazon has blacklisted all uboot commands. The bootloader code is available through Amazon's open source repository. The uboot console restrictions are in:
    platform/bootable/bootloader/uboot-amlogic/s922x/bl33/common/amzn_lockdown.c

    The unlock codes are generated by Amazon's servers in combination with the devices' serial number. This system is the same as other fire devices. There is a list of all the uboot commands in the documents folder of raven_boot.zip to give you an idea of what's available.

    To work with the U-boot console, you can also send uboot console commands via Amlogic burn-mode for convenience.
    Code:
    ./update bulkcmd "uboot command"

    Unfortunately, i don't think there is a way to route the uboot console output over HDMI or USB, so TX is still necessary for visualization. Your soldering work and connector look a lot nicer than what I was working with, I'm jealous :)

    Would it not be possible to just flash a patched bootloader? Is the stock bootloader encrypted? If so, were the relevant keys extracted?
    The bootloader is signed, and verified by the bootrom. This is part of the 'chain of trust' that ensures the bootloader is not altered / tampered with. The reason the patched bootloader in the OP can be loaded is because we are using a tethered computer to run a bootrom exploit program (amlogic-usbdl) to inject our own next stage code (bl2.bin) that bypasses the bootrom verification process. The modified Bl2 code allows for the rest of the bootloader to load. Without a computer to run the exploit, our Bl2 code would fail verification, and the Cube would hang.

    The bootloader is encrypted with several keys, and the keys change with major releases. I don't know what XDA's policy is on posting keys, so I don't want to chance a violation. A more detailed description of the whole process will be added to github relatively soon.

    What about ≥ 7.2.7.3 kills this exploit? Is dfu access lost? If not, what else prevents it from working? I wouldn't think that dfu could be lost, since it is in rom, unless an efuse can disable it?
    @roligov said he was not able to enter into DFU with USB after 7.2.7.3. There was an option added to the efuse file last year to disable DFU from USB, my guess is Amazon chose to burn the fuse(s) in 7.2.7.3.

    EDIT: If you plan to be do a lot of probing, I'd recommend going with Superna9999's HDMI dongle design, it's a lot more convenient than the Arduino boards.
    2
    What about ≥ 7.2.7.3 kills this exploit? Is dfu access lost? If not, what else prevents it from working? I wouldn't think that dfu could be lost, since it is in rom, unless an efuse can disable it?

    @roligov said he was not able to enter into DFU with USB after 7.2.7.3. There was an option added to the efuse file last year to disable DFU from USB, my guess is Amazon chose to burn the fuse(s) in 7.2.7.3.

    Exactly that. I had a unit that worked fine, tested DFU mode before applying update Fire OS 7.2.7.3 (PS7273/2625). After updating to that firmware version, DFU mode no longer worked. Exact same setup worked 5 minutes before and still works on other cubes. If no one on here confirms it no longer works on the latest firmware, I may sacrifice another cube and update to the latest. I thought it wasn't possible either since it's a bootrom exploit, but guessing an efuse has been burnt.

    It may be possible to probe the board and achieve DFU mode by someone who knows what they doing like the method used for the Fire Sticks (I tried with 1 cube which ended up in a bootloop, luckily Amazon replaced it).