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

[Pro-me3us]

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

I'm not totally sure what changes you were making, but I don't recommend editing the reserved partition if that's what it was.

I have an old bootloader that I made that exits into fastboot mode a little bit earlier than the bootloaders included in the OP. Let me know if that gets you past the crash, in which case I can compile one to dump you into update mode instead.

If you want to flash the magisk patched boot image to the Cube, you need to create a new patched image with Magisk Manager, and leave both recovery and vbmeta unchecked. Also, if you don't have a bootloader exploit to bypass verified boot, the bootloader will always reject modified boot images, which is the signature check fail you are seeing.

 

[Functioner]

I have an old bootloader that I made that exits into fastboot mode a little bit earlier than the bootloaders included in the OP. Let me know if that gets you past the crash, in which case I can compile one to dump you into update mode instead.

Yes! That did it...

vpu: set clk: 666667000Hz, readback: 666666667Hz(0x100)                         
vpu: vpu_module_init_config                                                     
vpp: vpp_init                                                                   
vpp: g12a/b osd1 matrix rgb2yuv ..............                                  
vpp: g12a/b osd2 matrix rgb2yuv..............                                   
vpp: g12a/b osd3 matrix rgb2yuv..............                                   
USB3.0 XHCI init start                                                          
detect ID pin : Device mode  , r5.b.iddig_curr=1nboard_usb_stop cfg: 2          
hpd_state=0                                                                     
Info: logoparam_getvalue: get succeed: key: logoparam.var.hdmi_mode, value: null
do_hpd_detect: hdmimode=null                                                    
Info: logoparam_getvalue: get succeed: key: logoparam.var.hdmi_colorattr, valuet
do_hpd_detect: colorattribute=rgb,8bit                                          
Info: logoparam_getvalue: get succeed: key: logoparam.var.hdmi_crcvalue, value:0
Info: logoparam_getvalue: get succeed: key: logoparam.var.hdmi_mode, value: null
no sink, fallback to 720p60hz[4]                                                
g_dnl_register: g_dnl_driver.name = usb_dnl_fastboot                            
                                                                                
USB RESET                                                                       
SPEED ENUM                                                                      
                                                                                
USB RESET                                                                       
SPEED ENUM 
.

Thanks much! I was actually trying to generate certain failures during my efforts to obtain persistent root. I see a path that I'm working on.

All of the memory locations used by your bootloader, like, for example, the devicetype location patch;

77d7c850: 00 00 2b 91
14 00 00 1b

Are different on the native bootloader, which is what I'll have to patch in order to do persistent. So, I was trying to sort out all of the native bootloader patch locations. And learn other stuff too.

I can get back to work now without having to spend time compiling a bootloader. Thanks again!

 

[Functioner]

If you want to flash the magisk patched boot image to the Cube, you need to create a new patched image with Magisk Manager, and leave both recovery and vbmeta unchecked.

The boot image has no ramdisk. If a recovery style patch isn't used, will magisk still add a ramdisk to a boot image lacking any native ramidsk?

 

[Pro-me3us]

Yes! That did it.

Glad it worked, here's a new bootloader that exits early and drops you in update. And a zipped copy of the reserved partition if you need it. To disprotect the reserved partition ./update bulkcmd 'amlmmc key'

The boot image has no ramdisk. If a recovery style patch isn't used, will magisk still add a ramdisk to a boot image lacking any native ramidsk?

Typically if a device boot image doesn't include a ramdisk, the device won't use it if it's added. There are exceptions to this like certain Xiaomi devices and the 2nd gen Cube (probably other Amlogic boxes too).

 

[Functioner]

The FireFU exploit has the advantage of being able to intercept u-boot prior to execution, patch the changes, and then jump to the patched u-boot.

The entry vector that I'm using can only make hot patches after u-boot has already initialized everything. The same FireFU exploits won't work in this case. I'll need to use different patches.

Next thing I'm trying is disassembly of the native bootloader's u-boot.bin. I don't think I can easily get the equivalent from amazon's source code. I worry though that a hot patch to another memory address won't be at a fixed address, like the u-boot.bin code.

 

[Functioner]

Would it be much trouble for you to build a bootloader that uses u-boot from PS7229/1856N, and has no exploit patches other than enabling unrestricted u-boot shell access? Somewhere in the github Raven_Bootloader_Builder section, you noted that the newer versions wouldn't build, or that bootm didn't work, but the latter wouldn't matter.

Edit: may not need another bootloader. Having some success with hot patches to sig check function (rsa_verify_hash.c)

Is the ARB value entirely repurposed for determining the production/engineering device status, or does it also enforce anti-rollback of the flashed bootloader?

 

[Pro-me3us]

build a bootloader that uses u-boot from PS7279/1856N, and has no exploit patches other than enabling unrestricted u-boot shell access

This bootloader is compiled from the PS7229 open source. Only amzn_lockdown.c was edited to remove the u-boot command blacklist. I don't have uart hooked-up to test it, but it should work.

After the release of the source for PS7204, Amazon added more of their UFBL code to the subsequent bootloader source releases. I could not get Fastboot boot to work on the later versions. I don't know if there was a check that I failed to find and patch, or if the source is just incomplete. After PS7229, the later bootloader source fails to even compile.

is the ARB value entirely repurposed for determining the production/engineering device status, or does it also enforce anti-rollback of the flashed bootloader?

I assume it's also used to enforce downgrades of the bootloader. I think it's still up to the vendor (Amazon) to choose to set it in the bootloader. There is no downgrade restriction from PS7242/3516 going down to PS7204. Amazon may have triggered it in one of the 3 bootloader updates since PS7242/3516.

 

[Functioner]

What is the vector that you're using?

I'll share it with you privately if I'm unable to get anywhere by the weekend. I don't want to share it publicly until I'm sure it bears fruit.

 

[Pro-me3us]

If you can disable the boot image signature verification, that's probably the most important thing. Setting the device to ARB=0 or engineering mode, may be required too. Engineering mode will enable the fos flags that include disable dm-verity and ADB root. But disabling dm-verity and root with fos flags isn't needed, the magisk-patched boot image can take care of that.

 

[Functioner]

If you can disable the boot image signature verification, that's probably the most important thing.

I agree. There's the amlogic verification "aml log : Sig Check -1" (which, oddly, amlogic abandoned after android 9), and the amazon certificate verification. Engineering device mode probably won't overcome the amlogic signature verification, but will give full IDME.

 

[Functioner]

After the release of the source for PS7204, Amazon added more of their UFBL code to the subsequent bootloader source releases. I could not get Fastboot boot to work on the later versions. I don't know if there was a check that I failed to find and patch, or if the source is just incomplete.

This is what I believe will be the key to the possibility of persistent root. If, with free rein of arbitrary bootloader modifications, you were unable to get bootm (fastboot boot) to boot a modified boot image on these later versions, then we are stuck. We have to hope the source was bad or that you missed a patch.

Did you only try fastboot boot, or also bootm directly? A boot image can also be loaded to the loadaddr using update:

update mwrite boot.img mem 0x1080000 normal
update bulkcmd 'bootm 0x1080000'

 

[Functioner]

GOT IT! Can boot a modified image!

I'll get a PoC package together within the next 24 hours and DM the details on discord.

Edit: Confirmed that fastboot boot also works with this single byte patch, so long as fastboot is invoked from the same boot session as when the patch was made. Actually flashing the modfied boot image to the boot partition on the emmc will probably require another patch, since engineering mode is not enabled.

 

[Pro-me3us]

I was looking back at the source for 7229 today. Booting images through fastboot and update both halt at the same point. I can see what the problem is. in 7229 the uboot command rsvmem is missing, and this is called during the mboot, and then halts when it can't use that command. the cmd_rsvmem file is included with 7229, but typing help in uboot, I can see it's missing.

The source that Amazon posts is just so full of mistakes it's ridiculous. I might be able to find out what is the cause for the exclusion of that command, but it sounds like you may not need it.

Is the single edit you are making just an unlock? and that's enough to remove the signature check?

Very good work! I'm glad to finally see a solution for this on the horizon

 

[Functioner]

With the patch in effect, I see this before it boots the modified image:

[rsvmem] no check for rsvmem, should check int kernel

But then it continues to boot fine. Yes, all that is done is a single byte patch to the unlock code. It's just a matter of hunting the other patches down though, although even this is completely fine for most uses.

Do you have a raven device with the 7229/1856N native bootloader? The patch address is bootloader dependent. Even the 7229/1853 that you complied earlier is at a different address. What is the newest bootloader that can be used w/o losing DFU?

Edit: uboot help shows rsvmem in the command list on the native 7229/1856N bootloader. Executing rsvmem gives the same result as shown during boot:

rsvmem
no check for rsvmem, should check int kernel

So i guess it is just missing in the source code.

 

[Pro-me3us]

[rsvmem] no check for rsvmem, should check int kernel

This is the correct message, and indicates that cmd_rsvmem is present.

Do you have a raven device with the 7229/1856N native bootloader? The patch address is bootloader dependent. Even the 7229/1853 that you complied earlier is at a different address. What is the newest bootloader that can be used w/o losing DFU?

Bootloaders aren't changed often. I've only seen 6 versions since the Cube was released.
PS7204->PS7212/1333 same
PS7229/1853+1856 are the same
PS7242/2906-PS7242/3516 same

These are the 3 bootloaders before the eFuse is triggered, then there are 3 after. I've tested PS7242/3516 with the latest firmware, it's the last safe one to use as far as I can tell.

One thing to keep in mind. When the bootloader is flashed to the Cube it's offset by 512 bytes. Depending how you extract the bootloader, that 512byte lead may or may not be present.

7229/1853+1856 are the same from what I remember. I have a copy of each if needed

 

[Functioner]

Okay, good. I'll ask for them if I don't already have them.

 

[Pro-me3us]

I found the issue with rsvmem and fixed it. PS7229 now boots to FireOS, but I don't know if it makes any difference once you get into FireOS what bootloader version was used. This PS7229 was an old testing version, and I made a number of patches, probably a bunch of redundant ones. If you need I can try to make single patches to give you an idea where certain settings/attributes are.

 

[p0werpl]

GOT IT! Can boot a modified image!

I'll get a PoC package together within the next 24 hours and DM the details on discord.

Edit: Confirmed that fastboot boot also works with this single byte patch, so long as fastboot is invoked from the same boot session as when the patch was made. Actually flashing the modfied boot image to the boot partition on the emmc will probably require another patch, since engineering mode is not enabled.

From what I understand, root is not persistent? Does the FTV have to be tethered to the DFU entry device at fresh boot?

 

[Pro-me3us]

Updated the OP with a new version of the Raven boot package. A BIG THANK YOU to @Functioner for getting the root to persist through reboots!

There is now a new bash menu option to root your 2nd gen Cube, with all features working. Make sure that after running the root menu option that Magisk and TWRP are present & functional, because they are both needed to provide an extra layer of protection from accidental Amazon OTA updates. It goes without saying, only update your firmware through TWRP!

DFU access is still needed to apply the new patch, so this will only work on Cubes with firmware older than PS7273 (or that still have USB DFU access). Anyone with a Cube past PS7273, I'd recommend blocking updates now on PS7624, FireOS is only going to get more locked down in future updates.

Any new sealed 2nd gen Cube is guaranteed to come with firmware PS7229 or older and can be fully rooted. Unfortunately new 2nd gen Cubes are getting harder to find fast.

 

[JJ2017]

Many thanks @Pro-me3us for this - good to see some progress on this device.

.... However, I've run into some problems using RAVEN2. I had previously installed the RAVEN exploit and everything was fine. I ran option 1 (in RAVEN2) for persistent root and (as SU) the script seemed to run without issue. But now the device wont boot beyond the initial boot screen. Since then every change I've made (e.g. flashing newer firmware (was on 7229/1856), wiping data in TWRP and flashing boot.img in fastboot) has only made the situation worse!

Is there any way to return to stock & restart the process? I've not updated the bootloader - the exploit still works & I can still access TWRP. But now firmware updates in TWRP are no longer working - the device won't progress beyond boot screen & I'm now stuck in bootloop Any ideas?