yashsingh1/xdaforums huggingface dataset:
[Fire Android Development] DragonFire1024:
Speaking of aboot, I came across a PDF paper discussing oem codes and aboot and how to unlock a locked bootloader using oem codes and fastboott. He managed to find a few to work. https://www.usenix.org/system/files/conference/woot17/woot17-paper-hay.pdf
[Fire Android Development] Supersonic27543:
I don't think that the OEM commands will work, because I disassembled the bootloader and there weren't any special OEM commands, and OEM unlock is specifically removed. The list is,

fastboot oem relock - only command that works, others can't run because locked hw

fastboot oem p2u

fastboot oem off-mode-charge

fastboot oem idme

fastboot oem flags
[Fire Android Development] DragonFire1024:
Those aren't in the paper if I recall. And I'm pretty sure those aren't what he used.

---------- Post added at 11:51 AM ---------- Previous post was at 11:43 AM ----------

He used this tool to get a list of codes https://github.com/alephsecurity/abootool
[Fire Android Development] Supersonic27543:
Yes, that's why we can't use them. I already studied that specific paper, and, Amazon removed all existing OEM commands and created their own OEM commands.
[Fire Android Development] DragonFire1024:
HAve we figured out what's rooting the HD 10 yet?
[Fire Android Development] Supersonic27543:
Yes. CVE-2016-5195 kernel vulnerability, aka DirtyC0W.
[Fire Android Development] DragonFire1024:
I've tried to get logs of it and either I'm reading it wrong, or the logcat freezes. But I do see references to the kernel. I don't have to reset at the moment, though in the next day or two I plan on again testing a ROM. This one should work and if it does will be 100% pure AOSP.

---------- Post added at 01:19 PM ---------- Previous post was at 01:17 PM ----------

Beat me to the punch.

---------- Post added at 01:30 PM ---------- Previous post was at 01:19 PM ----------

So devo mode. It seems it has to do with allowing full sdk access without root. The servers look to set your device to aws which is Amazon's cloud developer portal. Aws costs big bucks so unless someone has a log in I can use, that's not an option. Question is, would this work in Android studio the same way? I know a few of you looked inside the APK. Are there Android addresses we can replace the amozon ones with if I were to edit the APK? If not I am almost sure the full access we get isn't possible without aws access.

Edit: I'm almost sure this also won't work with OTA disabled. It appears when you activate Devo mode the device needs one of the OTA files or both in order to perform any updates you make to the device via the aws portal.
[Fire Android Development] DragonFire1024:
These are present on the Fire 7, HD 8, HD 10 in /system/bin and can be launched with root. I haven't tried to use them other than telling them to spit out information. I will let you guys draw conclusions. ;) https://xdaforums.com/showpost.php?p=77191065&postcount=472
[Fire Android Development] DragonFire1024:
I came across this article, which is just about the only thing I could find that made a direct mention of 'AMZN_DHA', but doesn't talk much about it specifically.
[Fire Android Development] DragonFire1024:
What if amzn_dha_tool = Amazon Device Hardware Authentication Tool?
[Fire Android Development] hwmod:
Good findings pal. That's a bit of help to let the research continue.

I wanted to add a couple of information that might be of help too.

In /system/bin/ I also found other commands probably related with your findings these are: amzn_dha_hmac and amzn_drmprov_check.

Again in /system/bin/ there are also: keystore and keystore_cli. Running these command in rooted tablet produces errors because libraries are missing.

In a locked tablet the needed libraries/modules are located in /system/lib/hw and the relevant files we need are:

amzn_dha.mt8127.so, amzn_drmprov.mt8127.so, keystore.default.so, keystore.mt8127.so

After copying these libraries to my other rooted tablet in the same folder I can run these commands as "root", the standard "shell" user cannot execute them. The results are the same of those you showed. The interesting thing I noticed is that the "SoC serial" obtained by running "amzn_dha_tool -d" is the same hexadecimal number that one can retrieve using "fastboot getvar all", also the number obtained by "fastboot" is called ""unlock code" :) :) :)

So I believe we got a step further in the right direction.

Have fun,

.: HWMOD :.
[Fire Android Development] t3chwizard:
Woot woot
[Fire Android Development] DragonFire1024:
This being the case, further research indicates a good possibility the key(s) have been backed up to dev/block/platform/soc/by-name in KB or DKB . I found some logs from older amazon tablets that say some of the things I see in these files, including backing up keys to a "shadow box" in that by-name. https://xdaforums.com/fire-hd/development/persisbackup-partition-t3422156 also, the two amzn files are present, and I believe the keystore is too...on the HD 10 at least
[Fire Android Development] DragonFire1024:
I think I am right. Though not in KB or DKB. I copied KB, DKB, LK, and TEE1 to storage. I couldn't see anything in all but one: /dev/block/platform/soc/by-name/lk

There are signatures/certificates present in that partition. At least two. And it goes on further. This is going to be a long .zip but I think we have it. I really think we might. You'll be be able to use notepad++ to read some of it. Attached a zip of LK and zip of screenshots. This has fast boot commands and mentions preloader and other important OEM stuff. Even talks about mtk images.
[Fire Android Development] DragonFire1024:
On the HD 10, the last security patch was in 2017. Right around the time android issued a patch for a loophole in nexus 6. Who wants to bet amazon didn't patch it? The HD 10 is based off the nexus 6 LVY48F. You can find the images on googles factory image site. I just found an article explaining cve-2016-10277. Now here's where its interesting. I can edit the framework-res and there is a config that has bp tools missing. I can add the config, which is missing, successfully. Does it work? No idea. Has to do with USB OEM. This article contains contains a lot of the lk.zip in my last post. I mean everything. Given there are engineering and production certificates present in the LK, then we probably don't need this exploit. https://alephsecurity.com/2017/05/23/nexus6-initroot/
[Fire Android Development] DragonFire1024:
Well I pulled /dev/block/platform/soc/by-name/boot0img0 and boot0img1 and the files say some specific things. I'm fairly certain LK contains the private key(s) and that the boot imgs look to the LK to verify engineering and production keys, and pass...unlocking the device.
[Fire Android Development] ldeveraux:
Wait... what??
[Fire Android Development] DragonFire1024:
See screen shots in last post and a few back. There are two keys in dev/block/platform/soc/by-name/lk. Engineering and production certificates both are Lab126. The /dev/block/platform/soc/by-name/boot0img0 and boot0img1 both look to the LK to verify those two certificates. I believe our keys to unlock are in the LK
[Fire Android Development] ldeveraux:
Yes, I see, but can we access them?
[Fire Android Development] DragonFire1024:
I do not know. There are two sets of numbers that contain one letter within them, the letter Z. I don't know what they are, but they maybe the keys themselves. We might just have to input those numbers. If these are the keys, I have no clue how to get them or if we need to. Someone with a bit more knowledge on this will have to answer. [MENTION=4267571]sd_shadow[/MENTION]?
[Fire Android Development] Jaytn:
I'm definitely not someone with more knowledge, but this seems weird to me. Why would they put the private keys on the device? That defeats the whole purpose of asymmetric cryptography, does it not? Should they not rather be the public keys?

If anything, I am curious as to how you come to the conclusion that they are the private keys?
[Fire Android Development] DragonFire1024:
Signed by Lab126, with "common kernel engineering and production" certificates (quoted directly from the LK). Sounds pretty private to me. Most of the files I reference do talk about a public key, but don't reference it to being anywhere in these partitions. Any public key it mentions refers to the already known test key found in /vendor. Secondly, the boot imgs specifically refer to verifying these two particular keys in LK, post test key verification, (test key/public key verification can be seen in the library files which then reference the keys or the backing up of keys in the LK in a "shadow box". Thats also quoting the library files).
[Fire Android Development] hwmod:
Also with the standard ADB it is possible to extract another pair of keys (a private key and its related public key). The command to do that is:

adb keygen <filename>​

The above command will generate a private key in <filename> and a public key in <filename>.pub and save them in the current folder.

Not sure what is the scope of each key but the more keys we have the more we can compare and distinguish them.

To try to "unlock" the bootloader using "fastboot" we must first put the needed key in a <file> and then issue the command command:

fastboot flashing unlock <file>​

so the key is not passed in-line to "fastboot" but store in a <file> that "fastboot" can read from current directory.

Have fun,

.:HWMOD:.
[Fire Android Development] Supersonic27543:
Looking at the reverse-engineered LK blob, it looks like Amazon cut off the functionality of "fastboot flashing unlock" and made their own command "fastboot flash unlock", so I guess our best bet is that. If you send a dummy file with that command it says "unlock code error".
[Fire Android Development] DragonFire1024:
Indeed. But has it ever come across the screen of the tablet before?
[Fire Android Development] Supersonic27543:
Yes, just reboot to fastboot and try "fastboot flash unlock dummyfile.whatever" It will display on the tablet.
[Fire Android Development] DragonFire1024:
I just noticed it today it come across the tablet's screen today.

It said USB transfer. Transfer complete or ok (can't recall immediately) then unlock code error. I placed a private key generated by ADB in a file titled dragon.txt and dragon.bin.
[Fire Android Development] Supersonic27543:
Also, keys generated by "adb keygen" are just the fingerprints for verifying an ADB authorized PC I think.
[Fire Android Development] DragonFire1024:
So close yet so far.
[Fire Android Development] t3chwizard:
So no unlock? Man you guys got me all excited
[Fire Android Development] DragonFire1024:
Not entirely true. It did something...no one's ever seen before. So we don't know what the information means.
[Fire Android Development] hwmod:
Obviously, they are not the master key to unlock the boot loader, still they may be generated by the same keystore system.

We might learn something by comparing these keys with those included in "preloader.img" and "lk.img".

.:HWMOD:.
[Fire Android Development] t3chwizard:
Wooot still hoping for some results for from all the hard work you guys have put into this. Keep it up!!
[Fire Android Development] DragonFire1024:
I'm back with a new HD 10 :)
[Fire Android Development] DragonFire1024:
There is a property 'Settings database Editor' spits out related to the amzn_dha tool:

ro.amzn_dha.hmac

It has a very large value set:

003f9267ce02688167f481fc265633c52cbd95b58ac30e9ab9577ba2951f8db4

I figured out what the dha_tool does, but still no idea what 'hmac' is.
[Fire Android Development] armada786:
Probably a hash-based message authentication code. Basically, it's used to authenticate a encrypted value by having a valid hash to compare to, though that's just my surface level understanding.
[Fire Android Development] DragonFire1024:
So I looked at lk on my HD 10. Found a few mentions of fastboot with some oem commands (I know we don't have an aboot). I also know we can't use those commands. However, I decided to try the command I found (oem reboot-bootloader) like so while in fastboot:

fastboot -c oem reboot-bootloader

The -c is supposed to override the kernel command line. And well it worked. At least it rebooted back to fastboot. Whereas fastboot oem xxx wouldn't work without -c. Is this something new?
[Fire Android Development] DragonFire1024:
Also there was at least one mention of uboot.
[Fire Android Development] hwmod:
Keys extraction example

DragonFire1024,

you can use the "binwalk" command to find and extract these keys from the "lk.bin" file (UBOOT).

This command is available for every OS you may have, is very powerful and it is very easy to use.

If you just pass one argument to it, the name of the file, then it will just scan the file and tell you the various types of chunks it finds in the specified file.

If you pass "-e" as argument before the file name it will extract the various components it finds, the following is an example of output using "lk.bin" from FireOS 5.4.0:

[SIZE="1"]
[root@ns AUSTIN]# binwalk -e lk.bin

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
89824 0x15EE0 SHA256 hash constants, little endian
311992 0x4C2B8 Android bootimg, kernel size: 0 bytes, kernel addr: 0x67616D69, ramdisk size: 1936269413 bytes, ramdisk addr: 0x746F6E20, product name: " large"
314176 0x4CB40 Unix path: /home/local/ANT/qanliu/develop-projects/maindev/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/cryp
314780 0x4CD9C Unix path: /home/local/ANT/qanliu/develop-projects/maindev/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/mem_
318212 0x4DB04 Unix path: /home/local/ANT/qanliu/develop-projects/maindev/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/asn1
319176 0x4DEC8 Unix path: /home/local/ANT/qanliu/develop-projects/maindev/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/bio/
323828 0x4F0F4 Unix path: /home/local/ANT/qanliu/develop-projects/maindev/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/evp/
324932 0x4F544 Unix path: /home/local/ANT/qanliu/develop-projects/maindev/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/obje
334152 0x51948 Unix path: /home/local/ANT/qanliu/develop-projects/maindev/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/x509
335792 0x51FB0 Certificate in DER format (x509 v3), header length: 4, sequence length: 1069
336888 0x523F8 Certificate in DER format (x509 v3), header length: 4, sequence length: 1067
442308 0x6BFC4 CRC32 polynomial table, little endian
[/SIZE]

As you can see there is an "SHA256 hash" at the beginning of the file and there are two "(x509 v3) certificates" in DER format almost at the end of the file.

By using the "openssl" command one can convert those binary format certificates to "PEM base64 encoded" format or to other needed formats.

Also I doubt they can be used straight away like this. They probably need extra steps (encoded, encrypted or signed) using the "Modulus" and "HMAC" returned by the "amzn_dha_tool -d" command you described above.

In the FireOS sources there are probably scripts to automate the full process used to generate public and private keys. Hopefully we don't need the RSA master key, maybe the related public key is enough for the unlock.

Have fun.

.:HWMOD:.
[Fire Android Development] hwmod:
Fire 7 5th Gen Contacts Points for flashing the EMMC

The attached picture is from the mainboard of my Fire 7 5th Gen tablet reporting the board connections that will allow to program the Samsung EMMC 8GBbytes flash containing the tablet firmware.

This is not a bootloader hack, it is an hardware alternative to get "root" permission on the device and might be of help finding other software method to gain "root" access and install custom ROMs.

I will still consider this a POC and the information here in and in the picture have to be reviewed and confirmed by other professional before considering them correct and functional to the task.

For these reasons you should also consider this as a WORK IN PROGRESS. I would prefer to find contact points on "resistors" (like I did for the "CLK") instead of using these thin and fragile "pads".

So please, wait a few weeks, read documentation and help with corrections and suggestions. I will do my best to improve these findings and try to give advices to avoid ruining your board.

You should at least read the following web page and go through the links contained there:

Exploitee.rs - Interfacing_with_e-MMC_Storage_Devices

This PDF, is a generic explanation of the approach used to perform the suggested hardware modifications to flash the e-MMC and get "root" permissions:

BH2017-Hacking-Hardware-With-A-10-Reader-wp.pdf

I will not be held responsible for any damage you may cause to your tablet or any property of you, your family or your friends.

If you don't have professional soldering tools or if you don't have the skills think twice before taking a soldering session with your PCB.

It is almost sure you will damage the thin pads, at least I can say I ripped two of these pads and that Fire main board is not working anymore.

So be prepared for a burning defeat. I understand your tablet is already a "brick" so things cannot be made worst by these soldering attempts.

Unfortunately Amazon is not willing to release the boot-loader unlock procedure to help customers revive their tablets so this is our last resort.

If you still feel you can do it and are willing to spend some more money to achieve your goal here is what you have to connect to these contact points:

Low Voltage eMMC Adapter (Fully Assembled)

And this is the Trascend USB Adapter they suggest to use due to it's rare capability to work with as few as only 1 data wire (DATA 0):

Transcend USB 3.0 SDHC/microSDHC Card Reader TS-RDF5K

I am not part of the Exploitee.rs company nor have any economic interest in what they do and sell.

However there are some good people working there and their achievements have been amazing.

Have fun,

.:HWMOD:.
[Fire Android Development] k4y0z:
I have done some further analyzation of the LK and found that there seems to be a factory-mode which loads and boots a factory.img from sd-card.

It's possible this mode can be activated using a factory-cable and putting a signed image to sd-card/factory.img.

It might additionally be necessary to hold the button-combination for either fastboot or recovery.

Can't currently test this, since I don't have a working factory-cable at hand.

I also looked at the unlock-procedure.

From what I understand the file that needs to be flashed for unlocking (fastboot flash unlock <signed unlock_code.bin>.) is just the rsa-signed/encrypted unlock_code that can be obtained through i.e. "fastboot getvar all".

Now if the signature uses the same key that is used for signing images maybe we could just take the signature from any image and overwrite the unlock_code with the hash that has been signed there.

We will have to find where the unlock_code is stored and if we are able to overwrite it.

I have also tried modifying the read_mcc.py from aftv2-tools to try reading the preloader by changing the BASE_ADDR from 0x11230000 to 0x11240000. However this just results in "Command Timeout", there might be more modifications necessary.

Just wanted to throw in these thoughts.
[Fire Android Development] DragonFire1024:
I have several cables that came with my tablets. If those are the proper ones, I'm already one step ahead. What's next?
[Fire Android Development] k4y0z:
By factory-cable I meant something like this:

https://xdaforums.com/showthread.php?t=1392693

With that (maybe together with some button-combination) and a boot-image on sdcard/factory.img it should load the image.

This probably won't help with unlocking (unless it also accepts unsigned images) but at least it could help people who have bricked their recovery-partition.
[Fire Android Development] DragonFire1024:
I'm working on a theory today and tomorrow that may allow for unsigned bins and zips to be adb sideloaded in recovery. Secondly, I'm still convinced the amzn_dha_tool is how they unlocked the device. What if we don't need a code. Just the one that matches the device's? What if the tool knows where the code is and all we need is the other half to give to the tool? We do know it generates the same code as getvar all in fast boot (the alleged unlock code). So I'm still convinced this tools usefulness is being underestimated.
[Fire Android Development] k4y0z:
That sounds interesting, although even if you are able to sideload-flash, it still won't boot, since the bootloader checks the signatures. Unless you're able to only flash an unsigned system to use a custom ROM

Unless the tool contains the private-key I don't think this will work.

I have looked at the unlock-procedure and as I understand it it does the following

- convert the unlock.bin (maybe from PEM to DER or similar)
- decrypt unlock.bin using public key
- compare decrypted unlock_key with the one from getvar

I have attached a flow-graph of the unlock-procedure from IDA, the names "maybe..." are based on guesses.
[Fire Android Development] DragonFire1024:
I don't yet know what the effect would be. There are several things I'm looking into. The good news is if it works, every Amazon tablet has the potential to be affected as the application is present on the Fire 7, HD 8 and HD 10. If it works, It's just a matter of getting this to work without rooting.
[Fire Android Development] hwmod:
I can confirm that this part about "factory.img" boot from SD might be true, also not sure Amazon has left it available and functional.

This is also well described in previous [MENTION=1741543]sturm[/MENTION]flut papers I previously linked to. These papers may now be found here:

MediaTek details: Little Kernel

The device must be booted in FACTORY_BOOT mode (4).

It may be that by erasing the "BOOT" partition the system forces this alternative boot method. Have not tried that yet.

.:HWMOD:.
[Fire Android Development] k4y0z:
I am also unsure if it is functional, but since the compiler didn't optimize it out it's possible.

I was hoping a Factory-Cable might enable this mode, but haven't tried that yet either.

[MENTION=4381075]hwmod[/MENTION]

What do you think about overwriting the unlock-code with a hash that is contained in the signature of an amazon-signed image. And then using this signature to unlock the device via

fastboot flash unlock <signature.bin>

Do you now where the code is stored?

I am talking about the individual code that can be obtained via

fastboot getvar unlock_code
[Fire Android Development] hwmod:
I don't know exactly where the original "unlock_code" value is stored, though I believe it is stored encrypted

or is the result of some decryption process that takes in account Soc Serial plus Manfufacturer ID and probably

other variables that are written in "mmcblk0boot1" partition.

What I can say, that I know and I have tried, is that when you issue the unlock command "fastboot flash unlock unlock.bin"

the "unlock.bin" content is written to the "mmcblk0boot1" partition to memory location starting at 0x44c and ending ad 0x84b.

Total size of "unlock.bin" should never be bigger than 1Kbye (1024 bytes) since that will most probably overwrite important parts

of that memory partition (mmcblk0boot1) resulting in another "brick".

The same result obtained by externally running:

fastboot flash unlock unlock.bin​

can be obtained by running the following command form a shell (root needed):

idme unlock_code "content_of_unlock.bin"​

So, I reiterate, never try to write an "unlock.bin" which size is over 1024 bytes.

Hope this help some avoid turning their tablet to a brick.

.:HWMOD:.
[Fire Android Development] DragonFire1024:
Would explain why it bricked a tablet when I tried just flashing the Amazon update.bin to see what would happen. I'll post the screen shots of the out put when I get home. I believe it can be useful.

Regarding storage, you may have explained why some bits of code in the lk seem commented out and replaced with weird values like 0x8. You also explained a point I believe what the dha tool could be used for.