[UNLOCK][ROOT][TWRP][UNBRICK] Fire TV Stick 3 and Fire TV Stick Lite (sheldon/p)

[ChriMo]

Update fails because the fireOS only downloads a diff partial update at the first try, the second attempt might work better...

Don't know if using Mobile Hotspot (speed not very high) is influencing but so far the Update failed at least 5 times. I will not care because only the remote IR setup is important and I guess this will not change/improve with new fireOS Updates.

NTFS/ext4 USB Sticks on my microUSB to USB-C OTG Adapter seem to be not recognized in FireOS using ES File Explorer (ADB-Debugging is on). In Lineage OS this worked. FireOS wants to format them in FAT32. Also Mouse over USB does not work in FireOS (in TWRP it works). So need to see if using USB-Space will work to move a TWRP backup away from internal space. Directly saving from TWRP to USB would also be desirable. I will see to find a Stick I can format in FAT32.
A 4 GB FAT32 Stick was not recognized or I was not able to mount it in FireOS; TWRP was able to see it.

EDIT just for the record: BT-Keyboard Layout (Language) is also not recognized or changeable in FireOS (like Lineage OS). The lack of ML support is surprising to me.

EDIT2 I had a hard time going into fastboot mode to flash LineageOS: I did a factory reset in FireOS (after having done a TWRP backup to USB-Stick). Then in MX Linux systemd I started the first steps until "sudo ./bootrom-step.sh" which shows "Waiting for device". When I connect the USB cable the FireStick went into TWRP and said "reboot in 5 sec." and then it did boot FireOS. Only after a while I discovered the USB-OTG adapter should be the culprit, as when connected directly the kamakiri script returned to work.

EDIT3 so have now LineageOS on the sheldonp, but since I had difficulties to connect the remote, I removed the batteries and then BT connecting worked. However the IR settings for the TV done in FireOS seem to be lost, when batteries are removed. Huge dealbreaker, because also battery changing will cause this. Need to look how others with sheldonp succeded using the IR remote under LineageOS.

 

[menef8]

Hello, I need some help ... I have a happily rooted sheldon stick, until I changed the amz account to another.

The stick entered a bootloop, so I managed to factory reset, reflash magisk via TWRP, but then no root access, and, my bad I forgot that, I used magisk app to patch boot.

Now the stick starts with the white logo and won't boot, nor twrp, and (this is the ugly part) no fastboot.

Launching kamakiri bootrom-step.sh goes fine without errors, also gpt-fix.sh runs fine, but then no fastboot appear (also tried boot-fastboot.sh and boot-recovery.sh)
And no ADB either, the stick does not go past the white logo.

I think the only thing to do before ditching the stick is to reflash a fastboot image using kamakiri.

Can this be done? How? I would be grateful if someone could help on that

 

[Sus_i]

Launching kamakiri bootrom-step.sh goes fine without errors, also gpt-fix.sh runs fine, but then no fastboot appear

Thats a common issue and usually PC releated. You may need to update the fastboot package...

 

[menef8]

Thats a common issue and usually PC releated. You may need to update the fastboot package...

I understand, but I've used the exact method described in post #1 with an Ubuntu 22.04 live stick and that worked flawlessly when I rooted the stick for the first time (just commented lines 73-76 in main.py).
But following your suggestion, to be sure I have tried:

1) another pc
2) using a FireISO stick instead of Ubuntu

They all work the same (fine), but no fastboot appear. The white logo remains for about 2 minutes and then the stick self-reboot (judging on what happens on the tv) in a bootloop.

But kamakiri bootrom-step.sh still works and flash its images, so maybe that a more consistent portion of the emmc could be flashed to revive the stick, at least I think ... am I wrong?

 

[Sus_i]

They all work the same (fine), but no fastboot appear. The white logo remains for about 2 minutes and then the stick self-reboot (judging on what happens on the tv) in a bootloop.

But kamakiri bootrom-step.sh still works and flash its images, so maybe that a more consistent portion of the emmc could be flashed to revive the stick, at least I think ... am I wrong?

You may get an idea of whats wrong if you take an UART bootlog via TTL to USB Serial Adapter at 921600 baud rate. The UART pads are easy to find on the board.

 

[menef8]

You may get an idea of whats wrong if you take an UART bootlog via TTL to USB Serial Adapter at 921600 baud rate. The UART pads are easy to find on the board.

Ok ... I opened the stick ... but where are the UART pads?

 

[Sus_i]

Ok ... I opened the stick ... but where are the UART pads?

View attachment 5769227

On the other side
Take a look at this picture here

https://forum.xda-developers.com/attachments/firetvstick_4k-jpg.4836291/

Thread:

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

NOTE: There have been multiple reports of devices with serial numbers containing VM190 or higher being shipped with DL-Mode disabled in BROM. These devices cannot be unlocked using kamakiri. These devices do not show up at all on USB when...

forum.xda-developers.com

On the pic you see the the three pads RX TX GND, almost similar to the sheldon stick... somewhere near the eMMC chip.

 

[menef8]

On the other side
Take a look at this picture here

https://forum.xda-developers.com/attachments/firetvstick_4k-jpg.4836291/

Thread:

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

NOTE: There have been multiple reports of devices with serial numbers containing VM190 or higher being shipped with DL-Mode disabled in BROM. These devices cannot be unlocked using kamakiri. These devices do not show up at all on USB when...

forum.xda-developers.com

On the pic you see the the three pads RX TX GND, almost similar to the sheldon stick... somewhere near the eMMC chip.

A funny job ... here are the comms at 115k and 921k ...

In my limited understanding I would say that the line of garbage at 921k is nothing more than the same lines of 115k ... and therefore the bootloader has gone

now I need hope ... can I flash a boot loader through kamakiri?

 

[Sus_i]

In my limited understanding I would say that the line of garbage at 921k is nothing more than the same lines of 115k ... and therefore the bootloader has gone

now I need hope ... can I flash a boot loader through kamakiri?

The bootrom log at 115200 looks fine, but the other log failed somehow.
I don't think that the bootloader is gone, as you said kamakiri bootrom-step worked fine, same as GPT fix, so at least the bootloader (MTK preloader and LK) is 100% there and the log should work fine.
I would check the UART and USB/serial settings, cable connections and try again...
Maybe disconnect the tx cable from the stick, try only with rx pad.

 

[DP FH]

Bought a sheldon... whoops it auto-updated... gave it back to amz and bought another one.
Serial protocol 2001 ...
I read there is a downgrade exploit mentioned, so I will block updates and wait... my kindle waited 2 years...
So no way to unlock if serial protocol 2001 ?

 

[DP FH]

@ChriMo In case you wanna know, the DSNs are G4N1EL0323520 and G071EL0323520

 

[usstreet]

@ChriMo DSN G071EL0323220 Serial protocol 2001

 

[wetwaffle_cz]

Is there any known way to do this even if the OS version is higher than 7.2.7.3? I assume there are some points one can short on the PCB or maybe a way to downgrade the OS? If so, how could I do it?

 

[menef8]

The bootrom log at 115200 looks fine, but the other log failed somehow.
I don't think that the bootloader is gone, as you said kamakiri bootrom-step worked fine, same as GPT fix, so at least the bootloader (MTK preloader and LK) is 100% there and the log should work fine.
I would check the UART and USB/serial settings, cable connections and try again...
Maybe disconnect the tx cable from the stick, try only with rx pad.

You are right, disconnected TX wire and the stick started talking at 921K, here is the log, the file contains two boot sequences, line 539 is the point where self-restart happens

 

[Sus_i]

You are right, disconnected TX wire and the stick started talking at 921K, here is the log, the file contains two boot sequences, line 539 is the point where self-restart happens

The log looks ok, except that the LK doesn't finish, doesn't jump to the kernel. The boot.img could be messed up somehow.

Can you try to take a log 'booting fastboot' via bootrom-step?

 

[menef8]

The log looks ok, except that the LK doesn't finish, doesn't jump to the kernel. The boot.img could be messed up somehow.

Can you try to take a log 'booting fastboot' via bootrom-step?

Things are getting harder: I said that bootrom-step.sh and gpt-fix.sh runs fine and that's true.
But when capturing UART comms they both fail! I tried more times and behave like that, so I decided to get serial log and screen output for all combinations, with and without serial attached.

I can't figure if this behaviour originates from the stick itself or is a conflict somewhere in Ubuntu when using serial comm and kamakiri at the same time...

 

[Sus_i]

Things are getting harder: I said that bootrom-step.sh and gpt-fix.sh runs fine and that's true.
But when capturing UART comms they both fail! I tried more times and behave like that, so I decided to get serial log and screen output for all combinations, with and without serial attached.

Forget about that. The reason for your issue is most likely a messed up boot.img, since there is no sign from kamakiris microloader in your logs. Thats probably also the reason why the LK bootloops and fastboot wont come up.

So I would say you need to flash a new boot.img via kamakiri main.py. Add the flash between step 5 and 6. @Rortiz2 mentioned somewhere how to do this, you may ask him if you like.

Maybe just flash the TWRP image too, as one of the last steps in the main.py. Both will take some time, but then you don't need the fastboot step and after that you should see the microloader and a jump to the kernel in your log.

 

[VelvetB]

• sheldonp End. Nov. 2022 SE USA DSN G071EL1521..... unlocking successful So looking at the 1522 that failed and my successful 1521, common sense would say the upgrade was some where in between, unless the locations and 3 letters makes a difference? BTW, can harm be done knowing a full serial number?

Agree @Sus_i Updated request:

All who have bought in the last months please report:
1) model (sheldon/p), date buyed and optionally the region or nation of the shop
2) DSN code: first 10 characters (label at the bottom of the package, sheldon usually G071CQ.... , sheldonp G071EL.... or G4N1EL....) and optionally made in/parts made in
3) unlocking successful or unsuccessful

My Report

• sheldon mid Sept. 2022 UE Central Europe, DSN G071CQ1320 China, unlocking successful
• sheldon begin Oct. 2022 UE Central Europe, DSN G071CQ1522 China, unlocking unsuccessful
• sheldon mid. Oct. 2022 MW Central Europe, DSN G071CQ1320 China, not on sale / not buyed
• sheldonp mid. Oct. 2022 MW Central Europe, DSN G071EL1520 China, not on sale / not buyed
• sheldonp mid. Oct. 2022 MW Central Europe, DSN G4N1EL0614 Vietnam/China, not on sale / not buyed

As you can see the last three are not on sale anymore, otherwise I would have tested the G071CQ1320 or G4N1EL0614. Not sure if the Vietnam/China variant might be vulnerable, the G071CQ1320 almost for sure.

 

[menef8]

Forget about that. The reason for your issue is most likely a messed up boot.img, since there is no sign from kamakiris microloader in your logs. Thats probably also the reason why the LK bootloops and fastboot wont come up.

So I would say you need to flash a new boot.img via kamakiri main.py. Add the flash between step 5 and 6. @Rortiz2 mentioned somewhere how to do this, you may ask him if you like.

Maybe just flash the TWRP image too, as one of the last steps in the main.py. Both will take some time, but then you don't need the fastboot step and after that you should see the microloader and a jump to the kernel in your log.

Solved! I have read post from @Rortiz2 and figure out how to.

I just copied boot.emmc.win in bin and rename as boot.img, then added these lines in main.py between step 6 and 8, before the microloader flash:

log("Flash boot")
switch_user(dev)
flash_binary(dev, "../bin/boot.img", gpt["boot"][0], gpt["boot"][1] * 0x200)

After bootrom-step.sh finishes proceed with fastboot-step and voilà

Thank you for you support

 

[disco_y2k]

I tried following the OP's instructions on several Linux laptops and even tried FireISO. I have followed the instructions to the letter and I always end up with the same result. It appears that everything loaded fine, but I get a Hacked Bootloader message on the TV screen? Any ideas what I am doing wrong? Thanks in advance!