yashsingh1/xdaforums huggingface dataset:
[Fire Android Development] DB126:
Appreciate your willingness to help but aside from SOC these devices have little in common. Really not applicable to 5th gen Fire.
[Fire Android Development] Kramar111:
Also works with CH341A
[Fire Android Development] zeroepoch:
If it could be unlocked (you had the code) I'm pretty sure it would be done using the idme command which can only be used with the stock firmware as root. Forgot the exact partition it modifies, but obviously using the command is much safer. You can read info as well so you can explore without destroying things. Randomly searching for some info on the command I found a copy of u-boot for an older device. https://github.com/verygreen/u-boot-amazon-jed

---------- Post added at 12:34 AM ---------- Previous post was at 12:22 AM ----------

I was reading through the previous comments when I saw the mention about u-boot sources but then I remembered this device uses the preloader and lk as its' fastboot implementation. I'm a little rusty now with this stuff since it's been almost 9 months since I wrote aftv2-tools for the preloader stuff. There are some older leaked sources for that, but I don't think they will help us with an unlock given that it's based on an encryption key from what I could tell quickly looking through the sources.
[Fire Android Development] DoctorDark_:
I'm not sure if this will help but while in recovery, if you press volume up then down, up then down a few times, it says "mounted /system".
[Fire Android Development] ttcontributor:
seem like it's a dead end now.
[Fire Android Development] DB126:
No, just stalled. 3rd gen HDX just received universal bootloader unlock after 2.5 years. Patience is a virtue. May happen tomorrow or never.
[Fire Android Development] nyln:
It is great seeing this community is still working hard at rooting.

If it helps any of you who have given up, I wrote a script that let's you change the default launcher without root on the Amazon Fire :smile:!

http://xdaforums.com/amazon-fire/general/tut-easily-remove-amazons-firelauncher-t3467758

http://xdaforums.com/amazon-fire/development/tut-remove-default-launcher-amazon-fire-t3288310
[Fire Android Development] t3chwizard:
Agreed. Thankfully I got mine when you could install custom ROMs on it wih TWRP over fastboot so that is fine for me for now. If a bootloader unlock was released though it would be awesome on this device.
[Fire Android Development] mightymouseguy:
Maybe this could help?

Don't know if this will help at all (I'm a n00b when it comes to scatter files and scripts) but has anyone tried accessing the bootloader by way of amazons Linux os? I don't know if there would be something randomly written into the distro files that could generate the appropriate hex key just by using the distro itself? Again, this could be a long shot or way off in general, but I wanted to throw it out there in case it helps...
[Fire Android Development] Jamalama:
i know this sounds stupid

but if we find the right codeline it says an unlock code right here

(bootloader) unlock_version: 1

(bootloader) unlock_code: 0x32c5657dd83d5139

or if this is similar to a motorola bootloader unlock then someone could make a program that bruteforces its way in (Find the true unlock code) through adb
[Fire Android Development] tonibm19:
OP says that, but that code doesn't seem to work.
[Fire Android Development] stef-nix:
How would this not be similar to previous Amazon devices that had exploits to install a 2nd bootloader?
[Fire Android Development] Reuben Talbott:
could we do something like this

http://xdaforums.com/fire-hd/development/bootloader-unlock-t3129630
[Fire Android Development] t3chwizard:
Still praying for a miracle. Maybe we should rally together and produce a petition to Amazon for this. There is a need and a significant user base for it. If anyone is interested in helping me please PM me. I will start a thread in general as well.

Here is the link to the thread. http://xdaforums.com/amazon-fire/general/bootloader-unlock-petition-amazon-fire-t3526869/page1
[Fire Android Development] DB126:
There is no business case for Amazon to do this and a strong business case for keeping it locked. A 10K or 50K signature petition wouldn't even move the needle given the target audience and millions of devices sold. These are not generic Android gizmos that can be casually decoupled from Amazon's carefully currated ecosystem.
[Fire Android Development] t3chwizard:
Doesn't mean we can't try
[Fire Android Development] BeeWall:
Has anybody tried messing with the RPMB partition? I saw it mentioned here

, and was wondering if someone could upload a 5.1.1 image to compare.
[Fire Android Development] BeeWall:
According to here, it seems like the unlock codes were device-specific on the hdx. Could someone run the commands from the post I linked to, and see if their unlock code follows the same pattern as the hdx? While the code isn't useful now, it might be eventually, if we can figure out how to use them.

Also, could this bug help? https://www.codeaurora.org/projects...unds-checking-when-flashing-sparse-images-cve

https://xdaforums.com/kindle-fire-h...bootloader-unlock-procedure-software-t3030281
[Fire Android Development] DB126:
For awareness - some tidbits may prove useful.

https://xdaforums.com/amazon-fire/general/fireos-5-3-2-1-rollbacks-t3517920
[Fire Android Development] :
I have an HD8 6th Gen with 5.3.1.1 (orig was 5.3.1.0) rooted. I was playing with fastboot commands too trying to figure it out regarding the whole bootloader locked thing and ways/exploits to unlock it (like older cuber.py exploit, etc). I noticed those keys too and wondered, wtf they are right here;however, and please parden me I am NO expert or guru or anything, but that unlock code you see displayed in 0xhexhexhexhex might be the PUBLIC key. Again I could be wrong, but for their key signing verification system, the manufacture might be using a 2 key crypto system (a secret Private-Key) and the public key which is generated device specific BUT is crypto'd with the private key. So, the private-key holder has signing authority on any updates (i.e. devices that were signed with their private key and device public key) they wish to send. Any changes to the file would fail key verification and fail. I dunno.
[Fire Android Development] bullet25:
The results I got from mine were:

root@ford:/ # cat /sys/block/mmcblk0/device/manfid
cat /sys/block/mmcblk0/device/manfid
0x000015
root@ford:/ # cat /sys/block/mmcblk0/device/serial
cat /sys/block/mmcblk0/device/serial
0x87715f5d

I'd try the rest of the steps but I don't see how to do:

create a file unlock.img with following content:
0xmmssssssss
where mm=manfid and ss=serial
[Fire Android Development] DB126:
This won't work as 3rd gen HDX devices have an exposure that permits an older, vulnerable (unlockable) aboot to be flashed. Amazon fixed both glitches long ago and likely won't repeat the mistake again. 4th gen HDX devices are impervious.
[Fire Android Development] BeeWall:
Also, I found out 0xmmsssss does not match up with the code on my device. So it has a different pattern.
[Fire Android Development] bullet25:
It actually does,

the mm is just the last 2 digits of the first one and the ss are the serial so for example mine would be:

0x1587715f5d

I downloaded the tools he has on that thread but they have changed from the instructions on the page so I don't know what to do now.
[Fire Android Development] DB126:
As previously noted not going anywhere with this technique as the bootloader vulnerability that permitted 'forged' signatures was unique to early production HDX devices. Another recently discovered flaw allowed the old compromised bootloader to be flashed on devices with newer 'firmware'. Highly specialized and not leverageable to other devices - even those of similar architecture​.
[Fire Android Development] blakegriplingph:
I know this may be somewhat unrelated, but I came here after doing research on how to work around the secure bootloader restriction with certain MT8127 devices.

I have a pair of LeapFrog Epics given to me by a friend for development purposes, and the thing is, like the Fire the bootloader on this tablet is locked, keeping people from flashing custom ROMs or recovery images. Short of pressuring LeapFrog to spill the proverbial beans and all, has there been any progress in this endeavour? If the restrictions on the Fire are lifted, I'm sure something similar can be done with the Epic and it's a win-win situation.
[Fire Android Development] DB126:
No meaningful progress on on unlocking 5th gen Fire.
[Fire Android Development] BeeWall:
Since we are unable to access RPMB, is it possible we could trick LK or Preloader into backing it up somewhere we can read, since obviously those have access to it?
[Fire Android Development] steve8x8:
What would it give to know what's inside as long as one cannot change it?

There is may be a very small loophole - if the RPMB gets corrupted for some reason, in the code there are indications for a repair process possibly capable of resetting it, probably to the values the current set of bootloaders expects.

This is to be taken with a whole load of salt - it would require old enough boot loaders in place (i.e. an already bricked tablet) and an idea how to make memory access fail at the exact right time. (Do we even know at which physical location this beast is hidden?)

Without a serial terminal I wouldn't even think about trying.

Since the tablet has to be opened (and we all know about service-friendliness of A devices) this is not an option for almost everyone. Those who have access to the right tools will be focused on more promising targets.

The price to get a $40 gadget back to life is rather high, in terms of time spent (and we're not the first ones thinking about this).
[Fire Android Development] BeeWall:
Perhaps if we could figure out what to modify, we could modify it and dd it back in.
[Fire Android Development] steve8x8:
Up to now we don't even know the size of the RPMB. 512 kB is a bit at the high side, isn't it? Well, with 1 k one-bits set, it's not that much... Before writing something back (*) we should be able to read first. (What about MTek's FlashTool?)

(*) RPMB corruption seems to be handled by the AR code, so we don't have to know all the bells and whistles, just what corruption means, and do that correctly (**). But as far as I know we don't have write access yet, there's only a theoretical chance to disturb read access (by the bootloader) enough to force a RPMB reconstruction.

(**) This would mean to understand how corruption is detected, by RE'ing the corresponding part of the code (suspectedly close to the AR strings).

That said, I'd love to learn what could be found, but...
[Fire Android Development] BeeWall:
Some of the strings in /dev/block/mmcblk0boot1 seem to match up with some idme vars, and that partition shows up in idme(both in /dev and the force_ro file in /sys). Which partition is boot1?

Also, does anybody have the preloader_prod.img from the 5.0.1 update? I'd like to compare it with normal preloader, but would rather not download the whole update bin for it.
[Fire Android Development] steve8x8:
I have a preloader.img for 5.0.0 and both preloader*.img files for 5.0.1 - if you want to look for something that doesn't come with Anti-Rollback I have bad news for you.
[Fire Android Development] BeeWall:
Could you post the preloader images for 5.0.1? I know that it doesn't affect rollback. I just want to compare them.
[Fire Android Development] steve8x8:
Here: https://drive.google.com/open?id=0B214JJmar6j-VllGSWNXTS1mSU0
[Fire Android Development] BeeWall:
A (risky and probably bricking) way to corrupt RPMB might be to, from fastboot, completely zero RPMB. It would probably corrupt it, but it would also probably brick. If we could find out where RPMB is, maybe someone could use the unbrick after downgrade method to write all the zeroes.
[Fire Android Development] steve8x8:
When I scanned my near-full harddrive for disposable files, I found a couple of images showing a "JTAG MicroSD UART" adapter. What the images show is a silkscreen the end of which looks like a MicroSD connector, and has a 14-pin male header and a 5-pin (power?) connector opposite to that.

Timestamp associated is September 2012, so this may be more than obsolete - and I have no precise idea where this came from and what it was good for.

I never got hold of such a beastie - but there's a small but nonzero chance it might help?
[Fire Android Development] blakegriplingph:
Does the Fire by any chance have the usual KCOLO and GND testpoints?
[Fire Android Development] hwmod:
Yes, they are labeled on the MB.

You can find them right under the volume up/down buttons.

And yes ... they work like in other tablets to let one boot in different modes.
[Fire Android Development] blakegriplingph:
So that means the Fire can be unbricked as with any MTK device, right? Or is it a tad more complicated than that?
[Fire Android Development] DB126:
I'd say the latter as no sucessful unbrick techniques have been identified (or at least published) other than in a few special situations. That said, not sure how thoroughly this approach has been explored ...
[Fire Android Development] hwmod:
SP_Flash_Tool information and sources

I recently discovered that there are many hidden screens and capabilities in SP_Flash_Tools, a bit late but always good to know.

I already knew that it was possible to use either Serial or USB interfaces/protocols but these new hidden screens were a surprise to me.

These keys combinations will toggle (enable/disable) some extra TAB in the SP_Flash_Tool interface or some advanced features.

CTRL+ALT+A = Boot ROM Adapter Download

CTRL+ALT+B = Mark NAND Bad Blocks Mode

CTRL+ALT+M = Runtime Trace Mode

CTRL+ALT+S = Security Mode

CTRL+ALT+T = Device Test Mode

CTRL+ALT+V = Advanced Mode

On top of these new info (at least for me) I also found out that SP_Flash_Tool full sources, for both Linux and Windows, can be downloaded from here:

http://mtk2000.ucoz.ru​

or even from here:

https://plus.google.com/102046638272163083468​

In the first link there are also many other useful tools for MTK devices.

Not sure these info are available and known already but I find them pertinent to this thread.

Hope this will be of help for our task, unfortunately my time is very limited and knowledge of these tools are really scarce.

.:HWMOD:.
[Fire Android Development] blakegriplingph:
If that's the case what if you try using Write Memory to write system.img or some other image to the tab? Would that subvert Amazon's protection scheme?
[Fire Android Development] hwmod:
AFAIK It is not possible without a properly signed certificate (probably an Amazon RSA key), but I hope to be showed wrong on that :)

Maybe by RE'ing the SP_Flash_Tool source code we could find some hole or alternative way to bypass the ANTI-ROLLBACK checks.

I believe it's just a matter of loading the correct code and/or keys in RAM and jump to it (not that easy though).

.:HWMOD:.
[Fire Android Development] blakegriplingph:
From what I can tell using write memory bypasses any security checks as it merely writes stuff to a region defined by the user. This should work on /system as what I can attest on my LeapFrog Epic, but low-level boot code is more stringently checked, so yeah, it may not be of much help if you intend on downgrading the device.
[Fire Android Development] BeeWall:
If we could figure out what bytes tell preloader the lk version (I know, there's a lot of bytes to look through), maybe we could modify those so the preloader would think a 5.0.x bootloader is a newer version. It wouldn't be an unlock, but it would make boootloops easier to fix with TWRP.
[Fire Android Development] hwmod:
This should be the tool we need but instructions were not so clear to me.

I pass on these info so you can try and maybe understand what is said there, there are instruction for both "secure" and "normal" SoC.

It seems it does the write/jump to SRAM like SP_Flash_Tool but I couldn't find how to make it work as intended, maybe you can do it.

https://github.com/mtk09422/chromiumos-third_party-mediatek-datool

.:HWMOD:.
[Fire Android Development] blakegriplingph:
Hmm, the RSA key and preloader stuff seems interesting. Maybe that would be key to unbricking the Epic, and of course the Fire for that matter. The preloader binary on my device apparently has the key stored as plaintext, but I'm not sure if that would be of any use at all.
[Fire Android Development] zeroepoch:
SP flash tool is not much use if it's requiring a signed download agent as most devices do now. The write command I already exploited with aftv2-tools to write to the system image. They closed the hole on recent firmwares. It was used by a number of fire tablet users with old firmwares to unbrick it. They are smart and checksum or hash everything. Brute force is one of the few options I think. In light of Google publishing the shattered SHA1 collision proof of concept if we get a few hundred people together with high end GPUs we could maybe spoof the hash after a few months. Mostly likely any RSA key you find in plaintext is probably the public key.
[Fire Android Development] t3chwizard:
I'm in. I have dual nvidia GT650M in my gaming laptop. Not the best but it should help. Glad to see this thread bumping after a while. We might figure this out yet!!!!
[Fire Android Development] BeeWall:
A good CPU is probably more important than a good GPU in this case.

How would they have a hash check for bootloader if the preloader is older and doesn't have hashes for newer versions? Or am I misunderstanding what you are talking about with hashes?
[Fire Android Development] zeroepoch:
From what I remembering looking at the preloader dump is they hash then sign the contents. Or you could say hashing is part of the signing really. So it doesn't matter if it's newer or older as long as that matches for the contents. This is just based on looking at the strings at the end of the image. It's been over a year now but I think I remember even being able to match the hash by doing it over the right range of bits. If you wanted to change a bit to hack something like the check for the unlock key you'd need to get the hash to match or resign the hash. In the work Google did they created a collision in SHA1 using a ton of GPUs. I think 110 and a year of time. https://shattered.io/
[Fire Android Development] BeeWall:
That means nothing to me ? Thanks for trying to explain.

If it takes a year and 110 computers, we better get busy.

You're right, two antirollback lines say checksum validated or invalid.
[Fire Android Development] DB126:
Yes - any reasonable level security effort involves hashing/signing. Forget about brute forcing with a handful of desktops. If it were that easy it would have been cracked the day after being released.
[Fire Android Development] hwmod:
Other ideas on unlocking/unbricking Fire 7 5th Gen tablets

Maybe our unlock attempts would be easier by using firmware of a similar device that already provides a signed firmware.

The device I am talking about is the Acer Iconia One 7 (model B1-770). It uses exactly the same SoC (MT8127A), the same GPU (Mali-450MP4) and most of the same hardware.

The idea is that if the firmware DOES NOT depend on information written in the SoC BROM it would be possible to load whatever firmware (preloader/lk) for the same SoC given they are correctly hashed and signed.

The only difference I see is that the Acer B1-770 uses a different partition layout:

Acer B1-770 uses MBR

Fire 7 5th Gen uses GPT

however we don't need a full boot and a working touch screen ... we only need to load the "preloader.bin" and "lk.bin" pair to gain "fastboot" access and be able to rewrite the hidden EMMC_BOOT1 area.

As a second alternative, also from Acer and using the same hardware:

Acer Iconia Tab 10 A3-A20 and A3-A20FHD (10 inch instead of 7 inch)

Also, the firmware of both these devices may offer a chance to compare the firmwares and gather more info and maybe we can join forces with ongoing development on these tablets.

I am interested to know if you think this would be a viable attempt or if I am missing some of the key points and you believe this does not offer any advance to the quest.

.:HWMOD:.
[Fire Android Development] BeeWall:
EMMC_BOOT1 is editable in the OS with root. RPMB is not. Also, I think this would probably brick, as things generally don't work device to device.
[Fire Android Development] hwmod:
Thank you for your thoughts. However I have a bricked Fire 7 so EMMC_BOOT1 is not writable.

Once we are able to unbrick/recover it would be easier to do more testing without worrying.

It is true that using firmware from different devices doesn't work normally and may brick the device,

but here we have an almost clone device/hardware same SoC (MT8127A), same PM (MT6323),

same GPU (Mali-450MP4), same BT/Wifi (MT6627) and same EMMC so I keep hoping :)

If somebody already tested this route please tell the results and procedure used.

Thoughts are really welcome and appreciated.

.:HWMOD:.
[Fire Android Development] BeeWall:
If it's bricked, how do you change preloader? Could you use that method to write to boot1? What even does boot1 do? I guess you could try preloader, but it might ruin the device even more.
[Fire Android Development] blakegriplingph:
Serial access, perhaps? Like a UART or something along those lines? Been trying to write a preloader dumped off my LeapFrog Epic to no avail, as I made the mistake of formatting the device and ending up with a semi-hard brick.

The Epic is still detected by my PC as a USB Serial Device, but while it can be reflashed it is still stuck in download mode.

If the Fire's preloader is signed, what about the bootROM within the SoC itself? Is it programmable in some way? Or if it is hardcoded, did Amazon somehow ask MTK to provide a bespoke version of the 8127, or is it merely a feature of the chip?
[Fire Android Development] hwmod:
I can't write/change the "perloader" without an "auth_sv5.auth" authorization file (at least I guess so).

However if we can find a similar tablet with its own ".auth" file and firmware for the "MT8127A" we could probably

be able to use it to bring up the minimal "fastboot" mode that will allow us to make changes and write to the "boot1" partition.

"boot1" is the hidden EMMC_BOOT1 partition which holds the "preloader", corresponding to /dev/block/mmcblk0boot0 in a

working tablet once it has completely loaded Fire OS or Android OS. From there this partition is writable (at risk of bricks).

I need firmware for any "MT8127A" device which includes the ".auth" file. The file should be exactly 2256 bytes which is probably an

RSA private key (hashed & SHA256 signed) that was used to sign the "preloader" and other accompanying images of the firmware.

If we find the above ".auth" file we may have a method to unbrick dead tablets around and extra chances to unlock these devices.

.:HWMOD:.

---------- Post added at 04:18 AM ---------- Previous post was at 04:01 AM ----------

I am not completely sure, just guessing and reading info around it seems the BootROM is read-only and cannot be reprogrammed through USB/Serial.

The BROM bootloader code should be located at address 0xFFFF0000 in the last 64K upper memory block.

I have hooked up the UART in my tablet but it doesn't let me write/download the DA.

We need to find a working ".auth" authorization file as I wrote in my previous message.

I don't think MTK provided a special version to Amazon, though we cannot exclude that possibility.

However I am more inclined to believe it is just a factory DA Disabled and DA Secured chip that

needs an authorization certificate to let one write the "preloader".

The DA Disabled & Secured are features of these MTK SoC family.

Another method would be to capture the RSA key in-memory like they did with the Qualcom SoC.

But for this we need someone knowing IDA Pro or similar, ARM assembly and hardware/debug skills.

.:HWMOD:.
[Fire Android Development] blakegriplingph:
Yeah, it could be just a commodity version of the 8127 with an oddball preloader slapped into it. The RSA key hack could also be an interesting thing to do too.

Oh and hope you don't mind, but can you check your inbox?