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

xyz` · Jan 27, 2019

Changelog:

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. It's now confirmed to work on both 16GB and 32GB models.

You will lose all data on the tablet, make a backup of important data before you start. If you've enabled encryption, it's probably a good idea to disable it before you proceed with the guide.

What you need:
- a Linux installation. Since I had to rush it, this guide is only for Linux. Once I get a chance to test it on Windows I'll update the guide.
- microusb cable to connect your tablet to the PC
- some way to open the tablet (pry tool, opening picks, etc)
- something conductive (metal tweezers, a paper clip, a piece of wire, etc)
- amonet.tar.gz
- 6300.zip: https://mega.nz/#!FI1HSI5T!2zUAeiW9I-eH3Ph0Ar10_2nioNIm0ilSnNYgOG9YPNE
- Magisk-v18.0.zip: https://github.com/topjohnwu/Magisk/releases/download/v18.0/Magisk-v18.0.zip
- finalize.zip

Install python3, PySerial, adb and fastboot. For Debian/Ubuntu something like this should work "sudo apt install python3 python3-serial android-tools-adb android-tools-fastboot".

Extract amonet.tar.gz, open a terminal and navigate to it.

You might need to run the scripts on your PC under sudo if you're getting permission errors.

0. Shut your device down and disconnect it from USB! Also, disconnect all other Android devices you might have connected from your PC. Also, if you have ModemManager installed, you MUST disable or uninstall it before you begin
1. Use a pry tool to remove the back shell from the tablet. Start at the bottom and work your way up. There are no cables between the back shell and the motherboard.
2. On the left side of the board there are 4 test points labeled DAT0, RST, CMD, CLK. We only care about the bottom one, CLK.
3. Plug in one end of the microusb cable, either to the PC or to the tablet, whatever's more convenient.
4. On your PC, run `./bootrom-step.sh`. It should print "Waiting for the bootrom".
5. Using your conductive apparatus, short the CLK test point to the ground. This means you should connect one side of your paperclip to the CLK pin and the other to the metallic shield or a side of the PCB. Firmly hold it in place so that there is connection. (See https://i.imgur.com/7BXIb2y.jpg)
6. Plug in the other end of the microusb cable.
7. You should see a new device appear on your PC

Code:

[10894.058045] usb 3-2.4.1: new full-speed USB device number 9 using xhci_hcd
[10894.239684] usb 3-2.4.1: New USB device found, idVendor=0e8d, idProduct=0003
[10894.239690] usb 3-2.4.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[10894.241330] cdc_acm 3-2.4.1:1.0: ttyACM0: USB ACM device

This *must* be the device you see. If you see a "preloader" device instead, you didn't hold the paperclip strong enough. Unplug it, shut down your Fire (pull out USB cord and wait; if it doesn't shut down, you might have to disconnect the battery) and try again starting at step 4.

8. The script you ran in step 4 should now tell you to remove the short. Remove the paperclip and press Enter as instructed.
9. The script will now proceed to downgrade your device and flash some essential files. Just let it be, it will take about 4 minutes. You should see the following output:

If the script freezes at some point, you will have to restart it. Terminate the script, unplug USB, and try again starting at step 4. If after unplugging USB cable the device doesn't shut down, you might have to disconnect the battery. You can keep it disconnected until the script succeeds, but once it's done you must reconnect it before booting to fastboot.

9. You should see a success message: "Reboot to unlocked fastboot". Only proceed if you see the message.
10. Once the device boots to fastboot (check with "fastboot devices". You should see amazon logo on the screen.), you can run "./fastboot-step.sh". Then, flip the device over so that you can see the display.
11. At this point the device should boot into recovery, however it's possible that the screen will be off by default. Just press the power button twice and the screen should turn on.
12. We'll now upload required files to the recovery. On your PC, do:

adb push 6300.zip /sdcard
adb push Magisk-v18.0.zip /sdcard
adb push finalize.zip /sdcard

13. In the recovery, go to "Install", navigate to "/sdcard" and flash 6300.zip
14. Go to "Wipe" and do the default wipe, then reboot
15. At the Fire setup screen, select your language. On the next screen, Wifi setup, select any password-protected network, then instead of entering the password press "cancel". Now, back at the wifi setup screen, press "skip" and "skip" in the dialog pop-up again
16. Hold down the power button, press Restart and hold volume down to boot into recovery.

17. In the recovery, go to "Install", navigate to "/sdcard" and flash Magisk-v18.0.zip
18. Press back, select finalize.zip and flash it
19. Once finalize.zip is flashed, press "Reboot System"

20. Done. The device should now boot into a rooted 6.3.0.0 firmware. You should have Magisk manager installed, and root working. You will be able to boot into recovery by holding volume down.
21. At this point it should be safe to connect to wifi. If everything works okay, assemble your device.

Your device is now unlocked. You can flash a custom boot image, system image, etc. However, if you ever brick the device so bad the recovery does not boot, you will have to repeat these steps starting from the first one. Read below for what you should not do.

VERY IMPORTANT STUFF:
Only ever flash boot images from TWRP. Since nothing but TWRP is aware of the exploit, if you try to flash a boot image from Android, it won't have the exploit integrated into it! This includes Magisk as well, so do NOT install or uninstall it from Magisk Manager (However, installing modules should be fine; although it depends on the specific module).

Due to how the exploit works, it takes over the first 0x400 bytes of boot.img/recovery.img. When flashing zips from the recovery, it will transparently remove and then reinstall the exploit when needed. So long as you flash zips from the recovery, you should treat the boot image normally. However, this means that you cannot use any other apps (e.g. FlashFire) to flash the boot or recovery partitions.

To revert back to stock:

Another way to fix a brick:

Other misc information / troubleshooting:
- If you need to disconnect the battery, use a pair of tweezers to grab the wires and gently pull towards yourself. You can do bootrom-step.sh either with or without the battery connected, however fastboot-step.sh should be done with the battery connected.
- If your device is bricked (e.g. from a downgrade), just follow the steps as-is.
- If you're getting an error like "Serial protocol mismatch", or any other error in bootrom-step, try disabling or temporarily uninstalling ModemManager from your Linux
- To remount /system as rw use "mount -o rw,remount /system". ("mount -o remount,rw /system" will not work)

Thanks to: @hwmod @firetablethelp for testing different versions of the payload.
Special thanks to: aftv2-tools contributors https://gitlab.com/zeroepoch/aftv2-tools; the bootrom download protocol scripts are largely based on their work

xyz` · Jan 27, 2019

GPL Notice:
- Source code for modified TWRP is available from https://github.com/xyzz/android_bootable_recovery
- Source code for amonet/brom-payload is available from https://github.com/xyzz/amonet/tree/master/brom-payload

Device tree to build TWRP: https://github.com/xyzz/android_device_amazon_karnak

Additionally, source code of the full exploit chain is available from https://github.com/xyzz/amonet

When I finish the writeup for this vulnerability, I'll update this post with a URL to the writeup.

beanaman · Jan 27, 2019

You sir, are a marvelous wizard leet haxor ?. Thanks for this. Will this ever lead to any software solution for root on this tablet. Parden my noob questions?

xyz` · Jan 27, 2019

beanaman said:
You sir, are a marvelous wizard leet haxor . Thanks for this. Will this ever lead to any software solution for root on this tablet. Parden my noob questions?

The only reason you have to open the tablet is to put the bootrom into download mode. If somebody figures out another way to do that, then yes it can be done completely in software. One way is to brick the tablet by erasing the preloader completely (both copies). However, this would require root (temporarily), and is more dangerous. Ultimately, I figured that the difficulty level here is about as much as replacing a battery (even lower) so I haven't investigated this further.

beanaman · Jan 27, 2019

Thank you for explaining that further. It's nice to have this capability in our toolbox.

Rortiz2 · Jan 27, 2019

Wow! @xyz` you are a genius!
This exploit can be applied to fire 7 7th gen?

DragonFire1024 · Jan 27, 2019

xyz` said:
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.

You will lose all data on the tablet, make a backup of important data before you start. If you've enabled encryption, it's probably a good idea to disable it before you proceed with the guide.

What you need:
- a Linux installation. Since I had to rush it, this guide is only for Linux. Once I get a chance to test it on Windows I'll update the guide.
- microusb cable to connect your tablet to the PC
- some way to open the tablet (pry tool, opening picks, etc)
- something conductive (metal tweezers, a paper clip, a piece of wire, etc)
- amonet.tar.gz
- 6300.zip: https://mega.nz/#!FI1HSI5T!2zUAeiW9I-eH3Ph0Ar10_2nioNIm0ilSnNYgOG9YPNE
- Magisk-v18.0.zip: https://github.com/topjohnwu/Magisk/releases/download/v18.0/Magisk-v18.0.zip
- finalize.zip

Install python3, PySerial, adb and fastboot. For Debian/Ubuntu something like this should work "sudo apt install python3 python3-serial android-tools-adb android-tools-fastboot".

Extract amonet.tar.gz, open a terminal and navigate to it.

You might need to run the scripts on your PC under sudo if you're getting permission errors.

0. Shut your device down and disconnect it from USB! Also, disconnect all other Android devices you might have connected from your PC.
1. Use a pry tool to remove the back shell from the tablet. Start at the bottom and work your way up. There are no cables between the back shell and the motherboard.
2. On the left side of the board there are 4 test points labeled DAT0, RST, CMD, CLK. We only care about the bottom one, CLK.
3. Plug in one end of the microusb cable, either to the PC or to the tablet, whatever's more convenient.
4. On your PC, run `./bootrom-step.sh`. It should print "Waiting for the bootrom".
5. Using your conductive apparatus, short the CLK test point to the ground. This means you should connect one side of your paperclip to the CLK pin and the other to the metallic shield or a side of the PCB. Firmly hold it in place so that there is connection. (See https://i.imgur.com/7BXIb2y.jpg)
6. Plug in the other end of the microusb cable.
7. You should see a new device appear on your PC

This *must* be the device you see. If you see a "preloader" device instead, you didn't hold the paperclip strong enough. Unplug it, shut down your Fire (pull out USB cord and wait; if it doesn't shut down, you might have to disconnect the battery) and try again starting at step 4.

8. The script you ran in step 4 should now tell you to remove the short. Remove the paperclip and press Enter as instructed.
9. The script will now proceed to downgrade your device and flash some essential files. Just let it be, it will take about 4 minutes. You should see the following output:

If the script freezes at some point, you will have to restart it. Terminate the script, unplug USB, and try again starting at step 4. If after unplugging USB cable the device doesn't shut down, you might have to disconnect the battery. You can keep it disconnected until the script succeeds, but once it's done you must reconnect it before booting to fastboot.

9. You should see a success message: "Reboot to unlocked fastboot". Only proceed if you see the message.
10. Once the device boots to fastboot (check with "fastboot devices"), you can run "./fastboot-step.sh". Then, flip the device over so that you can see the display.
11. At this point the device should boot into recovery, however it's possible that the screen will be off by default. Just press the power button twice and the screen should turn on.
13. We'll now upload required files to the recovery. On your PC, do:

adb push 6300.zip /sdcard
adb push Magisk-v18.0.zip /sdcard
adb push finalize.zip /sdcard

14. In the recovery, go to "Install", navigate to "/sdcard" and flash 6300.zip
15. Go to "Wipe" and do the default wipe, then reboot
16. At the Fire setup screen, select your language. On the next screen, Wifi setup, select any password-protected network, then instead of entering the password press "cancel". Now, back at the wifi setup screen, press "skip" and "skip" in the dialog pop-up again
17. Hold down the power button, press Restart and hold volume down to boot into recovery.

18. In the recovery, go to "Install", navigate to "/sdcard" and flash Magisk-v18.0.zip, finalize.zip, in that order.
15. Press "Reboot System" once the latest zip, finalize.zip, is installed.

16. Done. The device should now boot into a rooted 6.3.0.0 firmware. You should have Magisk manager installed, and root working. You will be able to boot into recovery by holding volume down.
17. At this point it should be safe to connect to wifi. If everything works okay, assemble your device.

Your device is now unlocked. You can flash a custom boot image, system image, etc. However, if you ever brick the device so bad the recovery does not boot, you will have to repeat these steps starting from the first one. Read below for what you should not do.

VERY IMPORTANT STUFF:
Only ever flash boot images from TWRP. Since nothing but TWRP is aware of the exploit, if you try to flash a boot image from Android, it won't have the exploit integrated into it! This includes Magisk as well, so do NOT install or uninstall it from Magisk Manager (However, installing modules should be fine; although it depends on the specific module).

Due to how the exploit works, it takes over the first 0x400 bytes of boot.img/recovery.img. When flashing zips from the recovery, it will transparently remove and then reinstall the exploit when needed. So long as you flash zips from the recovery, you should treat the boot image normally. However, this means that you cannot use any other apps (e.g. FlashFire) to flash the boot or recovery partitions.

To revert back to stock:

- download update package from amazon https://fireos-tablet-src.s3.amazon...ate-kindle-NS6301_user_1611_0001309035396.bin to your PC
- flash 6300.zip from twrp
- flash revert-stock.zip from twrp
- wipe data
- reboot to recovery; you should see amazon recovery now
- select "apply update from ADB" in the recovery menu
- run "adb sideload update-kindle-NS6301_user_1611_0001309035396.bin" on your PC

Special thanks to: aftv2-tools contributors https://gitlab.com/zeroepoch/aftv2-tools; the bootrom download protocol scripts are largely based on their work

LMFAO I can't ****ing believe this. I'm almost certain this will work on the HD 10 too. You found it before me. Absolutely brilliant. You've just proved many weeks and or months of my hard research that I've posted in more than a few threads between the fire 7 forums and here. You just happened to be a lot quicker at this and probably smarter. ACM I discovered a few weeks or months ago on the HD 10. There is a build file that has many ways to set ACM props. doing this made everything light up on my PC...new drivers were installed and being used including the preloader drivers. I set my test HD 10 to persist ACM since then, convinced it was one of the possible keys to the puzzle. If you've read anything I've done in the past several weeks and months you may have been the only one who truly believed anything I had been saying. I don't know who you are or where you came from but I can only thank you. You've made my day, my week and my year. At least now I can say I'm not crazy, hallucinating or 'don't know what I'm doing or talking about.' it will take me a few days to get started, but I'll get right to testing my test HD 10 in the next few days or so.

Edit: I was convinced it had to do with fos_flags too, which I believe is another way to unlock.

Sent from my MotoG3 using XDA Labs

xyz` · Jan 27, 2019

Rortiz2 said:
Wow! @xyz` you are a genius!
This exploit can be applied to fire 7 7th gen?

The vulnerability is present on every mediatek device, so yeah. It will not work as-is because of different addresses (for the crypto device and offsets for LK). Additionally, on Fire 7 7th gen the eMMC test point is hidden behind the shield that you need to desolder, so you will probably want to find a different way to enter the bootrom download mode.

k4y0z · Jan 27, 2019

Great work!

xyz` said:
The vulnerability is present on every mediatek device, so yeah. It will not work as-is because of different addresses (for the crypto device and offsets for LK). Additionally, on Fire 7 7th gen the eMMC test point is hidden behind the shield that you need to desolder, so you will probably want to find a different way to enter the bootrom download mode.

This is very promising could you please elaborate, what exactly needs to be modified to port this to other MTK-hardware.
I have a fire 5th gen here and I can access brom-mode by pressing left mute button while pluging in.
tried your scripts as is (commenting out the parts that change rpmb or flash partitions) and it get's stuck at

Code:

[2019-01-28 00:01:40.973289] Disable bootrom range checks

Does the hash in load_payload.py (4dd12bdf0ec7d26c482490b3482a1b1f) need to be modified?
I do have the kernel-sources for the device and am willing to investigate correct addressing etc.

Also since this is a boot-rom exploit wouldn't it allow flashing a hacked preloader + lk which just ignore boot-signatures so we can just run a standard twrp?

xyz` · Jan 27, 2019

k4y0z said:
This is very promising could you please elaborate, what exactly needs to be modified to port this to other MTK-hardware.
I have a fire 5th gen here and I can access brom-mode by pressing left mute button while pluging in.
tried your scripts as is (commenting out the parts that change rpmb or flash partitions) and it get's stuck at

Code:

[2019-01-28 00:01:40.973289] Disable bootrom range checks

Does the hash in load_payload.py (4dd12bdf0ec7d26c482490b3482a1b1f) need to be modified?
I do have the kernel-sources for the device and am willing to investigate correct addressing etc.

Also since this is a boot-rom exploit wouldn't it allow flashing a hacked preloader + lk which just ignore boot-signatures so we can just run a standard twrp?

So first of all make sure you're accessing bootrom mode and not preloader mode (Although if the preloader supports read/write, the exploit should work there as well, I just haven't tested it since on hd 8 8th gen none of preloaders support these). I suggest soldering on a UART adapter, then use 115200 baud rate. When in bootrom dl mode, you should see "[DL] 00000BB8 444C0005 010701" (basically, the "[DL]" part is the important one)

If it's a different soc, you will have to dump the bootrom and find the offset where range check data is stored (in my case, 0x102868). You might have to modify the 4dd12bdf0ec7d26c482490b3482a1b1f part as well, it's basically calculated as a xor of expected data and actual data it's written. Then, you'll also need to update the pointer I'm overwriting (0x1028A8 in my case, called ptr_send in brom-payload). Again, if executing under preloader it's gonna be completely different way to exploit it.

Once all this is done, you should be able to load binary payloads and execute them in bootrom mode. You'll also need to edit brom-payload and set up proper pointers to send_dword/recv_dword/etc, these can be found by reversing your bootrom dump. At this point it should be possible to get emmc read/write.

Finally, if you want a persistent unlock (and not just the ability to modify /system) you'll need to port lk exploit as well. So you'll have to figure if your lk is vulnerable to the same bug, port microloader, inject_microloader.py and lk-payload to use the proper offsets. It's a lot of work.

I'll hopefully finish my writeup in the next weeks and post a link to it, that should be easier to understand since I'll explain the whole process from start to finish.

You're right about being able to load a custom preloader/lk, however the bootrom exploit requires a PC connection and a bunch of USB commands (so in a way, it's "tethered"). The actual unlock exploit isn't using any bootrom bugs, but rather the lk bug, since that one works without a PC. In fact, the bootrom exploit is only used to flash stuff to eMMC (but, of course you could probably do more fun stuff with it) in my chain.

k4y0z · Jan 28, 2019

Thanks for your quick reply.

xyz` said:
So first of all make sure you're accessing bootrom mode and not preloader mode (Although if the preloader supports read/write, the exploit should work there as well, I just haven't tested it since on hd 8 8th gen none of preloaders support these). I suggest soldering on a UART adapter, then use 115200 baud rate. When in bootrom dl mode, you should see "[DL] 00000BB8 444C0005 010701" (basically, the "[DL]" part is the important one)

I'm pretty sure I'm in boot-rom, my preloader actually has direct read/write using read_mmc.py but that has been fixed in newer preloaders, so I would rather go the boot-rom route.
Have you tried if pressing left (or both) volume buttons while pluging in brings you to brom-mode as well, like it does on my device?
I'll attach a serial to check for the output.

xyz` said:
If it's a different soc, you will have to dump the bootrom and find the offset where range check data is stored (in my case, 0x102868). You might have to modify the 4dd12bdf0ec7d26c482490b3482a1b1f part as well, it's basically calculated as a xor of expected data and actual data it's written. Then, you'll also need to update the pointer I'm overwriting (0x1028A8 in my case, called ptr_send in brom-payload). Again, if executing under preloader it's gonna be completely different way to exploit it.

Any hint on how i would dump the bootrom? Also could you upload your boot-rom so I can compare once i got mine?

xyz` said:
Finally, if you want a persistent unlock (and not just the ability to modify /system) you'll need to port lk exploit as well. So you'll have to figure if your lk is vulnerable to the same bug, port microloader, inject_microloader.py and lk-payload to use the proper offsets. It's a lot of work.

Willing to put that work in

xyz` said:
I'll hopefully finish my writeup in the next weeks and post a link to it, that should be easier to understand since I'll explain the whole process from start to finish.

looking forward to your writeup.

xyz` said:
You're right about being able to load a custom preloader/lk, however the bootrom exploit requires a PC connection and a bunch of USB commands (so in a way, it's "tethered"). The actual unlock exploit isn't using any bootrom bugs, but rather the lk bug, since that one works without a PC. In fact, the bootrom exploit is only used to flash stuff to eMMC (but, of course you could probably do more fun stuff with it) in my chain.

I thought it might be possible to flash a preloader that exploits the same vulnerability, but from your explanation I assume that won't be possible.
For this device it would already be great to be able to overwrite RPMB to downgrade, since there was an LK that allowed booting into unsigned TWRP.

xyz` · Jan 28, 2019

k4y0z said:
Thanks for your quick reply.

I'm pretty sure I'm in boot-rom, my preloader actually has direct read/write using read_mmc.py but that has been fixed in newer preloaders, so I would rather go the boot-rom route.
Have you tried if pressing left (or both) volume buttons while pluging in brings you to brom-mode as well, like it does on my device?
I'll attach a serial to check for the output.

Yep, I've tried and it didn't work, though it could be device-specific. There are several additional ways preloader can force you into bootrom download mode, for example if preloader has an assertion and you hold volume down, it just deletes itself from emmc and next boot you'd be in bootrom mode (this doesn't work on hd 8 though as there's a bug in how it's set up); then there's some button checks that sets up a SRAMROM_USBDL which bootrom checks (but the code for the button check isn't present on Fire preloader). So unfortunately the only option that worked for me is shorting eMMC to ground.

k4y0z said:
Any hint on how i would dump the bootrom? Also could you upload your boot-rom so I can compare once i got mine?

This will be in the writeup, it's too long to explain here. I'm not sure if I can share my dump since technically it's copyrighted code.

k4y0z said:
I thought it might be possible to flash a preloader that exploits the same vulnerability, but from your explanation I assume that won't be possible.
For this device it would already be great to be able to overwrite RPMB to downgrade, since there was an LK that allowed booting into unsigned TWRP.

Well, we only can flash preloaders signed by amazon. If you have a preloader/LK combination that doesn't have signature checks that's great, you can use that.

xyz` · Jan 28, 2019

k4y0z said:
Any hint on how i would dump the bootrom? Also could you upload your boot-rom so I can compare once i got mine?

Also, here's what I used on my Fire 7:

Code:

def call_func(func):
    sdr_write32(0x11010804, 3)
    sdr_write32(0x11010808, 3)
    sdr_write32(0x11010C00, func)
    sdr_write32(0x11010400, 0)
    while (not sdr_read32(0x11010800)):
        pass
    if (sdr_read32(0x11010800) & 2):
        if ( not (sdr_read32(0x11010800) & 1) ):
          while ( not sdr_read32(0x11010800) ):
            pass
        result = -1;
        sdr_write32(0x11010804, 3)
    else:
        while ( not (sdr_read32(0x11010418) & 1) ):
            pass
        result = 0;
        sdr_write32(0x11010804, 3)
    return result


def hw_acquire():
    sdr_write32(0x11010000, sdr_read32(0x11010000) & 0xFFFFFFF0)
    sdr_write32(0x11010000, sdr_read32(0x11010000) | 0xF)
    sdr_write32(0x11010004, sdr_read32(0x11010004) & 0xFFFFDFFF)


def hw_release():
    sdr_write32(0x11010000, sdr_read32(0x11010000) & 0xFFFFFFF0)
    sdr_write32(0x11010000, sdr_read32(0x11010000) | 0xF)


def init():
    sdr_write32(0x11010C0C, 0)
    sdr_write32(0x11010C10, 0)
    sdr_write32(0x11010C14, 0)
    sdr_write32(0x11010C18, 0)
    sdr_write32(0x11010C1C, 0)
    sdr_write32(0x11010C20, 0)
    sdr_write32(0x11010C24, 0)
    sdr_write32(0x11010C28, 0)
    sdr_write32(0x11010C2C, 0)

    sdr_write32(0x11010C00 + 18 * 4, [0] * 4)
    sdr_write32(0x11010C00 + 22 * 4, [0] * 4)
    sdr_write32(0x11010C00 + 26 * 4, [0] * 8)


def aes_read16(addr):
    sdr_write32(0x11010C04, addr)
    sdr_write32(0x11010C08, 0) # dst to invalid pointer
    sdr_write32(0x11010C0C, 1)
    sdr_write32(0x11010C14, 18)
    sdr_write32(0x11010C18, 26)
    sdr_write32(0x11010C1C, 26)
    if call_func(126) != 0: # aes decrypt
        raise Exception("failed to call the function!")
    words = sdr_read32(0x11010C00 + 26 * 4, 4) # read out of the IV
    data = b""
    for word in words:
        data += struct.pack("<I", word)
    return data


def aes_write16(addr, data):
    if len(data) != 16:
        raise RuntimeError("data must be 16 bytes")

    pattern = bytes.fromhex("6c38d88958fd0cf51efd9debe8c265a5")

    # iv-xor
    words = []
    for x in range(4):
        word = data[x*4:(x+1)*4]
        word = struct.unpack("<I", word)[0]
        pat = struct.unpack("<I", pattern[x*4:(x+1)*4])[0]
        words.append(word ^ pat)

    sdr_write32(0x11010C00 + 18 * 4, [0] * 4)
    sdr_write32(0x11010C00 + 22 * 4, [0] * 4)
    sdr_write32(0x11010C00 + 26 * 4, [0] * 8)

    sdr_write32(0x11010C00 + 26 * 4, words)

    sdr_write32(0x11010C04, 0xE680) # src to VALID address which has all zeroes (otherwise, update pattern)
    sdr_write32(0x11010C08, addr) # dst to our destination
    sdr_write32(0x11010C0C, 1)
    sdr_write32(0x11010C14, 18)
    sdr_write32(0x11010C18, 26)
    sdr_write32(0x11010C1C, 26)
    if call_func(126) != 0: # aes decrypt
        raise Exception("failed to call the function!")

Try calling aes_read16(0) and see if it returns valid looking data (should start with "07 00 00 EA FE FF FF EA FE FF FF EA FE FF FF EA")

k4y0z · Jan 28, 2019

xyz` said:
Also, here's what I used on my Fire 7:
Try calling aes_read16(0) and see if it returns valid looking data (should start with "07 00 00 EA FE FF FF EA FE FF FF EA FE FF FF EA")

It seems to just hang with both aes_read16 and aes_write16.
It is probably related to the CRYPTO_BASE.
I tried finding the correct one here: https://github.com/chaosmaster/andr...ch/arm/mach-mt8127/include/mach/mt_reg_base.h

but didn't seem to find anything usefull (I tried CRYPTO_BASE = 0x1101B000, but that doesn't work either)

xyz` · Jan 28, 2019

k4y0z said:
It seems to just hang with both aes_read16 and aes_write16.
It is probably related to the CRYPTO_BASE.
I tried finding the correct one here: https://github.com/chaosmaster/andr...ch/arm/mach-mt8127/include/mach/mt_reg_base.h

but didn't seem to find anything usefull (I tried CRYPTO_BASE = 0x1101B000, but that doesn't work either)

So what you can do is download a firmware update for your device, load up the preloader in IDA (or a disassembler of your choice) and search for "hw sha". You should see it used like this: https://i.imgur.com/1PcObV7.png. Then inside that function https://i.imgur.com/wvpq5Qm.png the first call is essentially hw_acquire, then hash, then hw_release. Going further https://i.imgur.com/D5Z9UoM.png. So the base in my case is 0x10210000. You should figure out at which point it hangs, if it's inside one of the while loops, make sure you call init() and hw_acquire() first (it's not always required, seems to be hw-dependent)

hwmod · Jan 28, 2019

Porting the hack to Fire 7" 7th Generation

xyz` said:
So first of all make sure you're accessing bootrom mode and not preloader mode (Although if the preloader supports read/write, the exploit should work there as well, I just haven't tested it since on hd 8 8th gen none of preloaders support these). I suggest soldering on a UART adapter, then use 115200 baud rate. When in bootrom dl mode, you should see "[DL] 00000BB8 444C0005 010701" (basically, the "[DL]" part is the important one)

If it's a different soc, you will have to dump the bootrom and find the offset where range check data is stored (in my case, 0x102868). You might have to modify the 4dd12bdf0ec7d26c482490b3482a1b1f part as well, it's basically calculated as a xor of expected data and actual data it's written. Then, you'll also need to update the pointer I'm overwriting (0x1028A8 in my case, called ptr_send in brom-payload). Again, if executing under preloader it's gonna be completely different way to exploit it.

Once all this is done, you should be able to load binary payloads and execute them in bootrom mode. You'll also need to edit brom-payload and set up proper pointers to send_dword/recv_dword/etc, these can be found by reversing your bootrom dump. At this point it should be possible to get emmc read/write.

Finally, if you want a persistent unlock (and not just the ability to modify /system) you'll need to port lk exploit as well. So you'll have to figure if your lk is vulnerable to the same bug, port microloader, inject_microloader.py and lk-payload to use the proper offsets. It's a lot of work.

I'll hopefully finish my writeup in the next weeks and post a link to it, that should be easier to understand since I'll explain the whole process from start to finish.

You're right about being able to load a custom preloader/lk, however the bootrom exploit requires a PC connection and a bunch of USB commands (so in a way, it's "tethered"). The actual unlock exploit isn't using any bootrom bugs, but rather the lk bug, since that one works without a PC. In fact, the bootrom exploit is only used to flash stuff to eMMC (but, of course you could probably do more fun stuff with it) in my chain.

That was smart of you @xyz a genial solution.
You have proven that the "chain of trust" was a joke.
Many have said that what we were trying was impossible.

Did you realize on the 7" 7th Gen there are RST and EINT pads on the back of the photo I sent ?
Can we port your method to the 7th Gen by using RST instead of CLK to stop the MCU accessing the EMMC ?

Also the "watchdog" you disabled is on the RTC device of the MT6323 PMIC chip which in turn is on the I2C bus.
I can write to the I2C bus using a Bus Pirate v4, I already tried some write and seems I can do that too as an alternative.
Again the pads for accessing the I2C bus are on the back of the PCB of 7th Gen. tablets, they are labelled SCL2 and SDA2.

In a couple of week, or less, you have shown that Lab126 didn't deserve all that money for such a fake security mechanism.
I confirm that zeroing the "preloader" in "mmcblk0boot0" also forces the MCU to enter [DL] mode.
I was sure that investing time on the the [DL] mode would have paid back.

Again congratulation for the achievement and thank you for the time you have put on this.

.:HWMOD:.

xyz` · Jan 28, 2019

hwmod said:
Did you realize on the 7" 7th Gen there are RST and EINT pads on the back of the photo I sent ?
Can we port your method to the 7th Gen by using RST instead of CLK to stop the MCU accessing the EMMC ?

I haven't tried with RST. Try it and see if you get a "[DL]" message on uart, if you do then it should work.

hwmod said:
Also the "watchdog" you disabled is on the RTC device of the MT6323 PMIC chip which in turn is on the I2C bus.
I can write to the I2C bus using a Bus Pirate v4, I already tried some write and seems I can do that too as an alternative.
Again the pads for accessing the I2C bus are on the back of the PCB of 7th Gen. tablets, they are labelled SCL2 and SDA2.

Yeah, I haven't investigated the watchdog too much. I don't think there's anything interesting you can do with it though.

hwmod said:
In a couple of week, or less, you have shown that Lab126 didn't deserve all that money for such a fake security mechanism.
I confirm that zeroing the "preloader" in "mmcblk0boot0" also forces the MCU to enter [DL] mode.
I was sure that investing time on the the [DL] mode would have paid back.

To be fair to lab126 all of the fail lies solely on mediatek. The bootrom code amazon probably doesn't even have access to, and LK is likely based on mediatek sources (although, it's a really obvious bug in image loading, come on). The boot chain is reasonably secure in its design, it's only the implementation that's flawed.

k4y0z · Jan 28, 2019

xyz` said:
So what you can do is download a firmware update for your device, load up the preloader in IDA (or a disassembler of your choice) and search for "hw sha". You should see it used like this: https://i.imgur.com/1PcObV7.png. Then inside that function https://i.imgur.com/wvpq5Qm.png the first call is essentially hw_acquire, then hash, then hw_release. Going further https://i.imgur.com/D5Z9UoM.png. So the base in my case is 0x10210000. You should figure out at which point it hangs, if it's inside one of the while loops, make sure you call init() and hw_acquire() first (it's not always required, seems to be hw-dependent)

Sadly i don't have the IDA decompiler, so just assembler it is :/
I did however find the correct CRYPTO_BASE I believe:

Code:

CRYPTO_BASE = 0x11010000

that gives the following output with aes_read16:

Code:

b'\x07\x00\x00\xea\xfe\xff\xff\xea\xfe\xff\xff\xea\xfe\xff\xff\xea'

aes_write16 now fails with "RuntimeError: ERROR: Serial protocol mismatch".

Can i dump the boot-rom with this now?

NFSP G35 · Jan 28, 2019

First of all, congrats and big thanks!

So, any hope for the 2017 HD8?

xyz` · Jan 28, 2019

k4y0z said:
Sadly i don't have the IDA decompiler, so just assembler it is :/
I did however find the correct CRYPTO_BASE I believe:

Code:

CRYPTO_BASE = 0x11010000

that gives the following output with aes_read16:

Code:

b'\x07\x00\x00\xea\xfe\xff\xff\xea\xfe\xff\xff\xea\xfe\xff\xff\xea'

aes_write16 now fails with "RuntimeError: ERROR: Serial protocol mismatch".

Can i dump the boot-rom with this now?

Yeah, just go through all of the bootrom memory (0 to 0x20000, just to be sure, in 16 byte increments), call aes_read16 on it, concatenate everything and you'll get your bootrom dumped. It should end with a bunch of FF bytes so that's how you can tell the actual size.

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

Senior Member

Attachments

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Similar threads

Top Liked Posts