FORUMS

Fire HD 8 (2018 ONLY) unbrick, downgrade, unlock & root

115 posts
Thanks Meter: 332
 
By xyz`, Senior Member on 27th January 2019, 06:04 PM
Post Reply Email Thread
28th January 2019, 04:17 PM |#51  
This is what the board looks like on the HD 10, with the 3 aluminum panels removed. Image 1, The camera is black circle in the upper left corner. The red, white and black wires and clip is the battery cable. To the left is the 'port' containing the supposed 4 pinholes, 1, 39, 2, 40. Image 2, To the right of the battery cable and clip is another 'port'. This does not appear to contain any pin points. I've looked it over several times and these are the only two places that are similar to the OP.

Sent from my MotoG3 using XDA Labs
Attached Thumbnails
Click image for larger version

Name:	IMG_20190128_110715.jpg
Views:	832
Size:	260.1 KB
ID:	4695367   Click image for larger version

Name:	IMG_20190128_111451.jpg
Views:	766
Size:	254.2 KB
ID:	4695368  
28th January 2019, 04:59 PM |#53  
Senior Member
Thanks Meter: 1,825
 
Donate to Me
More
RIP Mediatek security....
Quote:
Originally Posted by xyz`

Make sure to read this guide completely before starting. It requires you to open the tablet, however you don't need to solder or use any advanced tools.

This is only for Fire HD 8, 8th generation, also known as karnak or KFKAWI. I've also only tested this on the 16GB version, though the 32GB one should work the same.

Those are some sick exploits, @xyz`! You've just cracked virtually all of Amazon's Mediatek-based devices. Not only Amazon, but you have defeated Mediatek secure boot in general. Who are you?

Every device that has a secure bootloader with blocked SP Flash Tool access and a secure boot ROM can now be accessed and essentially made unlocked. (I can think of others besides Amazon's.) You just have to find the pins and port the exploits to the specific platform. But that's peanuts compared to making your initial implementation. XDA needs to write an article about this exploit....

I did go over your work briefly, and I understand it for the most part. There are a couple of things that were surprising and I didn't expect:
  • You can overwrite boot ROM code(?). The boot ROM is read-only so I assume it's loaded into and running from SRAM, and this is the copy you modify. But then how can it execute while being encrypted? Moreover, I think there could be another copy of it, the actual ROM, possibly unencrypted. I know on 32-bit chips, it's at 0xFFFF0000.
  • You can reset the RPMB region(?). I thought the RPMB keeps track of how many times a block is written to and this number can never be decreased. And this write count is how the bootloader determines which version of it should be running. I guess either Amazon's implementation is flawed or this is not how RPMB works.

Again, incredible work, man. I hope this takes off and you or other people start porting this to other devices.
The Following 2 Users Say Thank You to diplomatic For This Useful Post: [ View ] Gift diplomatic Ad-Free
28th January 2019, 06:57 PM |#54  
Senior Member
Thanks Meter: 1,665
 
Donate to Me
More
@xyz` I have gotten a step further and am able to overwrite the boundary-value.
A readout after writing it confirms it is set to the expected value.
Now I'm stuck at loading the payload:
Code:
dev.write32(0x201000, words)
Since this doesn't use aes_write does that mean boundaries are still checked for some reason?

It fails at
Code:
self.check(self.dev.read(2), b'\x00\x01') # arg check
the read returns b'\x1d\x04' instead of the expected b'\x00\x01'
(ignoring the check just leads to the next error)

EDIT:
if i write to 0x200D00 instead of 0x201000 it seems to work?!
Could you point me to finding a suitable pointer to overwrite with the jump to the payload?
(0x1028A8 in your case)

Quote:
Originally Posted by diplomatic

You can reset the RPMB region(?). I thought the RPMB keeps track of how many times a block is written to and this number can never be decreased. And this write count is how the bootloader determines which version of it should be running. I guess either Amazon's implementation is flawed or this is not how RPMB works.

i believe that works because the payload runs in the context of the boot-rom before it switches to the secure context, where overwriting RPMB wouldn't work.
The Following User Says Thank You to k4y0z For This Useful Post: [ View ] Gift k4y0z Ad-Free
28th January 2019, 07:03 PM |#55  
Senior Member
Flag Verona
Thanks Meter: 276
 
More
Quote:
Originally Posted by xyz`

Follow the revert to stock instructions, you can flash zips from adb shell (use "twrp install 6300.zip" then "twrp install revert-stock.zip")

@xyz the suggestion to reboot as soon as I get to the recovery shell didn't fix the touchscreen problem (no signal).
The suggested reboot just display the Amazon white logo for a blink and then everything turn dark, no video !

Could it be a slightly different hardware between 16GB and 32GB HD 8 tablet models ?
I am pointing my finger against the touchscreen hardware, mine uses bq25601 chip.
It seems there are two different device drivers available bq25601 and bq24297.
The touchscreen hardware is on I2C bus #2 and the slave address is 0x6b.
But I am shooting in the dark ... You are the master !!!

I confirm that this [DL] (Download mode) is wicked stuff. It was willingly put on chips to make impossible to brick the device.
I read about it in older Mediatek documentation written by @sturmflut (now moved here: Mediatek details).

Let's say that this thing is unbreakable, Lab126 did the ANTI-ROLLBACK to make our tablets go havoc and brick forever.
While you did the magic ANTI-BRICKING and reviving counter-stuff. Not only that, you raised the bar:
in the real spirit of Java, this is a write once and exploit everywhere on every Mediatek tablets.
Ha ... ha ... great stuff pal. You made my day and all the coming month too.

Now ... everybody have fun !!!

.:HWMOD:.

---------- Post added at 08:03 PM ---------- Previous post was at 07:58 PM ----------

Quote:
Originally Posted by diplomatic

Those are some sick exploits, @xyz`! You've just cracked virtually all of Amazon's Mediatek-based devices. Not only Amazon, but you have defeated Mediatek secure boot in general. Who are you?

Every device that has a secure bootloader with blocked SP Flash Tool access and a secure boot ROM can now be accessed and essentially made unlocked. (I can think of others besides Amazon's.) You just have to find the pins and port the exploits to the specific platform. But that's peanuts compared to making your initial implementation. XDA needs to write an article about this exploit....

I did go over your work briefly, and I understand it for the most part. There are a couple of things that were surprising and I didn't expect:

  • You can overwrite boot ROM code(?). The boot ROM is read-only so I assume it's loaded into and running from SRAM, and this is the copy you modify. But then how can it execute while being encrypted? Moreover, I think there could be another copy of it, the actual ROM, possibly unencrypted. I know on 32-bit chips, it's at 0xFFFF0000.
  • You can reset the RPMB region(?). I thought the RPMB keeps track of how many times a block is written to and this number can never be decreased. And this write count is how the bootloader determines which version of it should be running. I guess either Amazon's implementation is flawed or this is not how RPMB works.

Again, incredible work, man. I hope this takes off and you or other people start porting this to other devices.

@diplomatic, you recall ? Just a couple of weeks ago we were speaking about the unbreakable "chain of trust".
Well this genius made it. No more bricked tablet and let's revive also those that were given as dead and unrecoverable.

.:HWMOD:.
The Following 2 Users Say Thank You to hwmod For This Useful Post: [ View ] Gift hwmod Ad-Free
28th January 2019, 07:40 PM |#56  
Senior Member
Thanks Meter: 115
 
Donate to Me
More
Outstanding work xyz`, this exploit made me pick up my fire hd 8 7th gen again.
Since the amonet.tar.gz has been remove I've download your repository and i've tested the exploit on my fire, everything seems to work except for the downgraded because is not present, now i have some questions:
-the downgrade files (in the bin folder) are original from the tablet or need to be patched
-is the downgrade is necessary (is an 8th gen thing or is essential for the exploit)
-where boot0-short.bin came from
-is microloader.bin the same as the output of the compilation of microloader (the output is called payload.bin)

I can not wait for the write-up of this exploit
28th January 2019, 08:13 PM |#57  
Quote:
Originally Posted by hwmod

@xyz the suggestion to reboot as soon as I get to the recovery shell didn't fix the touchscreen problem (no signal).
The suggested reboot just display the Amazon white logo for a blink and then everything turn dark, no video !

Could it be a slightly different hardware between 16GB and 32GB HD 8 tablet models ?
I am pointing my finger against the touchscreen hardware, mine uses bq25601 chip.
It seems there are two different device drivers available bq25601 and bq24297.
The touchscreen hardware is on I2C bus #2 and the slave address is 0x6b.
But I am shooting in the dark ... You are the master !!!

I confirm that this [DL] (Download mode) is wicked stuff. It was willingly put on chips to make impossible to brick the device.
I read about it in older Mediatek documentation written by @sturmflut (now moved here: Mediatek details).

Let's say that this thing is unbreakable, Lab126 did the ANTI-ROLLBACK to make our tablets go havoc and brick forever.
While you did the magic ANTI-BRICKING and reviving counter-stuff. Not only that, you raised the bar:
in the real spirit of Java, this is a write once and exploit everywhere on every Mediatek tablets.
Ha ... ha ... great stuff pal. You made my day and all the coming month too.

Now ... everybody have fun !!!

.:HWMOD:.

---------- Post added at 08:03 PM ---------- Previous post was at 07:58 PM ----------



@diplomatic, you recall ? Just a couple of weeks ago we were speaking about the unbreakable "chain of trust".
Well this genius made it. No more bricked tablet and let's revive also those that were given as dead and unrecoverable.

.:HWMOD:.

My question is:
How can we use this exploit to unbrick the bricked fires?
28th January 2019, 08:15 PM |#58  
OP Senior Member
Thanks Meter: 332
 
More
Quote:
Originally Posted by pcrii

after fastboot i couldnt get the recovery to display on the screen adb confirmed i was in recovery though. i retried several times unplugging the battery several times and ended up breaking the connector. is it possible to find/buy that connector type and resolder myself?

I'm not sure if it's a standard connector, however what you can do is cut off the battery connector part, solder on longer wires and solder to the battery test points above the connector (labeled supply / id / on / gnd). Obviously it's dangerous, make sure to check everything for continuity with a multimeter before.

Quote:
Originally Posted by Supersonic27543

@xyz` Thank you for this! It looks like this method required a lot of serious coding on your part, and some trial and error too. I'm guessing that this'll not work on the HD 8 2017, my current target, for the reasons you mentioned for the Fire 7 2017?
Even though that this method has a few bugs, I'm sure that you'll eventually manage to overcome them! Good luck with your development

It should work on the 2017 model as well, the main difficulty would be porting the lk exploit (since the latest preloader on 2017 model forces 64-bit Linux kernel and the way I exploit it requires a 32-bit one); one thing to try would be flashing 2018's preloader (since it's using the same rsa key it might just work) and lk, another is implement the exploit for the 64-bit case (should be possible).

Quote:
Originally Posted by diplomatic

You can overwrite boot ROM code(?). The boot ROM is read-only so I assume it's loaded into and running from SRAM, and this is the copy you modify. But then how can it execute while being encrypted? Moreover, I think there could be another copy of it, the actual ROM, possibly unencrypted. I know on 32-bit chips, it's at 0xFFFF0000.

No, the bootrom is read only and all writes to it are ignored. However, bootrom still has to use read-write memory (for its data segment and the stack), which is what I'm overwriting.

Quote:
Originally Posted by diplomatic

You can reset the RPMB region(?). I thought the RPMB keeps track of how many times a block is written to and this number can never be decreased. And this write count is how the bootloader determines which version of it should be running. I guess either Amazon's implementation is flawed or this is not how RPMB works.

The rpmb region is replay-protected, meaning you cannot capture emmc WRITE packets and replay them to flash an older version, this is the purpose of the write counter. Write counter isn't supposed to be used to prevent downgrades (although if you try really hard you definitely can use it this way). The actual data of the rpmb block is used for that, it stores versions of preloader, lk and tz. The other thing is that the rpmb block is protected with a device-specific key, however since we're running in a very privileged mode it's easy to derive it just copying what preloader's doing. Then I'm overwriting rpmb with zeroes and on next boot the downgraded preloader provisions it with the proper data (and as a bonus, you now get to mix and match different preloader/lk/tz versions).

Quote:
Originally Posted by hwmod

Could it be a slightly different hardware between 16GB and 32GB HD 8 tablet models ?
I am pointing my finger against the touchscreen hardware, mine uses bq25601 chip.
It seems there are two different device drivers available bq25601 and bq24297.
The touchscreen hardware is on I2C bus #2 and the slave address is 0x6b.

That's what I'm thinking too. When I'm reloading lk as part of the exploit, the display detection breaks somehow so I've just assumed every device would have the same display and hardcoded the vendor value here https://github.com/xyzz/amonet/blob/...ad/main.c#L128 but it seems not to be the case. I'll try to figure a way to repair the display without hardcoding its id (but if somebody can get a UART boot log that'd be immensely helpful)

Quote:
Originally Posted by t0x1cSH

Outstanding work xyz`, this exploit made me pick up my fire hd 8 7th gen again.

It's probably not a good idea to run as-is on fire 8 7th gen since it'd flash 8th's preloader, lk and tz and I don't know if they are compatible.

Quote:
Originally Posted by t0x1cSH

-the downgrade files (in the bin folder) are original from the tablet or need to be patched

They are originals from 6.3.0.0 (dumped from a never-updated device)

Quote:
Originally Posted by t0x1cSH

-is the downgrade is necessary (is an 8th gen thing or is essential for the exploit)

Yeah, only 6.3.0.0 preloader is exploitable in the specific way I'm doing (changing boot.img to fake 32-bit kernel image)

Quote:
Originally Posted by t0x1cSH

-where boot0-short.bin came from

It's a dump of the boot0 partition, which stores the preloader. I've chopped it off past the first preloader (it stores 2 copies) so that it doesn't take forever to flash.

Quote:
Originally Posted by t0x1cSH

-is microloader.bin the same as the output of the compilation of microloader (the output is called payload.bin)

Nope, microloader.bin is a result of doing an inject_payload.py on a boot image (and then hex editing it to insert the magic FASTBOOT_PLEASE string that I check for here https://github.com/xyzz/amonet/blob/...ad/main.c#L101)

I'll upload the amonet.tar for reference here (but do not use it as it's got the display bug).
Attached Files
File Type: tar amonet.tar - [Click for QR Code] (15.59 MB, 96 views)
The Following 2 Users Say Thank You to xyz` For This Useful Post: [ View ] Gift xyz` Ad-Free
28th January 2019, 08:17 PM |#59  
OP Senior Member
Thanks Meter: 332
 
More
Quote:
Originally Posted by Rortiz2

My question is:
How can we use this exploit to unbrick the bricked fires?

Depends on how it's got bricked, but in most cases it should be enough to just follow the instructions; when you start it doesn't matter if your device is bricked or not. But in theory you should be able to recover from any software brick, even if you destroy the partition table and flash zeroes to the emmc.
The Following User Says Thank You to xyz` For This Useful Post: [ View ] Gift xyz` Ad-Free
28th January 2019, 08:21 PM |#60  
Quote:
Originally Posted by xyz`

Depends on how it's got bricked, but in most cases it should be enough to just follow the instructions; when you start it doesn't matter if your device is bricked or not. But in theory you should be able to recover from any software brick, even if you destroy the partition table and flash zeroes to the emmc.

Thanks for the fast reply.
Another question:
How have you flashed TWRP without unlocking the bootloader?
28th January 2019, 08:25 PM |#61  
OP Senior Member
Thanks Meter: 332
 
More
Quote:
Originally Posted by Rortiz2

Thanks for the fast reply.
Another question:
How have you flashed TWRP without unlocking the bootloader?

That's the purpose of the microloader, it's exploiting a bug in how lk is loading the boot image (without checking load address/size), then I'm patching it to fake device unlocked status.
The Following User Says Thank You to xyz` For This Useful Post: [ View ] Gift xyz` Ad-Free
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes