[UNLOCK][ROOT][TWRP][UNBRICK][...] FireTV 2nd gen Cube (raven) ≤ PS7242

Search This thread

Pro-me3us

Senior Member
May 12, 2022
482
454
RavenMenuV2.png

Raven Boot v2.0 now includes persistent root. A huge thank you to @Functioner for getting it working! This package includes unrestricted U-Boot, fastboot & Amlogic burn mode commands, as well as TWRP and Magisk support. The Raven boot tool includes options to root your Cube, gain temporary root access without modifying your device, and a number of options for recovery and backup.



Setup-01.jpeg


NOTE: PS7242/3516 or older required
A newer method is available that works up to PS7292, that doesn't use DFU or a DFU device, but has no DFU recovery options

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

Changelog:
v2.2 April 7th, 2023​
  • Minor update to Magisk 25.208
    • Hopping back on official signed Magisk app line
      v2.0 and v2.1 use an unofficial Magisk build that will result in a signature mismatch when updating.
      If you are using Raven root v2.0/2.1, delete the file /data/adb/magisk.db on your Cube,
      before updating to Raven root v2.2.
  • Added USB booting for flash drives that use aml_autoscripts, for future development.
v2.1 February 18th, 2023​
  • Updated TWRP v3.6.1-9-0 ---> v3.7.0-9.0
  • Fixed problem with TWRP not always displaying all the partitions under 'Mount/Backup'
    • Always mounts 'Internal Storage' to /sdcard now
  • Fixed bash menu to always use the included fastboot binary
  • Cube's physical buttons can be used on bootup
    • Volume Up ---> Fastboot
    • Volume Down ---> TWRP recovery
    • Action button ---> Amlogic Update
**Hold down button for ~5sec after power-on, and before the blue LEDs / 1st Amazon logo​
v2.0 February 9th, 2023​
  • Root is now persistent, does not require computer after every reboot
  • One click option to install root access, TWRP, Magisk & OTA blocker module
  • Magisk updates
    • Zygisk is working (July 1st, 2022)
    • Magisk can be installed from TWRP or direct installed from within Magisk Manager
    • Created module to block Amazon OTA updates via etc/hosts and hiding the OTA apk
    • updated quick access images to Magisk v25.2
  • TWRP updates
    • Bootloader flashing is blocked, so that full OTA firmware bins can be easily flashed (tested up to PS7624/3337)
    • Removed firmware downgrade checks & warnings
    • Added NTFS support for flash drives within TWRP
  • Added options to backup entire reserved partition, and mmcblk0boot0 & mmcblk0boot1 boot partitions in Amlogic update
  • Added emergency boot to Fastboot/Update modes
v1.0 May 15th, 2022​
  • Temporary unrestricted fastboot, u-boot & update commands
  • Boot with root access or Magisk support
  • Boot to TWRP for backup & recovery
  • Backup Cube using Amlogic Update


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



libusb is needed 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


***NOTE: If you previously installed Magisk on your Cube from raven_boot v1.0, first run adb shell rm /data/adb/magisk.db to prevent any conflicts with the new Magisk version.

Instructions
  1. Download the latest raven_boot.zip and unzip it. Open a terminal window from the unzipped raven_boot directory

  2. Power off the Cube and connect your DFU device to the Cube's HDMI port. Connect the USB cable (microUSB to USB-type A) to computer & Cube

  3. Power on the Cube, type lsusb in the terminal to confirm ID 1b8e:c003 Amlogic, Inc. is present, indicating the Cube is in DFU mode

  4. Unplug the DFU device from the HDMI port, reconnect the Cube to TV with HDMI cord. Keep the computer connected.

  5. In the terminal type bash menu, and choose option 1) to automatically root the Cube.
To preserve the Cube's persistent root, be sure to confirm that both TWRP & Magisk are installed.

Quick Access
For options 2) and 3) to gain temporary root, download the images zip file that corresponds to your current FireOS version, and unzip the contents into raven_boot/images directory.​
For Cubes running FireOS 7242/2896 or later get ---> images_7242-2906_v2.0.zip​
For FireOS versions 7201/942 to 7242/2216 get ---> images_7229-1853_v2.0.zip​

magisk.png
root_access.png

Magisk v25.206 is included with Raven boot, it's recommened that you use this version or newer. For instructions on how to update your firmware and keep root access, read here


About the exploit
This exploit is based on a vulnerability in the Amlogic bootrom that allows for us to run unsigned code in the next 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 Amlogic s922x SOC (Bl1) has been loaded into memory. We then 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 kernel (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's eMMC.

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

Contributors
@Functioner
@Zenofex
@npjohnson
@zeewox
@Pro-me3us

Additional thanks to
@tchebb - a bottomless encyclopedia of Amlogic knowledge, answering countless questions & troubleshooting
@roligov - providing photos, additional FireOS updates, and testing
@osm0sis, @canyie, @vvb2060 & @yujincheng08 - the Magisk team for being awesome, troubleshooting and making a number of code changes to get all features working on the Cube
@k4y0z - helping troubleshoot some TWRP and Magisk issues
 

Attachments

  • images_7242-2906.zip
    17.5 MB · Views: 218
  • images_7212-1333.zip
    17.5 MB · Views: 120
  • raven_boot.zip
    36.8 MB · Views: 220
  • 2nd_gen_cube_top.jpg
    2nd_gen_cube_top.jpg
    2.3 MB · Views: 607
  • 2nd_gen_cube_bottom.jpg
    2nd_gen_cube_bottom.jpg
    2.1 MB · Views: 567
  • raven_boot_v2.0.zip
    51.3 MB · Views: 74
  • images_7242-2906_v2.0.zip
    17.5 MB · Views: 48
  • images_7229-1853_v2.0.zip
    17.5 MB · Views: 46
  • raven_boot_v2.1.zip
    51.7 MB · Views: 79
  • raven_boot_v2.2.zip
    51.7 MB · Views: 84
Last edited:

Pro-me3us

Senior Member
May 12, 2022
482
454
Entering the Cube's DFU mode
To boot into device firmware upgrade (DFU) mode we need to pass a 'boot@usb' 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:

 
Last edited:
  • Like
Reactions: Kramar111

Pro-me3us

Senior Member
May 12, 2022
482
454
Flashing OTA Firmware with TWRP
To upgrade the firmware past PS7273+ and keep the Cube unlocked and rooted, we need to avoid flashing any bootloader version newer than PS7242/3516. The new build of TWRP included with Raven boot v2.0+ and Raven root shrinker automatically blocks any bootloader flashing. Be sure that you are using Raven boot v2.0 or newer! Firmware bin flashing is working and tested up to PS7633/3445.

The shrinker script only works up to PS7624/3337, upgrading past this version will still maintain root, but will lose the shrinker backdoor backup.

Update Procedure:
1) Download the full firmware bin (XDA or Github), change extention .bin to .zip

2) In ADB type reboot recovery to enter TWRP. You can also open Magisk Manager and choose the reboot to recovery option in the top right corner of the main screen.

3) Copy the firmware file to your Cube via USB connected computer, flash it, and re-flash Magisk
Code:
adb push <firmware-filename.zip> /sdcard/Download/
adb shell
twrp install /sdcard/Download/<firmware-filename.zip>
twrp install /sdcard/Download/magisk.apk
If you used the shrinker method, then the magisk apk is in /data/local/tmp/ instead
Code:
twrp install /data/local/tmp/magisk.apk

If you prefer to use a USB mouse and regular TWRP interface, rather than computer, download the firmware bin directly to the Cube in FireOS. Firmware updates don't require wiping data/dalvik. If downgrading firmware, wiping data/dalvik is advisable.

NOTE: It's IMPORTANT to not forget to flash magisk.apk after each firmware upgrade. Magisk & TWRP work together to preserve root access. Magisk prevents TWRP from being deleted, and TWRP helps to prevent accidental Amazon OTA updates. Without Magisk, OTA updates will no longer be blocked by the OTA blocker Magisk module.


Protected Packages
Amazon added package protection in +PS7273. To remove this, boot into FireOS with Magisk or root support, edit /data/system/PackageManagerDenyList, delete the list of applications, and save.

To prevent the protected applications list from being regenerated on reboot, disable:
Code:
adb shell pm disable-user com.fireos.arcus.proxy
All applications can now be disabled/enabled without root, including custom launchers.
 
Last edited:
  • Like
Reactions: BTK19
D

Deleted member 11959327

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

Attachments

  • cube-g2-uart_001.jpg
    cube-g2-uart_001.jpg
    137.4 KB · Views: 234
  • cube-g2-uart_002.jpg
    cube-g2-uart_002.jpg
    111.2 KB · Views: 240
  • cube-g2-uart_003.jpg
    cube-g2-uart_003.jpg
    36.5 KB · Views: 235
Last edited by a moderator:
  • Like
Reactions: Sus_i and Pro-me3us

Pro-me3us

Senior Member
May 12, 2022
482
454
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.
 
Last edited:

roligov

Senior Member
Dec 29, 2012
308
110
London
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).
 
D

Deleted member 11959327

Guest
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 bootloader is encrypted with several keys, and the keys change with major releases.
Whatever bootloader keys are used for the chain of trust in order to ensure an internally consistent hand-off from stage to stage are distinct from the most external bootrom key that is used to encrypt the entire bootloader partition image from start to finish, right? That most "external layer" bootrom key, that is used to encrypt the entire bootloader partition image, must remain the same for the life of all instances of the hardware, at least if all similar devices are to be able to run firmware updates, right?

By the "most external layer" of encryption, I mean this layer;

bl-ext-aes.jpg


If a device that is configured for secure boot, as distinguished from a device that is not configured for secure boot, like the khadas VIM3L (but still has a bootloader partition that is at least encrypted with the most external layer key), could it not run a different bootloader (that was internally consistent and unmodified), so long as that bootloader was encrypted with a matching most external layer key? Does secure boot prevent this?

For example, if an entire bootloader was taken intact from a generic 922 device, and that entire bootloader was not internally modified at all (but happened to have a functioning u-boot bl33 layer), and that entire bootloader (after itself being decrypted with its most external layer bootrom key, if necessary) was encrypted with the most external layer key matching the v2 cube, would that bootloader not boot all the way to bl33 and beyond on the v2 cube?

Perhaps an internally consistent alternative bootloader, even if if properly encrypted with the most external layer bootroom key, would still break the chain of trust because the portion of the bootloader that is in rom (bl1) is not just generic bootloader code common to many devices, but is customized specifically for that particular secure boot device (or references a root of trust elsewhere in the rom that is individualized), so the subsequent bootloader stages would fail trust because of that individualization that is in, or referenced by, bl1, even if they were entirely unmodified?

Perhaps this bootloader might boot but avb or vbmeta verification might fail in some other way, or whatever drm magic is in the bootloader might be absent, but would it not at least boot, or does secure boot prevent any internally consistent alternative bootloader from booting, even if it is encrypted with the correct most external layer key, matching the bootrom key?

I apologize if I'm missing something obvious because of my impoverished understanding of this process.
 
Last edited by a moderator:
D

Deleted member 11959327

Guest
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.
Do you have any guesses about how the efuse is burnt by the updated system? Might the new bootloader itself do it, or the running system, or is there anything obvious in updater-script (if amazon ota's use an updater-script)?
 
D

Deleted member 11959327

Guest
It seems that all of the quickly obtainable edid-spoofing hdmi plugs come with an eeprom in the sot23 package, lacking the a0, a1, and a2 pins needed for the addressing change. Does anyone know of a hdmi plug that uses an 8-lead eeprom that can be ordered for quick delivery?

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.
 

Pro-me3us

Senior Member
May 12, 2022
482
454
Do you have any guesses about how the efuse is burnt by the updated system? Might the new bootloader itself do it, or the running system, or is there anything obvious in updater-script (if amazon ota's use an updater-script)?
At power on Amlogic devices will print a string of SOC information that starts with G12B:BL....
in that string is F2FB39B0:432060. The 2 values report the security efuse status for the device. 32bit values:
CFG9: 0x00432060
CFG10: 0xF2FB39B0

Following 7273/2625 there is a 1 bit change in CFG10
CFG10: 0xF2FB39B0 (pre 7273) = 1111 0010 1111 1011 0011 1001 1011 0000
CFG10: 0xF2F339B0 (post 7273) = 1111 0010 1111 0011 0011 1001 1011 0000

Bits are read from right to left starting with bit 0, so Flag 19 flips from 1 to 0. The security efuse table shows that an efuse was buned to disable 'IS_FEAT_USB_BOOT_ENABLE', barring DFU entry via USB.

There is little documentation on how to burn efuses, more importantly I don't know of any public information on the efuse addresses that correspond to which features. Burning efuses would have to be done through uboot and the Bl31api which is how non-secure world talks to secure world. Amazon may handle it through cmd_efuse.c, since there was an addition to that code made to disable USB boot in 2021. The following can be found in the 2nd gen Cube package from Amazon's open source page
platform/bootable/bootloader/uboot-amlogic/s922x/bl33/common/cmd_efuse.c

Whatever bootloader keys are used for the chain of trust in order to ensure an internally consistent hand-off from BL stage to BL stage are distinct from the most external bootrom key that is used to encrypt the entire bootloader partition image from start to finish, right? That most "external layer" bootrom key, that is used to encrypt the entire bootloader partition image, must remain the same for the life of all instances of the hardware, at least if all similar devices are to be able to run firmware updates, right?
There are several layers of security, including encryption and signed code. The s922x contains an AES key which is static, and it can be used to decrypt the bootloader. The Cube has boot decrypt enabled, meaning that it is expecting Bl2 to be encrypted, and it will decrypt anything passed to it with the internal AES key. Amazon takes things a step further and encrypts the later bootloader stages with 3 more AES keys. So to fully decrypt the bootloader there are 4 total keys, one of which is static.

But in the case of the Cube, decryption is not an issue since we can dig to get all the keys. The keys just allow the SOC to unscramble the image. There is also signing which involves image hashes. By modifying the image, the hash changes, failing the signature check. The function of the amlogic-usbdl exploit is to bypass the code verification, not encryption.

The Bl2 signing tool is public but Bl2 is not open source. I don't know how functional the Bl2.bin is that is included in the firetv open source repository. There's likely also other security checks I'm overlooking.

For example, if an entire bootloader was taken intact from a generic 922 device, and that entire bootloader was not internally modified at all (but happened to have a functioning u-boot bl33 layer), and that entire bootloader (after itself being decrypted with its most external layer bootrom key, if necessary) was encrypted with the most external layer key matching the v2 cube, would that bootloader not boot all the way to bl33 and beyond on the v2 cube?
If it was from a generic device without any security features implemented in the bootloader maybe? The Cube has a root key burned to it that I assume is specific to the 2nd gen Cube. I believe this is used in verifying bl2.

There would be hardware/board differences that would lead to a host of issues as well. Uboot would be missing the FireOS layer, so I would be surprised if it could hand things off properly. Bl2 would still have to be encrypted using the AES key, since the Cube has boot encrypt enabled, which is doable.

That could be tested with Amlogic's update tool in DFU.
Code:
./update write bl2.bin 0xfffa0000 //loads bl2 into memory at the run address
./update run 0xfffa0000  //executes bl2 from memroy
./update bl2_boot bootloader.img //loads and runs the rest of the bootloader into and from memory

The closest thing to Khasdas' VIM3L for the s922x is the Odroid N2/+, in terms of a developer's board with little to no security features implemented. The unsigned Cube bootloader will load fairly far on the N2+, but I don't remember if it got as far as the kernel. I never tried the reverse, loading an N2+ bootloader on the Cube.
 
Last edited:
D

Deleted member 11959327

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

Attachments

  • plug_001.jpg
    plug_001.jpg
    1.8 MB · Views: 174
Last edited by a moderator:

Pro-me3us

Senior Member
May 12, 2022
482
454
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.
That's a very nice improvement over Superna9999's design, you should share this with him :D I did start to strip the plating on my HDMI cable from all the plugging/unplugging during testing. With this design, does the Cube end up powering two ICs, the one on the dongle and the one in the TV HDMI port? Are there any issues having the Cube power both?

Even with the original design, I think a power cycle is required to get into DFU, rather that just a reboot. I remember adb rebooting would cause the Cube to keep resetting until a power cycle or the dongle was removed. It may be that there is a bootrom level 'reboot reason' stored in volatile memory, that's not cleared until power cycling? If you send a reboot command from u-boot / burn mode are you put in DFU, or do you still need to power cycle? I briefly looked for a command to reboot into DFU (without I2C), but couldn't find anything.

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.
You'll need to use a canary build of Magisk to make your own patched boot.img. There is an Amlogic quirk that probably affects many slot A only devices. Amlogic uses the suffix 'normal' rather than '_a', which is not recognized by Magisk. A patch was added to ignore the suffix in canary build ~24.310.

When patching the boot.img with Magisk, choose recovery mode and leave vbmeta unchecked. Using the regular boot mode (not recovery mode), results in a mount/unmount loop during bootup. The cause of this will have to be worked out long-term for a persistent root. Right now SU works for Magisk but Zygisk doesn't. I'm not sure if that is a limitation of loading Magisk with fastboot boot, or because recovery mode is being used to create the patch.

You will also want to enable UART output from the kernel. This will be applied to your Cube automatically by choosing bash menu 1) boot to FireOS with ADB root / permissive. You can do it manually by booting to fastboot
Code:
fastboot oem flags fos: 0x4

The flags are stored in IDME and can also be changed directly there
Code:
fastboot oem IDME fos_flags 0x4
The IDME values will persist without the exploit, but values like
ADB root and DM-verity off will be ignored/rejected by the native bootloader when uboot determines the Cube is not an engineering device (defined as ARB=0). But the console enable value will be accepted, letting you see native FireOS uart output.

EDIT: I added the 31 IDME properties that can be edited
 

Attachments

  • fastboot_flags.zip
    1.1 KB · Views: 48
Last edited:
  • Like
Reactions: BTK19 and Sus_i
D

Deleted member 11959327

Guest
With this design, does the Cube end up powering two ICs, the one on the dongle and the one in the TV HDMI port? Are there any issues having the Cube power both?
I don't think current draw is a problem. A 24c02 eeprom draws 1 mA max when reading, and 5 μA max when in standby. Even if both eeproms on the bus were read at the same, that would not be a lot of current. There is only one read operation of each serial device per power cycle.

Consider another edid emulator with passthrough, the gofanco prophecy. The gofanco emulator has not only two onboard 24c02 eeproms, but also a 3AQ20 MCU and a hc4052 mux/demux IC, all powered by the hdmi port.

You'll need to use a canary build of Magisk to make your own patched boot.img. There is an Amlogic quirk that probably affects many slot A only devices. Amlogic uses the suffix 'normal' rather than '_a', which is not recognized by Magisk. A patch was added to ignore the suffix in canary build ~24.310.

Thanks. I didn't realize that 24.310 was used on the supplied image or that a recovery style patch was required. Now it all works.

The flags are stored in IDME and can also be changed directly there
Code:
fastboot oem IDME fos_flags 0x4
The IDME values will persist without the exploit, but values like
ADB root and DM-verity off will be ignored/rejected by the native bootloader when uboot determines the Cube is not an engineering device (defined as ARB=0). But the console enable value will be accepted, letting you see native FireOS uart output.

EDIT: I added the 31 IDME properties that can be edited

Thanks for the list of IDME properties. I'm getting up to speed now. It's quite different than the typical amlogic setup. No env or vbmeta partitions. There doesn't seem to be any vulnerabilities like the uboot/rsv exploit used for the gen 1 cube.
 
Last edited by a moderator:
  • Like
Reactions: Pro-me3us

Pro-me3us

Senior Member
May 12, 2022
482
454
I don't think current draw is a problem. A 24c02 eeprom draws 1 mA max when reading, and 5 μA max when in standby. Even if both eeproms on the bus were read at the same, that would not be a lot of current. There is only one read operation of each serial device per power cycle.
Oh ok that's a minuscule amount. I think HDMI ports are rated for 50-300mA output. Are you able to passthrough 4k 30FPS, 60FPS (Youtube for example) with the one of those connected? Or DV/HDR? I'm curious if a dongle like that could be left in for regular use of the device.

Thanks for the list of IDME properties. I'm getting up to speed now. It's quite different than the typical amlogic setup. No env or vbmeta partitions. There doesn't seem to be any vulnerabilities like the uboot/rsv exploit used for the gen 1 cube.
Yeah an ENV partition would have made things a lot easier. Most Fire devices are MediaTek based, and the Cube is sort of alone in the use of U-Boot. There's also the 1st gen Cube and Pendant, but they are getting hard to come by. Frederic's exploit will probably work for any G12A/G12B/SM1 SOC from Amlogic, including the 1st gen Cube and Pendant, but I don't have one to test and make the necessary modifications. Amazon no longer sells these two models, and I'm assuming they also lost DFU access with the February/March update.

I think the uboot/rsv exploit got patched pretty soon after the FireFU release. I also checked aml_emmc_partition.c for the 2nd gen Cube and it was patched by the release version 7.2.0.4.

There is the u-boot vulnerability database. I don't know if any of these are present or useful on the Cube, testing them is above my skill level. I was only able to apply Frederic's exploit to the Cube because he documented everything very well.

I've posted a draft of the raven exploit on github with a little more information. I still need to edit it a bit, but the outline is there.
 
Last edited:
D

Deleted member 11959327

Guest
Are you able to passthrough 4k 30FPS, 60FPS (Youtube for example) with the one of those connected? Or DV/HDR? I'm curious if a dongle like that could be left in for regular use of the device.
It all seems to work so far. All 19 lines are wired as passthrough. The passthrough hdmi ddc link doesn't seem to be bothered by having a non-standard i2c address eeprom on the bus.

I've posted a draft of the raven exploit on github with a little more information. I still need to edit it a bit, but the outline is there.
That's a very illuminating writeup. It instantly filled in a lot of holes in my understanding.

That also seems to have been quite a lot of work, thanks again for sharing it all.
 

Pro-me3us

Senior Member
May 12, 2022
482
454
Isn't that most projects, more work than initially anticipated :LOL:

I did all my testing with the ribbon cable to the physical buttons disconnected. Can you check something for me since you have UART access with the buttons active?

When in FireOS, holding down the Cube action button (button with dot) for 15sec kills all processes and appears shut the device down. But the device is not powered off, the mute button still turns on/off. If you boot into FireOS with the adb root/permissive option, what does the UART output say when doing this?

In this mode, if I press the action button again the Cube reboots, but if I press any of the other buttons, and then action, the Cube does not reboot. So I'm wondering if the Cube is being dropped into some sort of diagnostic that may be accessible from UART.

I'd be interested in seeing any of the UART output including the reboot string
Code:
G12B:BL:6e7c85:2a3b91;FEAT:F2FB39B0:432060;POC:7;RCY:1;USB:3;

I don't know if there are any hidden button combinations when powering the device on that do anything. I'm not sure where that would be defined in the source code. Holding the vol - button during bootup puts the Cube in safe mode. I don't think there are any other known power up button functions yet.
 
D

Deleted member 11959327

Guest
When in FireOS, holding down the Cube action button (button with dot) for 15sec kills all processes and appears shut the device down. But the device is not powered off, the mute button still turns on/off. If you boot into FireOS with the adb root/permissive option, what does the UART output say when doing this?

I'm pretty sure that I executed the sequence described above. Advise If the following is not the correct sequence;

1. boot into FireOS with the adb root/permissive option
2. after fully booted, hold the action button for 15sec
3. after shutdown, try alternatively pressing buttons other than the action button
4. compare the results (of initially pressing buttons other than the action button after shutdown) to pressing the action button without first pressing other buttons.

Code:
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2022.06.08 16:45:42 =~=~=~=~=~=~=~=~=~=~=~=
idme_platform_write block_offset=3e7000, capacity=400000
fos_flags set to 87
idme_platform_write block_offset=3e7000, capacity=400000
dev_flags set to 64
cmd cb_download is download:008f2800
Starting download of 9381888 bytes
.......................................................................
downloading of 9381888 bytes finished
Booting kernel...success
boot_addr_start bootm 0x1080000
kernel_size 0x8af0af, page_size 0x800, totalSz 0x8b0000
ramdisk_size 0x0, totalSz 0x0
dtbSz 0x42000, Total actualBootImgSz 0x8f2000
amzn_verify_onetime_unlock_code: Verify one time unlock cert fail, ret = -5
ee_gate_off ...
## Booting Android Image at 0x01080000 ...
reloc_addr =73d75610
copy done
Kernel command line: rootfstype=ext4 ro rootwait skip_initramfs OTG_mode=DEVICE androidboot.selinux=permissive
load bootimage dtb from 0x74625610 ......
.
.
.

[  105.592503@4] input input0: key 138 down.

.
.
.

[  121.598891@2] vendor_write_shutdown_reason: shutdown_reason 0x0
[  122.598985@2] hdmitx: hw: avmute set to 2
[  122.699063@2] ISSI: resetting device before reboot!
[  122.702896@2] meson-mmc: meson_mmc_clk_set_rate_v3 269
[  122.703003@2] meson-mmc: actual_clock :0, HHI_nand: 0x80
[  122.703497@2] meson-mmc: [meson_mmc_clk_set_rate_v3] after clock: 0x10100002
[  122.705549@2] amvecm: shutdown module
[  122.705735@2] di pre hrtimer canel 1.
[  122.705764@2] [DI] shutdown done.
[  122.706176@2] vout: vout2: aml_vout2_shutdown
[  122.706925@2] vout: aml_vout_shutdown
[  122.707185@2] fb: osd_shutdown
[  122.707569@2] amvdac_drv_shutdown: shutdown module
[  122.708205@0] reboot: Power down
bl31 reboot reason: 0x108
bl31 reboot reason: 0x108
system cmd  0.
bl30 get wakeup sources!
process command 00000006
bl30 enter suspend!
Little core clk suspend rate 1908000000
Big core clk suspend rate -2086967296
store restore gp0 pll
suspend_counter: 1
Enter ddr suspend
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24

The above log happened both when the action button was pressed and also when any other button was pressed instead (after shutdown). New lines containing "DMC_DRAM_STAT11: 0x24" are repeated endlessly, or at least for the 10 minutes that I let it run.

if I press the action button again the Cube reboots, but if I press any of the other buttons, and then action, the Cube does not reboot

I could not get the Cube to reboot if I pressed the action button again after shutdown. Perhaps I wasn't supposed to wait to press it until the shutdown was complete?

A reboot string never appeared, just ""DMC_DRAM_STAT11: 0x24"" endlessly until the power was cycled.

I'm still running PS7229/1856. I don't have an ota for an android 9 version of fireos that is not the current version.

If this is some sort of standby mode, I can't seem to wake out of it.
 
Last edited by a moderator:
D

Deleted member 11959327

Guest
Do you happen to know why a uart command prompt console can't be started? If;

start console

is executed in a shell with root access, it appears to execute successfully, but no console command prompt appears over the uart connection.

Edit: resolved, disregard.
 
Last edited by a moderator:

Pro-me3us

Senior Member
May 12, 2022
482
454
The above log happened both when the action button was pressed and also when any other button was pressed instead (after shutdown). New lines containing "DMC_DRAM_STAT11: 0x24" are repeated endlessly, or at least for the 10 minutes that I let it run.
Ah ok, maybe it is only a shutdown command in that case. The reboot reason 0x108 might be SHUTDOWN_LONG_PWR_KEY_PRESS according to sign_of_life_vendor.c. This looks similar to adb reboot -p which is a software shutdown (0x109?). After a software shutdown the Cube can also be rebooted with the action button. There may be no way to completely shutdown Cube without a real power button. I don't know why in this state pressing the action button doesn't consistently reboot.

Pressing the power button on the remote might also put the Cube in a similar suspension state that does allow waking.


Do you happen to know why a uart command prompt console can't be started? If;

start console

is executed in a shell with root access, it appears to execute successfully, but no console command prompt appears over the uart connection.

Edit: resolved, disregard.
I only ever used UART for logs while the kernel was loaded. I never tried to bring up a command prompt. Did you manage to get input working through UART?

For fos_flags the default is 0x0. If you are using the bash menu script it is setting the fos_flags to 0x87 each time FireOS with ADB root is booted. You will have to fastboot boot the image manually to avoid that. You can also set the Flag values with ADB root using the command 'idme fos_flags value'.

The focus was pretty narrow while working on getting the exploit working. I didn't spend much time with the bootrom. Frederic gave me most of the addresses I needed once the bootrom was extracted. I haven't heard of anyone finding extra I2C commands. Both the FireFU and Superna9999 page mention boot@SPI, but I don't know if that actually works.

You can take a look to see if there is anything interesting. To dump the Cube bootrom run the following command with the zipped files:
Code:
sudo ./amlogic-usbdl  memdump_over_usb_s922x.bin cube_bootrom

There is also the question of what that missing 20pin connector is on the Cube PCB.
 

Attachments

  • dump_over_usb.zip
    7.9 KB · Views: 43

Top Liked Posts

  • There are no posts matching your filters.
  • 14
    RavenMenuV2.png

    Raven Boot v2.0 now includes persistent root. A huge thank you to @Functioner for getting it working! This package includes unrestricted U-Boot, fastboot & Amlogic burn mode commands, as well as TWRP and Magisk support. The Raven boot tool includes options to root your Cube, gain temporary root access without modifying your device, and a number of options for recovery and backup.



    Setup-01.jpeg


    NOTE: PS7242/3516 or older required
    A newer method is available that works up to PS7292, that doesn't use DFU or a DFU device, but has no DFU recovery options

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

    Changelog:
    v2.2 April 7th, 2023​
    • Minor update to Magisk 25.208
      • Hopping back on official signed Magisk app line
        v2.0 and v2.1 use an unofficial Magisk build that will result in a signature mismatch when updating.
        If you are using Raven root v2.0/2.1, delete the file /data/adb/magisk.db on your Cube,
        before updating to Raven root v2.2.
    • Added USB booting for flash drives that use aml_autoscripts, for future development.
    v2.1 February 18th, 2023​
    • Updated TWRP v3.6.1-9-0 ---> v3.7.0-9.0
    • Fixed problem with TWRP not always displaying all the partitions under 'Mount/Backup'
      • Always mounts 'Internal Storage' to /sdcard now
    • Fixed bash menu to always use the included fastboot binary
    • Cube's physical buttons can be used on bootup
      • Volume Up ---> Fastboot
      • Volume Down ---> TWRP recovery
      • Action button ---> Amlogic Update
    **Hold down button for ~5sec after power-on, and before the blue LEDs / 1st Amazon logo​
    v2.0 February 9th, 2023​
    • Root is now persistent, does not require computer after every reboot
    • One click option to install root access, TWRP, Magisk & OTA blocker module
    • Magisk updates
      • Zygisk is working (July 1st, 2022)
      • Magisk can be installed from TWRP or direct installed from within Magisk Manager
      • Created module to block Amazon OTA updates via etc/hosts and hiding the OTA apk
      • updated quick access images to Magisk v25.2
    • TWRP updates
      • Bootloader flashing is blocked, so that full OTA firmware bins can be easily flashed (tested up to PS7624/3337)
      • Removed firmware downgrade checks & warnings
      • Added NTFS support for flash drives within TWRP
    • Added options to backup entire reserved partition, and mmcblk0boot0 & mmcblk0boot1 boot partitions in Amlogic update
    • Added emergency boot to Fastboot/Update modes
    v1.0 May 15th, 2022​
    • Temporary unrestricted fastboot, u-boot & update commands
    • Boot with root access or Magisk support
    • Boot to TWRP for backup & recovery
    • Backup Cube using Amlogic Update


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



    libusb is needed 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


    ***NOTE: If you previously installed Magisk on your Cube from raven_boot v1.0, first run adb shell rm /data/adb/magisk.db to prevent any conflicts with the new Magisk version.

    Instructions
    1. Download the latest raven_boot.zip and unzip it. Open a terminal window from the unzipped raven_boot directory

    2. Power off the Cube and connect your DFU device to the Cube's HDMI port. Connect the USB cable (microUSB to USB-type A) to computer & Cube

    3. Power on the Cube, type lsusb in the terminal to confirm ID 1b8e:c003 Amlogic, Inc. is present, indicating the Cube is in DFU mode

    4. Unplug the DFU device from the HDMI port, reconnect the Cube to TV with HDMI cord. Keep the computer connected.

    5. In the terminal type bash menu, and choose option 1) to automatically root the Cube.
    To preserve the Cube's persistent root, be sure to confirm that both TWRP & Magisk are installed.

    Quick Access
    For options 2) and 3) to gain temporary root, download the images zip file that corresponds to your current FireOS version, and unzip the contents into raven_boot/images directory.​
    For Cubes running FireOS 7242/2896 or later get ---> images_7242-2906_v2.0.zip​
    For FireOS versions 7201/942 to 7242/2216 get ---> images_7229-1853_v2.0.zip​

    magisk.png
    root_access.png

    Magisk v25.206 is included with Raven boot, it's recommened that you use this version or newer. For instructions on how to update your firmware and keep root access, read here


    About the exploit
    This exploit is based on a vulnerability in the Amlogic bootrom that allows for us to run unsigned code in the next 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 Amlogic s922x SOC (Bl1) has been loaded into memory. We then 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 kernel (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's eMMC.

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

    Contributors
    @Functioner
    @Zenofex
    @npjohnson
    @zeewox
    @Pro-me3us

    Additional thanks to
    @tchebb - a bottomless encyclopedia of Amlogic knowledge, answering countless questions & troubleshooting
    @roligov - providing photos, additional FireOS updates, and testing
    @osm0sis, @canyie, @vvb2060 & @yujincheng08 - the Magisk team for being awesome, troubleshooting and making a number of code changes to get all features working on the Cube
    @k4y0z - helping troubleshoot some TWRP and Magisk issues
    4
    D
    Deleted member 11959327
    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.
    4
    EDIT: This procedure has been revised, please follow the instructions here

    Flashing OTA Firmware with TWRP
    To upgrade the Cube firmware past PS7273+ and keep this exploit working, we need to avoid flashing any bootloader version newer than PS7242/3516. The following procedure removes the bootloader flashing instructions from the OTA firmware, so that everything but the bootloader is updated. After updating, the Cube will still boot normally with or without the exploit loaded. Tested & working up to PS7614/3227.

    Modify the firmware:
    1) Download 2nd gen Cube full firmware (XDA or Github), change extention .bin to .zip, and open the file.

    2) Open /META-INF/com/google/android/updater-script in a text editor, delete the following block of code:
    Code:
    # Bootloader
    if (getprop("ro.boot.secure_cpu") == "0")
    then
        ui_print("Copying bootloader for non secure device...");
        write_bootloader_image(package_extract_file("images/u-boot.bin"), "bootloader");
    else
        ui_print("Copying bootloader for secure device...");
        write_bootloader_image(package_extract_file("images/u-boot.bin.signed"), "bootloader");
    endif;

    3) Save modified updater-script to the firmware .zip.



    TWRP Flashing procedure:
    1) Boot Cube into TWRP with the bash menu script [Option (3, Suboption (1].
    Code:
    adb push <firmware-filename.zip> /sdcard
    adb shell
    twrp install <firmware-filename.zip>
    Done! reboot

    *2) Flashing can also be done through the TWRP gui using the 'install' button if you prefer


    IMPORTANT: Keep system updates blocked, and only flash firmware through TWRP using this procedure. Firmware upgrades don't require wiping data/cache/dalvik, but if you are downgrading firmware, wiping data may be advisable.


    Note: Amazon added package protection in +PS7273. To remove this, boot into FireOS with root access, edit /data/system/PackageManagerDenyList, delete the list of applications, and save.

    The list of protected applications will be regenerated after every reboot (obtained from Amazon server), to prevent this:
    Code:
    adb shell pm disable-user com.fireos.arcus.proxy

    Custom launcher use, and the ability to disable/enable any system app will work when booting with or without the exploit.
    4
    I've made a post for booting CoreELEC on unlocked 2nd gen Cubes here.

    CoreELEC is a minimal Linux OS that only runs Kodi. This boots and runs 100% from a USB stick, and will not affect FireOS at all. Simply plug the USB drive into your Cube, reboot, and it will boot from the USB stick. Shutdown CoreELEC when you are done, unplug the USB stick, press the 'action' button on the Cube and it will boot back to FireOS.

    A few of the benefits include lossless audio passthrough support for TrueHD/DTS-MA etc. OS only uses about 400-500MB of the 2GB available.

    This is still a beta in testing. Looking for feedback on what is an isn't working
    3
    I'll see if I can simplify things any further. I tried to find a way to have TWRP automatically skip over the Bootloader code, but there is no simple solution.

    I made a minor TWRP edit that should avoid and date/downgrade warnings, put the image in raven_boot/images.

    Lastly I made an updated magisk patched boot image using the kernel from PS7614/3227 since there have been +10 updates since PS7242/2906 (still worked fine with PS7614/3227 anyways). It's probably about time to make a new version of the OP files, I was just waiting on the next release of Magisk.

    I've been able to both upgrade and downgrade. I'm testing PS7614/3227 now, and as far as I can tell everything is working without any problems.

    PS if anyone is running a firmware below PS7273 and not one of the following, please backup your unit and let me know for the archive:
    PS7212/1333
    PS7229/1853
    PS7229/1856
    PS7242/2906
    PS7242/3516