[UNLOCK][ROOT][TWRP][UNBRICK] Fire TV Stick 4K (mantis)

[Sus_i]

I have the same problem ( stuck at "waiting for bootrom"), i just got it two days ago, tried everything what i found in the forum but nothing helped. :S

Have you checked the output in lsusb too?
Make sure the short is steady and proper, then connect the sticks usb (to the PC running fireISO) and watch out in lsusb.

 

[I_CRAFT]

so i've attached two TTL-to-USB adapters (some generic and one with the CH340G chip) to the three pins (RX/TX/Ground) and got no output at all.

i have tested it with a baudrate of 300 to 115200 and this command from linux

# screen /dev/ttyUSB0 <baudrate>

 

[Sus_i]

so i've attached two TTL-to-USB adapters (some generic and one with the CH340G chip) to the three pins (RX/TX/Ground) and got no output at all.

i have tested it with a baudrate of 300 to 115200 and this command from linux

# screen /dev/ttyUSB0 <baudrate>

The bootrom baudrate is 115200.
If you boot without a short, the output should only be a line and some numbers, something like this:

[DL] 00008B50 00000000 010801

F0: 103B 0000

F3: 0000 0000

V0: 0000 0000 [0001]

00: 0008 4000

01: 0000 0000

BP: 0000 0301 [0000]

G0: 0162 0000

T0: 0000 02A1 [000F]

Jump to BL

After that the bootprocess jumps to the bootloader. At this point the baudrate is 921600.

You can take some logs, at BR baudrate 115200, ofc first without a short and then with a short. Just to see what happens. If I remember correct, the patched tank sticks doesn't jump to the BL, they print something like 'system halt' (in case the eMMC is proper shorted out).

Can't help you with the command, used always putty on a win7 machine...

 

[itsyaboy]

After rooting how do we update? It’s been a while since I set everything up and I may have disabled ota etc, I’m trying to get google stadia to run but it’s not getting passed the “get started” screen so I’m assuming I need to update.. so 1) is it safe to update and will the root stay intact? 2) how do I enable ota updates? 3) is there a safer manual way of updating?

 

[k4y0z]

I suppose it was just a matter of time until they also disabled DL-Mode on mantis.
I haven't looked into it in detail, but I don't think it actually requires a newer BROM/SOC.
They probably simply disabled the DL-Mode using an efuse.

so i've attached two TTL-to-USB adapters (some generic and one with the CH340G chip) to the three pins (RX/TX/Ground) and got no output at all.

i have tested it with a baudrate of 300 to 115200 and this command from linux

# screen /dev/ttyUSB0 <baudrate>

Yes, that should work, make sure to cross-connect TX and RX (RX goes to TX and vice versa).

 

[Pretoriano80]

@k4y0z on FireOS 6.2.7.7 Amazon added an efuse check, any idea about it?

Edit: Probably it confirms the efuse theory from your previous post!?

This is how the script looks:

# Copyright 2020 Amazon.com, Inc. or its affiliates. All Rights Reserved.

# Default status
STATUS=invalid

# Read the e-Fuse once
ewriter 0 0 1 > /dev/null 2>&1

if [ $? -eq 0 ]; then
    log -t efuse Reading e-Fuse succeeded
    STATUS=$(ewriter 0 0 1 | sed '2!d')
else
    log -t efuse Reading e-Fuse failed
fi

# Log the value in logcat buffer
log -t efuse Initial e-Fuse value: $STATUS
# ...and property
setprop efuse.status $STATUS

 

[Sus_i]

I thought (until now) that the efuse theory is somewhat unlikely, since @xyz` said that the BR exploit is unpatchable... but now we see some eFuse/ewriter code.

Worst case. Maybe efuses are implemented in all MT8695 chips out there... (most likely, isn't it?),
and in case they are as easy to trigger like for qualcomm or nvidia chips... (also high likely!?)
it should be an easy task for Amaz. to f*ck up all the older vulnerable 4k sticks out there too.

 

[tsynik]

That's output of ewriter 0 0 1 on 4K updated to 6.2.7.7 via TWRP:
mantis:/ # ewriter 0 0 1
failed to creat efuse session ffff0008
failed to read efuse
tee result = 0xffff0008
status code = -65528, which means "tee error"

 

[Pretoriano80]

I thought (unil now) that the efuse theory is somewhat unlikely, since @xyz` said that the BR exploit is unpatchable... but now we see some eFuse/ewriter code.

Worst case. Maybe efuses are implemented in all MT8695 chips out there... (most likely, isn't it?),
and in case they are as easy to trigger like for qualcomm or nvidia chips... (also high likely!?)
it should be an easy task for Amaz. to f*ck up all the older vulnerable 4k sticks out there too.

Maybe the efuse was implemented on the newer 4K sticks?!
It's odd that the default STATUS value it's "invalid".

That's output of ewriter 0 0 1 on 4K updated to 6.2.7.7 via TWRP:
mantis:/ # ewriter 0 0 1
failed to creat efuse session ffff0008
failed to read efuse
tee result = 0xffff0008
status code = -65528, which means "tee error"

It may require a new bootloader/preloader (or whatever MTK calls its stuff), which (thankfully) it's not updated when installing FireOS with TWRP.
Someone with more experience on this low level stuff may know better.

 

[tsynik]

It's odd that the default STATUS value it's "invalid".

Looks like it not used yet, because from getprop efuse.status i have empty line on my 4K with 6.2.7.7

 

[Pretoriano80]

Looks like it not used yet, because from getprop efuse.status i have empty line on my 4K with 6.2.7.7

Same here! However, the check it's enabled in ramdisk and if you "getprop | grep efuse", you will probably see that the service is stopped.

 

[k4y0z]

@k4y0z on FireOS 6.2.7.7 Amazon added an efuse check, any idea about it?

As said, I haven't really looked at it.

I thought (until now) that the efuse theory is somewhat unlikely, since @xyz` said that the BR exploit is unpatchable... but now we see some eFuse/ewriter code.

Worst case. Maybe efuses are implemented in all MT8695 chips out there... (most likely, isn't it?),
and in case they are as easy to trigger like for qualcomm or nvidia chips... (also high likely!?)
it should be an easy task for Amaz. to f*ck up all the older vulnerable 4k sticks out there too.

To me the efuse-theory seemed most likely.
The BROM probably always had the option to disable the DL-Mode via efuse.
And that doesn't really patch the vulnerability, it's more of a mitigation, in that sense xyz` was right.
Typically that wouldn't be disabled though, since that also means no SP Flash tools or similar for amazon themselves either (i.e no way to recover bricked devices even for the manufacturer)
If the efuse-theroy is correct, then indeed they could burn it via an update, so far it seems they haven't gone that route and have only disabled it on recently manufactured devices.

That's output of ewriter 0 0 1 on 4K updated to 6.2.7.7 via TWRP:
mantis:/ # ewriter 0 0 1
failed to creat efuse session ffff0008
failed to read efuse
tee result = 0xffff0008
status code = -65528, which means "tee error"

It may need an up to date TZ to work, the code may just not be implemented in the older one.

 

[tsynik]

It may need an up to date TZ to work, the code may just not be implemented in the older one.

Yes, but not only tz need to be updated. I flashed kamakiri with only new tz.img from 6.2.7.7 and had same error. after i replaced all: lk.bin, preloader.img and tz.img from 6.2.7.7 in kamakiri.zip and updated with it from twrp, now I have this output about eFuse:

mantis:/ # ewriter 0 0 1
efuse hex:
00
status code = 0, which means "eFuse is ok."

and new param in props:

mantis:/ # getprop|grep fuse
[efuse.status]: [00]
[init.svc.efuse_check]: [stopped]

does that mean I can't short eMMC in the future on this 4K? =) is it better to revert to kamakiri-1.2 bins? we can always spoof efuse.status with Magisk ;-)

 

[Pretoriano80]

Yes, but not only tz need to be updated. I flashed kamakiri with only new tz.img from 6.2.7.7 and had same error. after i replaced all: lk.bin, preloader.img and tz.img from 6.2.7.7 in kamakiri.zip and updated with it from twrp, now I have this output about eFuse:

mantis:/ # ewriter 0 0 1
efuse hex:
00
status code = 0, which means "eFuse is ok."

and new param in props:

mantis:/ # getprop|grep fuse
[efuse.status]: [00]
[init.svc.efuse_check]: [stopped]

does that mean I can't short eMMC in the future on this 4K? =) is it better to revert to kamakiri-1.2 bins? we can always spoof efuse.status with Magisk ;-)

Have you checked if fastboot flashing still works?

 

[Sus_i]

Yes, but not only tz need to be updated. I flashed kamakiri with only new tz.img from 6.2.7.7 and had same error. after i replaced all: lk.bin, preloader.img and tz.img from 6.2.7.7 in kamakiri.zip and updated with it from twrp, now I have this output about eFuse:

mantis:/ # ewriter 0 0 1
efuse hex:
00
status code = 0, which means "eFuse is ok."

and new param in props:

mantis:/ # getprop|grep fuse
[efuse.status]: [00]
[init.svc.efuse_check]: [stopped]

does that mean I can't short eMMC in the future on this 4K? =) is it better to revert to kamakiri-1.2 bins? we can always spoof efuse.status with Magisk ;-)

Nice to see that your stick is working with the new tz image.

Probably the error is gone, because the LK updated something during boot, at least rpmb should be updated now.
I guess eFuse ok mean that the efuse isn't burned for now. Have you checked the message in lsusb when shorted?

 

[k4y0z]

Yes, but not only tz need to be updated. I flashed kamakiri with only new tz.img from 6.2.7.7 and had same error. after i replaced all: lk.bin, preloader.img and tz.img from 6.2.7.7 in kamakiri.zip and updated with it from twrp

When updating TZ, typically preloader also needs to match.
If you update LK you'll lose the unlock (which might also happen, when updating preloader).
If you use the ZIP-file to update via TWRP, only tz will be updated unless you uncomment the following in the update-binary:

#ui_print "- updating preloader"
#dd if=/${INSTALLER}/kamakiri/bin/preloader.img of=/dev/block/mmcblk0boot0 bs=512

does that mean I can't short eMMC in the future on this 4K? =) is it better to revert to kamakiri-1.2 bins? we can always spoof efuse.status with Magisk ;-)

You will have to test if this burned the efuse or just displays its current status.
What use would it be to spoof the status?

 

[k4y0z]

Doublepost, sorry.

 

[tsynik]

You will have to test if this burned the efuse or just displays its current status.
What use would it be to spoof the status?

Today I checked that 4K and unlocked 2 new ones. Good thing is old one on 6.2.7.7 and with current TZ only show efuse status, but still have ability to be unlocked with a short. It detected and flashed with kamakiri fine. Another findings are new 4K sticks with current preloader always throw error after kamakiri's waiting for bootrom... about serial protocol mismatch. Just powered it from USB without a short and bootrom-step.sh script failed soon without any other actions done. With old one kamakiri don't throw that error on boot (old preloader differs in behaviour?) - waiting for bootrom forever until short. New ones still can be unlocked with a proper short fine.
p.s. probably it's better to stay on previous fw (6.2.7.6?) Amazon will not have ability to burn OTP in the future with it (their New Year gift maybe? =)

 

[Sus_i]

Good thing is old one on 6.2.7.7 and with current TZ only show efuse status, but still have ability to be unlocked with a short.

Are you able to check if your stick plays prime 4k content with the updated TZ?

p.s. probably it's better to stay on previous fw (6.2.7.6?) Amazon will not have ability to burn OTP in the future with it (their New Year gift maybe? =)

Probably yes.

Question is if we can use the new TZ with the old preloader, or if we should try the new preloader, in order to avoid license and keybox errors in the future...

Remember what k4y0z said:

When updating TZ, typically preloader also needs to match.

If you update LK you'll lose the unlock (which might also happen, when updating preloader).

I had a quick look into all OTA packages since 6.2.6.6, just comparing the size of the images.

-The Preloader changed only in 6.2.7.1 and it's still the same in the latest. (We are using the older 6.2.6.6 PL in kamakiri).
-LK changed in 6.2.7.3 (this image is a lot bigger than all other versions) and it changed again in 6.2.7.6.
-TZ changed in 6.2.6.8 (the one already included in kamakiri) and it changed again in 6.2.7.7.

In conclusion I guess we can test the new Preloader together with the updated TZ. @tsynik do you want to try the new PL/TZ, together with a 6.2.7.6 rom for safety?

In case the PL breaks the unlock somehow (could be that the PL won't boot the vulnerable LK / LK payload), we can switch back with kamakiri/shorting method, as we know already that shorting was possible even for sticks running 6.2.7.3. Isn't it?

Maybe the newer PL/TZ combination could help to avoid the LICENSE_ERROR at 4k content, someday in the future...!?

 

[tsynik]

Are you able to check if your stick plays prime 4k content with the updated TZ?

I don't have Prime and outside US so can't test this case.

In case the PL breaks the unlock somehow (could be that the PL won't boot the vulnerable LK / LK payload), we can switch back with kamakiri/shorting method, as we know already that shorting was possible even for sticks running 6.2.7.3. Isn't it?

I've done last 4K sticks unlock prior to 1st boot and update to 6.2.7.6 in OOBE cycle, so can't be 100% sure, it's no way to check which preloader was flashed out of the box ;-) But it's definitely differs in boot behaviour than kamakiri bundled one (protocol mismatch error in kamakiri on every boot).