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

Search This thread

Pro-me3us

Member
May 12, 2022
10
15
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
 

Attachments

  • images_7242-2906.zip
    17.5 MB · Views: 63
  • images_7212-1333.zip
    17.5 MB · Views: 35
  • raven_boot.zip
    36.8 MB · Views: 82
  • 2nd_gen_cube_top.jpg
    2nd_gen_cube_top.jpg
    2.3 MB · Views: 74
  • 2nd_gen_cube_bottom.jpg
    2nd_gen_cube_bottom.jpg
    2.1 MB · Views: 77
Last edited:

goapy

Senior Member
Dec 30, 2021
133
34
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: 9
  • cube-g2-uart_002.jpg
    cube-g2-uart_002.jpg
    111.2 KB · Views: 9
  • cube-g2-uart_003.jpg
    cube-g2-uart_003.jpg
    36.5 KB · Views: 9
Last edited:
  • Like
Reactions: Sus_i and Pro-me3us

Pro-me3us

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

roligov

Senior Member
Dec 29, 2012
292
103
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).
 
  • Like
Reactions: goapy and Sus_i

goapy

Senior Member
Dec 30, 2021
133
34
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:

goapy

Senior Member
Dec 30, 2021
133
34
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)?
 

goapy

Senior Member
Dec 30, 2021
133
34
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

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

goapy

Senior Member
Dec 30, 2021
133
34
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: 5
Last edited:

Pro-me3us

Member
May 12, 2022
10
15
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: 11
Last edited:
  • Like
Reactions: BTK19 and Sus_i

goapy

Senior Member
Dec 30, 2021
133
34
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:
  • Like
Reactions: Pro-me3us

Pro-me3us

Member
May 12, 2022
10
15
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:

goapy

Senior Member
Dec 30, 2021
133
34
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.
 
  • Like
Reactions: Finnzz

Pro-me3us

Member
May 12, 2022
10
15
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.
 

goapy

Senior Member
Dec 30, 2021
133
34
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 ......
.
.
.

[  [email protected]] input input0: key 138 down.

.
.
.

[  [email protected]] vendor_write_shutdown_reason: shutdown_reason 0x0
[  [email protected]] hdmitx: hw: avmute set to 2
[  [email protected]] ISSI: resetting device before reboot!
[  [email protected]] meson-mmc: meson_mmc_clk_set_rate_v3 269
[  [email protected]] meson-mmc: actual_clock :0, HHI_nand: 0x80
[  [email protected]] meson-mmc: [meson_mmc_clk_set_rate_v3] after clock: 0x10100002
[  [email protected]] amvecm: shutdown module
[  [email protected]] di pre hrtimer canel 1.
[  [email protected]] [DI] shutdown done.
[  [email protected]] vout: vout2: aml_vout2_shutdown
[  [email protected]] vout: aml_vout_shutdown
[  [email protected]] fb: osd_shutdown
[  [email protected]] amvdac_drv_shutdown: shutdown module
[  [email protected]] 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:

goapy

Senior Member
Dec 30, 2021
133
34
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:

Pro-me3us

Member
May 12, 2022
10
15
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 [email protected], 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: 9
  • Like
Reactions: goapy

Top Liked Posts

  • There are no posts matching your filters.
  • 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
    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
    1
    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.
    1
    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.
    1
    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 [email protected], 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.
  • 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).