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

[Pro-me3us]

I appreciate all the efforts you've put into this thanks a bunch
I was wondering if buying new cube 2nd gen from eBay like that one would work just fine

From what I've seen there are 3 batches of 2nd gen Cube, that ship with the following firmware:

PS7204/1044N (October 2019, initial release of the 2nd gen Cube)
PS7206/1098N (November 2019)
PS7229/1856N (January 2021, shipped with updated remote with channel buttons, sometimes called 2021 Cube)

Up until a month ago Amazon was still selling the 3rd batch with PS7229/1856N. I think this is the final stock. I doubt that Amazon made any new 2nd Gen Cubes in 2022, since they were already working on the 3rd gen Cube release. As long as the 2nd gen Cube is new it will ship with firmware older than PS7273 (March 2022), and this exploit will work.

The photos on the eBay box include the old remote without the channel buttons, so it probably ships with PS7206/1098N.

 

[rocker0]

From what I've seen there are 3 batches of 2nd gen Cube, that ship with the following firmware:

PS7204/1044N (October 2019, initial release of the 2nd gen Cube)
PS7206/1098N (November 2019)
PS7229/1856N (January 2021, shipped with updated remote with channel buttons, sometimes called 2021 Cube)

Up until a month ago Amazon was still selling the 3rd batch with PS7229/1856N. I think this is the final stock. I doubt that Amazon made any new 2nd Gen Cubes in 2022, since they were already working on the 3rd gen Cube release. As long as the 2nd gen Cube is new it will ship with firmware older than PS7273, and this exploit will work.

The photos on the eBay box include the old remote without the channel buttons, so it probably ships with PS7206/1098N.

Okay, that's a little promising, thanks for explaining that, I'm hoping to get my hands on it soon enough, ordered one already =).
I saw someone over here mentioning there are refurbished ones in eBay, but I didn't come across them so I went for that one instead.

 

[Pro-me3us]

Okay, that's a little promising, thanks for explaining that, I'm hoping to get my hands on it soon enough, ordered one already =).
I saw someone over here mentioning there are refurbished ones in eBay, but I didn't come across them so I went for that one instead.

Yeah, refurbished units are a little more of a gamble now because it's been 8months since the Cube was patched.

I see Amazon still selling the 2nd gen Cube new in a bunch of European countries, so new units may appear on Amazon in North America again. I wouldn't be surprised if the 2nd gen Cube was temporarily made unavailable to promote 3rd gen Cube sales.

 

[Pro-me3us]

For anyone that is thinking about trying this 2nd gen Cube exploit, and is uncomfortable making their own DFU device (force boot to USB) needed for this process, you might be able to buy a premade one here:

Meson HDMI Recovery Boot Plug by Neil's Hacks on Tindie

Meson HDMI Recovery Boot Plug - requesting a recovery boot target of an Amlogic SoC

www.tindie.com

Neil occasionally makes these on request for the Amlogic community, and doesn't make any money off them, so be nice! I've been hesitant to link to him because these are intended for development & recovery purposes, not rooting. I'll list it now since the 2nd gen Cube is on it's sunset days.

NOTE: This device will do nothing on FireOS +PS7273 firmware

 

[BigEmpty]

I got root working on my cube! Is it possible some way to use root to get NTFS and ExFAT support natively working on the cube's USB port?

 

[Pro-me3us]

I got root working on my cube! Is it possible some way to use root to get NTFS and ExFAT support natively working on the cube's USB port?

Adding native exFAT/NTFS/EXT4/F2FS support for USB OTG is possible, but that would probably take some work.

My cursory understanding is that filesystem support is enabled in the kernel. A kernel module (driver) can be created to use with Magisk to add that support without having to make a custom kernel, but I think the module has to be compiled for the specific kernel being used by the device.

This is writeup of the module creation for another device:

exFAT/NTFS support for the Cosmo Communicator | MyGNU.de

Unfortunately the Cosmo Communicator, like many other Android phones, does not support the exFAT filesystem. Most vendors do so due to exFAT being covered by software patents in the USA, which is a problem for companies selling to the USA. exFAT might not be the most sophisticated filesystem...

www.mygnu.de

Most of the exFAT/NTFS/EXT4/F2FS support appears to be based on Vold:

GitHub - Magisk-Modules-Repo/vold-posix: vold-posix

vold-posix. Contribute to Magisk-Modules-Repo/vold-posix development by creating an account on GitHub.

github.com

And the 2nd gen Cube kernel source can be found here:

raven_firmware/README.md at main · Pro-me3us/raven_firmware

Amazon FireTV 2nd gen Cube Firmware & Stock Apps. Official Cloud Front direct links only - Pro-me3us/raven_firmware

github.com

This might be easy for someone that has experience working with Magisk and kernels, but a bit of a project for others. Native NTFS support has been added to other FireTV devices through custom kernels and even at least one Magisk module, but the rooted 2nd gen Cube community is very small.

 

[Pro-me3us]

I got root working on my cube! Is it possible some way to use root to get NTFS and ExFAT support natively working on the cube's USB port?

A followup, it looks like the the Cube already has support for ext3, ext2, ext4, cramfs, squashfs, vfat, msdos, exfat, iso9660, ntfs, fuseblk, udf (listed in /proc/filesystems). So it's possible to manually mount a USB drive. Check /dev/block/ for the USB name, which will be a variation of sdxx. For example I plugged in an NTFS drive that appeared as sda2. This can be mounted wherever you like. I'll mount it to /mnt/usb/ in this example.

Create /mnt/usb/ directory from ADB:

mkdir /mnt/usb/

Mount sda2 to /mnt/usb/

mount -t ntfs -o rw /dev/block/sda2 /mnt/usb/

If you want to unmount

umount /dev/block/sda2

You can then use a file manager or ADB to view the contents of the drive. A few caveats:
1) the NTFS module is read-only, so no writing to the drive. (exFAT may mount as read-write, need to check)
2) the drive won't appear as external storage, so you won't be able to navigate to the drive from within most media players.

Full native support with auto-mount/unmount takes a bit more work. That is handled by the volume daemon (VOLD). @Pretoriano80 made a Magisk module for the 4K Stick to handle this with a modified VOLD. I asked him what would be involved to make something similar, and he suggested checking LineageOS for a version of VOLD that will work with FireOS7 and the Cube. Then it's a matter of going through the kernel log to address any errors or permission issues that arise as the Cube boots. Pretoriano80's module and XDA thread give a good outline. He agrees it's bit of work but doable for someone that wants to put in the time.

 

[BigEmpty]

Yes thank you very much! That's the reason I first asked because once I had root I saw that NTFS devices were populated in dev/block as sda? and if I mounted I could browse them in the adb shell easy. So I thought somehow with root I could get media players to see them easy too. I will read your references about methods to automate the mount/unmount and see what I can learn. Thanks for looking into this so much!

 

[Pro-me3us]

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:

# 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].

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:

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.

 

[Pro-me3us]

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

 

[hasobist]

Hello Pro-me3us!
Thank you for the update and keep the good work going,hoping for a permanent root soon.
Cheers.......

 

[BigEmpty]

Suppose the native BL33 bootloader code had unrestricted access to the u-boot shell. Might a memory patch to the running BL33 code be able to nop or toggle the engineering device status check?

 

[Pro-me3us]

Suppose the native BL33 bootloader code had unrestricted access to the u-boot shell. Might a memory patch to the running BL33 code be able to nop or toggle the engineering device status check?

Yes, if you can figure out a way to do a memory patch or get unrestricted access to u-boot, that opens up a number of possibilities.

Using Peacock on a rooted device
Unrelated, I was asked whether Peacock would work on the Cube with root. Peacock appears to have a number of security checks that will cause it to force close on a rooted device. @bobpiesz made a Peacock mod that will work, but it requires disabling signature verification, and hiding Magisk.

What's needed:
Magisk / Magisk manager 24.0 or later
LPosed for Zygisk latest
CorePatch 2.2 (EN)
Modded Peacock app

1) Enable Zygisk in Magisk Manager settings

2) Go to Magisk Manager modules tab, install LPosed for Zygisk, and enable it. If you don't see an LPosed icon on your Homescreen/Apps drawer after installation, use a filemanager (Total Commander, MiXplorer, etc) to navigate to /data/adb/lspd, and manually install manager.apk. Requires a reboot to become active.

3) Install CorePatch 2.2 (EN) apk, this is the last version compatible with Android 7x-10x. Open CorePatch, grant SuperUser access when prompted, and make sure the second toggle is enabled Disable Package Manager Signature Verification. Open LPosed and enable CorePatch module. Reboot for CorePatch to become active.

4) Install modded Peacock app, but don't open it yet.

5) Open Magisk Manager, go to settings, enable Enforce DenyList, go to Configure Denylist and add the Peacock app. Lastly in Magisk Manager settings, hide the Magisk app (give Magisk installation permission, then retry), give Magisk any new name.

Now Peacock will no longer force close. If it does force close, go into FireOS settings, apps list, and clear Peacock data & cache, and try to reopen.

A couple other Magisk / LPosed (Xposed) mods that people might find useful
Install Google Services / AndroidTV Play Store (verified on Cube)

Full remote button remapping including recents & favorites, with Xposed Edge (verified on Cube)

 

[BigEmpty]

Was Zygisk support added? I must have missed that. I read earlier that su is enabled but not Zygisk.

Was the peacock problem determined to exist equally in the firetv version of the peacock app as compared to the android tv version of the peacock app?

There are differences between the two versions. For example, the android tv version won't run unless google play services is running. Although the firetv version will run on an android tv device just fine with google play services disabled.

 

[Pro-me3us]

Was Zygisk support added?

Yeah it's been working since July.

I don't know much about the Peacock app other than it crashes on rooted devices, FireTV and AndroidTV. Not sure if Google Services is needed, the AndroidTV mod works on FireTV without it. I don't actually use the app.

 

[rocker0]

I haven't got my hand on the DFU HDMI yet but I am little newbie and I would appreciate if you can help me with some confusions I'm having.

1. Reconnect the Cube and TV with HDMI cable.

1-I have my laptop placed on some desk and my firetv cube somewhere else near the TV, I will move the firetv cube next to my laptop and do the steps mentioned, but can i unplug the power cable and plug it in again before doing that step "Reconnect the Cube and TV with HDMI cable."
or am I not allowed to do that "i can't power it off at all"?
as I don't think my HDMI cable is that long to reach my TV so if i am allowed to, I would need to unplug the power from the cube and plug it again near my TV then connect the HDMI to my TV

1. Type 'bash menu' in the terminal, and choose your boot mode.

I want to install magisk and LSposed, do you mind explaining to me the steps i need to do that?
Also I'm confused on which boot mode i have to choose.
is it fine to restart the firetv cube if ever promoted?
my firetv cube FW is Fire OS 7.2.0.1(PS7201/942)

Thanks a lot

 

[Pro-me3us]

can i unplug the power cable and plug it in again before doing that step "Reconnect the Cube and TV with HDMI cable."

The exploit is all run in RAM, so if you pull the Cube's power, the exploit is gone along with root access.

You will want to move your laptop to the TV and Cube. Loading the exploit literally takes 10-15sec, then you can move your laptop back to your desk. After the Cube boots you will have root through Magisk until you restart the Cube. The Cube can potentially go 1-2 months without a reboot.

I want to install magisk and LSposed, do you mind explaining to me the steps i need to do that?
Also I'm confused on which boot mode i have to choose.
is it fine to restart the firetv cube if ever promoted?

Bash menu option 2) + suboption 2) is all you will want for regular use
2) FireOS boot with Magisk support
2) USB host mode - connect peripherals to Cube

Once you boot into FireOS you can install apps normally. Download and sideload Magisk Manager and LPosed for Zygisk (steps are the same as the Peacock steps). Whenever a new Magisk or LPosed module is installed a reboot is required for the module to become active. And because the exploit is wiped from memory, you have to reload it from your laptop. Installing modules is one of the few times that you actually do have to reboot the Cube.

You can freely boot with and without the exploit, going back and forth from Magisk being active or inactive when the exploit is absent. It's not going to corrupt anything.

 

[Functioner]

DRAM
-> start = 0x
-> size = 0x80000000
TLB addr = 0x
relocaddr = 0x
reloc off = 0x76D61000

Would save some time if someone could fill in the blanks. Approximate size of U-Boot at the top of memory. Raw hex disassembly of U-Boot as expressed in memory for the newest bootloader that can be used. Finally -/+ hex memory patches for amzn_target_is_unlocked, amzn_dm_verity_is_off, amzn_target_device_type with an emphasis on minimum to boot modified boot image on emmc.

 

[Functioner]

I spent the time and sorted it out myself. Something that I noticed that is kind of interesting is that if a magisk boot image is flashed to the emmc on a raven device running the native PS7279/1856N bootloader, it will fail (aml log : Sig Check -1) to a fastboot connection if a usb cable is connected. However, boot can still continue if "fastboot continue" is executed. Though for some reason magiskinit doesn't execute, even though the boot proceeds pretty far it eventually fails due to dm-verity. Not sure why magiskinit doesn't execute. It might be because it's booting the recovery partition and not the boot partition, or possibly it is because of the recovery style patch. I was able to get a 1 value for eng_device on the native PS7279/1856N bootloader, but still get the "aml log : Sig Check -1" bootm failure.

 

[Functioner]

I managed to get my raven in a state that even DFU can't fix. The ./amlogic-usbdl image boots ok via DFU, but any of the ./update bl2_boot images eventually result in this

"Synchronous Abort" handler, esr 0x96000010                           
ELR:     77e2836c                                                               
LR:      77e28300                                                               
x0 : 0000000000000009 x1 : 0000000000000000                                     
x2 : 0000000077daa164 x3 : 0000000000000001                                     
x4 : 0000000000000030 x5 : 0000000000000000                                     
x6 : 00000000ffffffd0 x7 : 0000000000000004                                     
x8 : 0000000000000038 x9 : 0000000000000008                                     
x10: 000000000000000f x11: 0000000077e3abe0                                     
x12: 0000000000000000 x13: 000000000108660d                                     
x14: 0000000001675200 x15: 0000000001c86516                                     
x16: 0000000073d71f30 x17: 0000000073d72ab8                                     
x18: 0000000073d55e28 x19: 0000000000000001                                     
x20: 0000000000000010 x21: 0000000000000000                                     
x22: 0000000000020000 x23: 0000000087d65000                                     
x24: 0000000000000010 x25: 0000000087d65000                                     
x26: 0000000000000002 x27: 0000000000000003                                     
x28: 0000000077e62f63 x29: 0000000073d54850                                     
                                                                                
Resetting CPU ...

I think the only way to fix it is to build a bootloader image that doesn't proceed through the normal boot process, and starts burn mode, or uart console mode, earlier than this

enable_dolby_vision                                                             
Dolby Vision  turn on                                                           
[OSD]load fb addr from dts:/meson-fb                                            
[OSD]set initrd_high: 0x7f800000                                                
[OSD]fb_addr for logo: 0x7f800000                                               
[OSD]load fb addr from dts:/meson-fb                                            
[OSD]fb_addr for logo: 0x7f800000                                               
[OSD]VPP_OFIFO_SIZE:0xfff01fff

It is shortly after that the "Synchronous Abort" handler reset happens, using any of the provided images. It might be a recovery bootloop, I was modifying various contents of the emmc.

Should it be possible to build such a bootloader image?