yashsingh1/xdaforums huggingface dataset:
[Fire Android Development] hwmod:
To answer to your question about AES-Keys I include a portion of the Fire / boot log:

[PART] load "8" from 0x0000000003960200 (dev) to 0xB8A00000 (mem) [SUCCESS]
[PART] load speed: 37106KB/s, 1063936 bytes, 28ms
[BLMTEE] sha256 takes 6 (ms) for 1063360 bytes
[BLMTEE] rsa2048 takes 118 (ms)
[BLMTEE] verify pkcs#1 pss: 0 (ms)
[BLMTEE] aes128cbc 8 (ms) for 1063360
[ANTI-ROLLBACK] Processing anti-rollback data

As you can see the log cites sha256, rsa2048, pkcs#1 pss and aes128cbc.

So I believe these are the types of keys and the crypto formats we have to look after in our quest.

.:HWMOD:.
[Fire Android Development] diplomatic:
The master AES keys that you're probably talking about are unique to each device. As far as I can tell, they never exist in RAM. They are only accessible to a hardware engine where you program some input data and get output data in return. But the CPU never actually sees the key. This is also true inside the TEE. While it may be possible to capture the device specific key(s) using some hack, I don't see much point in this. That's because you can, as root or system, legitimately ask the TEE to decrypt and encrypt whatever data you want. Not much point in hacking the TEE. For the relevant API info, see this library. What you may be able to retrieve by reading raw memory are secondary keys that are encrypted with the device specific key. Keys such as this could be DRM private keys, for example. Those ones do enter the RAM, albeit only in the private TEE space. But even in this case, you can probably write a program to use a legitimate API to do the crypto with those keys without ever needing to see them.
[Fire Android Development] hwmod:
Thank you for the information [MENTION=8132642]diplomatic[/MENTION] but then how could they extract those AES keys on the Qualcom platform ?

From the document I linked in my previous post #738 about the Qualcom case it is clear they achieved it and they also explained all the process they used.

Part of the details of the hack are described in another document linked atop of the above document and which I link also here:

Qualcom case #2: Trusted Zone privilege escalation vulnerability

Shortly in the above blog they say:

And here is a small extract from the boot log of our devices, just after calibration and initialization of our Fire devices and his Trust Zone activation:

[BLDR] jump to 0xB8A00000
[BLDR] <0xB8A00000>=0xE24F4008
[BLDR] <0xB8A00004>=0xE59F5420
[TZ_SEC][B]Start world switch from secure to non-secure world.[/B]
[GPIO] mt_gpio_set_default_chip: mt_gpio_set_default() done
mtk_wdt_mode LK config mode value=5d
mtk_wdt_mode_config LK mode value=10, tmp:22000010

This means to me that there is a bridge from "Secure World" to "Unsecure World" also on our devices and

that its functionality is most probably the same exact environment described in the linked Qualcom case.

This is what pushed me into try to compile the "LiME" module since that is the tool that transfers the complete

tablet memory on my Linux PC where I have power, memory and analysis tools to try out this idea.

I know you already said that this is highly improbable however please be patient and read the links I sent.

You surely have the knowledge and capabilities to support this effort, that's why I explicitly ask your help.

It is obvious there are no obligations but I recognize I don't have the needed knowledge and alone I will fail.

As I said I already have the needed module and tools compiled and ready to use, I tested them both

on the 5th Gen and 7th Gen versions of the FIre tablets, the module "lime.ko" can be loaded and works

even without "root" permissions and I have tested the complete RAM is transferred to my PC.

.:HWMOD:.
[Fire Android Development] DragonFire1024:
What can I do to help? I can use my HD 8, no root and of course my HD 10, with root. I'll look at your links when I'm done with work.

---------- Post added at 12:25 PM ---------- Previous post was at 12:17 PM ----------

I've nothing to do in terms of devices right now anyway. Without a means to successfully flash the system on the HD 10, aside from an extracted img from the device itself, I'm pretty much stuck with nothing to do.
[Fire Android Development] hwmod:
If you have a device with kernel version 3.10.54+ you can probably be able to also use the "LiME" module I compiled.

If not, I need to know the kernel version your device uses, download those kernel source and recompile the module for you.

If you can compile the "LiME" module yourself then follow the instructions on the "LiME" repository on how to load the module.

Be patient, this evening I will have the time to upload both the "LiME" module and the "aeskeysearch" for Linux for you and others to try.

.:HWMOD:.
[Fire Android Development] DragonFire1024:
I'm pretty sure it's the same kernel version. I don't recall a change in the version at least from the 8 to the 10.
[Fire Android Development] wolf45801:
So we are close on rooting the 7th gen fire 7?
[Fire Android Development] Rortiz2:
Yes and no.

To root fire 7 7th gen, it is necessary to adapt the kernel of the 5th gen which is what is working [MENTION=4381075]hwmod[/MENTION] or so I think. But you need to remove the shield that protects the EMMC and it is soldered. I have made a hole with a knife (not recommended) for short the bootrom point. So we're a little ****ed up.

Best regards
[Fire Android Development] wolf45801:
Yeah I'm aware of the sheild being soldered on I have a dremmel I might be able to cut it open
[Fire Android Development] DragonFire1024:
This seems like an awful lot of work that went into stopping entry to these points of the device. I've seen higher-end cell phones with less 'protection'. Maybe Amazon did know about the exploit or the possibility of one being possible. It seems that generation of the tablets has the most shielding and less of it is added as the devices got newer. or perhaps they thought nobody would exploit them and stop placing the shield over the top of the test points or at least stopped soldering them and switched to glue. I currently have all of my fire tablets open with the exception of my daily driver and that looks like it could be the case.
[Fire Android Development] diplomatic:
OK, if you're talking about Android keymaster keys (which I called secondary keys before), those may be able to be extracted in theory. But the hardware unique keys that are burned into the chip with which the keymaster keys are encrypted, those never enter the RAM. I'm not saying it's impossible to see the hardware key, but you won't get it by dumping the RAM. That blog post on the Qualcomm keys even says as much. In addition, be aware that the secure memory is not visible outside the TEE. That's sort of the whole point of the secure world. So you might have trouble reading it from the kernel.

But what is your goal in all this? You know the TEE has nothing to do with boot image signatures or unlocking or any of that stuff, right? That's done purely in software. The most useful thing I see that this could be used for is cracking Android disk encryption. Indeed, that is the focus of the blog post...

And of course there's a bridge between the normal world to the secure world. The OS must interact with the TEE for it to be of any use. The kernel has a driver that does just that. For userspace applications (keymaster, mediaserver, etc), the UREE library that I mentioned provides the API to this driver.
[Fire Android Development] k4y0z:
Just a little teaser for you guys ;)

(bootloader) max-download-size: 134217728
(bootloader) partition-size:userdata: 17329be00
(bootloader) partition-type:userdata: unknown
(bootloader) partition-size:cache: fa00000
(bootloader) partition-type:cache: unknown
(bootloader) partition-size:system: 4b000000
(bootloader) partition-type:system: unknown
(bootloader) partition-size:TEE2: 500000
(bootloader) partition-type:TEE2: unknown
(bootloader) partition-size:TEE1: 500000
(bootloader) partition-type:TEE1: unknown
(bootloader) partition-size:LOGO: 380000
(bootloader) partition-type:LOGO: unknown
(bootloader) partition-size:MISC: 80000
(bootloader) partition-type:MISC: unknown
(bootloader) partition-size:recovery: 1000000
(bootloader) partition-type:recovery: unknown
(bootloader) partition-size:boot: 1000000
(bootloader) partition-type:boot: unknown
(bootloader) partition-size:UBOOT: 100000
(bootloader) partition-type:UBOOT: unknown
(bootloader) partition-size:EXPDB: 1160000
(bootloader) partition-type:EXPDB: unknown
(bootloader) partition-size:DKB: 100000
(bootloader) partition-type:DKB: unknown
(bootloader) partition-size:KB: 100000
(bootloader) partition-type:KB: unknown
(bootloader) off-mode-charge: 1
(bootloader) secure: yes
(bootloader) kernel: lk
(bootloader) product: FORD
(bootloader) version: 0.5
[B](bootloader) unlock_status: true[/B]
(bootloader) unlock_version: 1
(bootloader) unlock_code: 0x3ae2b78fe7b23869
(bootloader) prod: 1
all: Done!!
finished. total time: 0.004s
[Fire Android Development] DB126:
Don't be ridiculous. Shielding is typically put into place for emissions certification or heat dissipation. Whomever Amazon sourced the components from likely opted for the assembly method due to manufacturing capability, lowest cost or some other efficiency. I doubt it was a proactive move by Jeff B. to thwart the miniscule modder community relative to total sales. Hardy lol.
[Fire Android Development] DragonFire1024:
Just stating the work looks better on earlier versions.
[Fire Android Development] DragonFire1024:
So I have a scatter file for the HD 10. The rest comes in the update.bin. I need an authentication file in order for SP flash tool to work. However, the fact I can even get the program to recognize the device now is huge, and it lasts for longer than the 17 seconds I discovered while fooling around with the ACM drivers. Which by the way, aren't just ACM drivers, it's all mediatek drivers. I found a link that contains some commands that we can try out, and are supposed to be universal amongst the chipset. I just have to find the bookmark. My point is, now that we are at this elevated status, there has to be something else we can do now.
[Fire Android Development] Rortiz2:
[MENTION=4381075]hwmod[/MENTION] any updates about the 7th gen?
[Fire Android Development] DragonFire1024:
Here you go:

http://www.lieberbiber.de/2015/07/02/mediatek-details-soc-startup/
[Fire Android Development] tonibm19:
Does that mean unlocking for fire 7 2015? :DD
[Fire Android Development] k4y0z:
Yes, in the same way it has been achieved for the HD8.

So not a real unlock, but it will still let you flash twrp/custom kernel and boot it :)

Not quite done yet though.
[Fire Android Development] hwmod:
[MENTION=8978978]Rortiz2[/MENTION], no ! Except for the "recovery.img" extraction and the new VDD1 pin location to short on 7th Gen tablets I have no other news.

Attached here the LiME module that can be loaded on "rooted" tablets to try finding keys in MEMORY (contains a quick howto text).

Includes an "aeskeyfinder" but once we have the complete 1GB ram on our PC we can use also other tools (like binwalk, john and similar).

Please read the docs at the original "LiME" repository.

Also for "aeskeyfinder" there is an inline help that can be shown by typing the command without passing parameters and it is really simple to use.

.:HWMOD:.

---------- Post added at 08:10 PM ---------- Previous post was at 08:05 PM ----------

WOW ! Awesome [MENTION=7104332]k4y0z[/MENTION], congratulation again for the new achievement.

If you can share a testing code I can quickly try on the 7th Gen tablet and give feedback.

Until now what was working on the 5th Gen showed it could work the same also on the 7th Gen.

Crossing fingers and hoping it will work.

.:HWMOD:.
[Fire Android Development] k4y0z:
It's not ready yet, still have to work out some quirks.

Also still have to find a way to reliably boot the newest boot.img, since I'm using the 5.0.1 LK.

But when it's done we can hopefully modify the boot.img to work correctly, since it doesn't matter if we break the signature.
[Fire Android Development] Rortiz2:
Ok, so I will wait because in ended trying to remove the shield and I screwed the screen and I had to go to a store to change it and I told them also remove the shield.

PS: I'm glad that someone like you has the 7th gen :). I'm sure you'll get to root it.

Sorry for my English.
[Fire Android Development] hwmod:
Whenever you believe it can be tested out on 7th Gen. Thank you !

On another theme, we know that for each of the PRELOADER, LK (UBOOT), BOOT & RECOVERY we have more than 3 times the space necessary to hold each of them in the EMMC.

With the ease granted by these new hacks, yours and [MENTION=9667509]xyz`[/MENTION] one, and the fact its possible to override pointer refs and attach payload do you think it is possible for example

have two different "boot.img" loaded in the BOOT partition, or two "recovery.img" loaded in the RECOVERY partition and the same for the LK & PRELOADER ?

Wouldn't that make easy loading/using the second cop and leave the first copy to trick the original PRELOADER into believe everything is OK/signed ?

Just a strange thought I had, but all that wasted space could maybe be used in a more profitable way.

.:HWMOD:.

---------- Post added at 09:37 PM ---------- Previous post was at 08:37 PM ----------

[MENTION=8132642]diplomatic[/MENTION], thank you so much for your answer and support. However it seems @4ky0z was able to find the solution before I even try my path,

also, I have shared the "lime.ko" module and the "aeskeyfind" utility should you wish to give it a try and tell me if it could work as it is to do what is

described in the Qualcom case blogs you have read. I definitely trust in your knowledge about crypto and related stuff.

Well the goal in all this was to be able to load whatever OS one wishes on these tablets and be as simple as loading a firmware in the EMMC through the normal "fastboot" utility.

I would also have been able to boot from an external SD Card or from an OTG device and much more but first option above would have been enough.

However I was not interested into having the hardware key of the Mediatek SoC we have seen that with a simple short of a pin we can actually load whatever we wish as the first bootloader, or am I wrong ?

If I understand correctly, the hack from [MENTION=9667509]xyz`[/MENTION] on the HD 8 is also capable of replacing the functionality of the BootROM by running a modified copy of it in SRAM.

.:HWMOD:.
[Fire Android Development] bibikalka:
Hand edited !!! :D Release your secrets at once to prove !!! :D
[Fire Android Development] diplomatic:
Yeah, with a lot of work, I think having multiple boot "slots" is possible. You could even repartition the storage and put the alternative boot images into their own partitions.

I don't think the scrutinizing the TEE is the right way to achieve booting alternative images. Like I said before, the TEE is not involved in verifying images or in BL unlock. I guess there's a misconception that anything on an Android device that's related to cryptography must have the TEE involved in it. That's not even close to accurate. Mostly, the secure world is used for stuff related to the security of data on your individual device. It is not used to verify software or data that came from somewhere else (e.g. the vendor).

I guess you can do a lot of stuff with the bootrom hack in theory. But it would only work when you do the pin short and bootstrap it from your computer.
[Fire Android Development] hwmod:
Yeah, with the efficient hacks we already have we should probably leave the TEE stuff and cryptographic attack as a last alternative in case these new hacks should fail.

While you may be right about the TEE as you explained above I believe the pin short method is only necessary once to get "root" permissions the first time.

Once we have achieved "root" we can simply overwrite code directly into any partition and force the BootROM into entering download mode [DL].

From very cursory test I did, one way is by zeroing out the "PL" or the "LK" partitions. In that way the tablet automatically enters download mode.

By the way this "unbreakability" will entitle and push developers to try more exotic route and maybe obtain a software only "root".

A software only "root" will then render obsolete the need of a first time pin shorting to GND and related shielding removal.

Everybody could then do that themselves with no risk to destroy their hardware.

.:HWMOD:.
[Fire Android Development] DB126:
Yep - if/when that is acheived this 'hack' will appeal to a much broader audience moving from the hyper-niche to niche community or perhaps the common gizmo enthusiast.
[Fire Android Development] bibikalka:
Can you explain a bit more about the part in bold??? Which tablet did you do that with ???

I have Fire HD 6 where I can zero out TZ/LK via aftv2-tools, so your approach could be game.
[Fire Android Development] hwmod:
Making the hack easier and safer

Yeah ... it works as one would expect ! :victory:

The tablet is not really bricked it is just missing the software, the OS ... but that is just temporarily.

If we can avoid to much fiddling with pin shorting or literally sawing the PCB the solution will be more accessible.

I performed the tests with both 5th Gen and 7th Gen Fire 7 tablets obtaining exactly the same results.

I created three files filled with zero by 'dd if=/dev/zero of=<filename> bs=1024 count=<numberofblocks>':

* "preloader.bin" of 4096KB size

* "lk.bin" of 4096KB size

* "tz.bin" of 512KB size​

I used the full available space of each partition of the EMMC and then wrote these three files by replacing existing files having the same name in the "bin" folder of the "amonet" utility/hack by using the "pin shorting" trick.

The process didn't complete and stopped after writing "preloader.bin" and "tz.bin" with the following error:

Traceback (most recent call last):
File "main.py", line 128, in <module>
main()
File "main.py", line 74, in main
switch_boot0(dev)
File "main.py", line 14, in switch_boot0
raise RuntimeError("what's wrong with your BOOT0?")
RuntimeError: what's wrong with your BOOT0?

The reason for this error is that in "main.py" there is a check on the 'BOOT0' partition after it is written but the check fails since the partition was completely wiped (filled with zero).

So my friends I am sure the trick works perfectly. After that I was able to revive the temporarily non working tablet by repeating the procedure and rewriting the wiped partitions with the standard "preloader.bin" and "tz.bin".

The only thing to watch out is that the check for the 'BOOT0' partition should be disabled to allow unconditional writing of the partitions, be it empty or not, maybe substitute the exception with just a warning.

It is safe to try this out, I did that twice, the only change required is commenting 4 lines (in bold) almost atop of "main.py" in "switch_boot0(dev)" function, which does a "preloader.bin" partition validation:

import struct

from common import Device
from handshake import handshake
from load_payload import load_payload
from logger import log

def switch_boot0(dev):
dev.emmc_switch(1)
block = dev.emmc_read(0)
[B] #if block[0:9] != b"EMMC_BOOT":
# print(block)
# dev.reboot()
# raise RuntimeError("what's wrong with your BOOT0?")[/B]

Happy hacking !

.:HWMOD:.
[Fire Android Development] retyre:
So, you're saying it's possible to enter bootrom mode -- without having to open up the device -- by writing a zeroed-out preloader.bin ... in bootrom mode (which you enter by ... shorting pins ... after opening up the device)?

You shouldn't have to tinker with lk or tz. Just corrupt the preloader with any junk file and it should drop you to bootrom mode.
[Fire Android Development] DragonFire1024:
Might not be a good idea. Anyone recall what happened when I flashed something I shouldn't have? I still haven't been able to recover that tablet.
[Fire Android Development] hwmod:
Have somebody tried to use version 5.1.1 of "preloader.img" instead of "preloader_prod.img" to overwrite the original "/dev/block/mmcblk0boot0" boot partition ? The "preloader.img" file is for "unsecure" devices as one can read in the "updater-script" sources of the original Amazon update packages (in the META-INF/com/google folder).

If that has not been tried before maybe someone is willing to test using the following command:

dd if=preloader.img of=/dev/block/mmcblk0boot0 bs=512

This command should be executed on a "rooted" device while connected as SU through the ADB shell.

I must warn potential testers that this operation could potentially "brick" the tablet.

I have read in this forum that people have more than one tablets in their hands and that some are willing to try.

I would try myself on my tablet but I only own one Fire 7 and if I "brick" that one I would have to stop my current investigation.

.:HWMOD:.
[Fire Android Development] Awesomeslayerg:
I'll try it
[Fire Android Development] Awesomeslayerg:
Is it possible to switch to uart mode?
[Fire Android Development] Tomsgt:
did you try the command for preloader yet?
[Fire Android Development] Awesomeslayerg:
Give me about a few minutes i just reflashed the stock firmware.
[Fire Android Development] Tomsgt:
ok cool i am working on my devices now
[Fire Android Development] Awesomeslayerg:
So i update my devices to 5.1.2 then i do the command or what?

---------- Post added at 11:55 AM ---------- Previous post was at 11:41 AM ----------

Alright guys im gonna try generating a scatter file from 5.1.2 So it should be easier to recover from a bricked device
[Fire Android Development] Awesomeslayerg:
I get operation not premitted and i am root.
[Fire Android Development] Kramar111:
It's already published here by [MENTION=4381075]hwmod[/MENTION] http://xdaforums.com/amazon-fire/de...lock-ideas-t3289721/post66315243#post66315243

but sys0 scared me :)

---------- Post added at 00:09 ---------- Previous post was at 00:00 ----------

put this command before dd

adb shell "echo 0 > /sys/block/mmcblk0boot0/force_ro" (if you have temporary root)

or

adb shell su -c "echo 0 > /sys/block/mmcblk0boot0/force_ro" (if you have permanent root)

but your been warned

even with "8GB access" you didn't have access to this part of memory later if system not boot (as i know)
[Fire Android Development] Awesomeslayerg:
And bricked didnt work. Its okay i have another fire :P
[Fire Android Development] hwmod:
OK ! I have got enough feedback from the test on the "preloader" partition I asked to execute in my previous post.

Don't try to write the "preloader.img" over the original "preloader_prod.img" on /dev/block/mmcblk0boot0.

It will surely "brick" the device, most probably in a worst way than trying to downgrade to older versions.

However, thanks to Kramar111 and Tomsgt, we have two methods to overwrite a protected partition (preloader).

The first method is described by Kramar111 in his post #69 above, that seems the most elegant method to do.

The second method (tested on a "rooted" 5.1.2) works by installing "busybox" and then issuing the command:

busybox cat preloader.img > /dev/block/mmcblk0boot0

.:HWMOD:.