yashsingh1/xdaforums huggingface dataset:
[Fire Android Development] diplomatic:
To clarify, I'm talking about binwalk detecting the 256-byte raw public key blobs in the

preloader

binary.

[MENTION=4381075]hwmod[/MENTION], the two preloader binaries you were talking about got me curious... I found preloader.img and preloader_prod.img in a 5th gen FW package and compared them. And the differences were pretty much as I thought. preloader_prod.img is signed with the device's chip key, while preloader.img actually uses Mediatek's default test key. So it's no wonder the latter one wouldn't work. I'm sure it's a perfectly valid PL, but it would never pass the chip's signature check. (Not even sure why it's there.) You can see the encoded key at offset 0x8c0. I know this info is not very helpful, but at least it should prevent you from making some bricks.

Well, according to the script, that flag does 'setprop sys.dexopt.boot.disable 1', which disables dexopt from running on boot. A quick search told me dexopt is a tool that optimizes dex files...
[Fire Android Development] DragonFire1024:
Hmm interesting. I wonder if it tells the system to not odex files. If so, this may be a break through. I'm certain the flags will work if I weren't for the files being odexed.
[Fire Android Development] hwmod:
Appreciate your insights on that, there are always details I learn which wasn't clear to me initially.

The reason there are two preloaders in the update packages is that each update is meant for two different branches (production and engineering).

Reading in the "updater-script" reveals that the conditional branch is bound to the "/proc/idme/board_id", certain numbers are "eng" other are "prod".

Since you named it, could you tell me which is the Mediatek private test key you are referring to and tell were to find it ? Or include it as attachment ?

Thank you in advance for the help and the time you put in this.

.:HWMOD:.
[Fire Android Development] Rortiz2:
I looked at the updater-script and as you said, reveals that the conditional branch is bound to the "/ proc / idme / board_id:

ui_print("Copying preloader.img to boot partition 0 for unsecure device...");
package_extract_file("images/preloader.img", "/dev/block/platform/mtk-msdc.0/mmcblk0boot0");
else
if ("[COLOR="Red"]0037001010000017" == read_file_str("/proc/idme/board_id[/COLOR]") ||
"[COLOR="red"]0037001020000017" == read_file_str("/proc/idme/board_id[/COLOR]"))
then
ui_print("Copying preloader.img to boot partition 0 for unsecure device...");
package_extract_file("images/preloader.img", "/dev/block/platform/mtk-msdc.0/mmcblk0boot0");
else
ui_print("Copying preloader_prod.img to boot partition 0 for secure device...");
package_extract_file("images/preloader_prod.img", "/dev/block/platform/mtk-msdc.0/mmcblk0boot0");
endif;
endif;
endif;

But what is unsecure device and secure device?:

ui_print("Copying preloader.img to boot partition 0 for [COLOR="red"]unsecure device[/COLOR]...");
package_extract_file("images/preloader.img", "/dev/block/platform/mtk-msdc.0/mmcblk0boot0");
else
ui_print("Copying preloader_prod.img to boot partition 0 for [COLOR="Red"]secure device[/COLOR]...");
package_extract_file("images/preloader_prod.img", "/dev/block/platform/mtk-msdc.0/mmcblk0boot0");

On the other hand, I have seen the file file_contexts and I found this section:

#############################
# System files
#
# removed for FireOS integration - not used
/system/bin/aal u:object_r:aal_exec:s0
# /system/bin/atcid u:object_r:atcid_exec:s0
# /system/bin/atci_service u:object_r:atci_service_exec:s0
# /system/bin/boot_logo_updater u:object_r:boot_logo_updater_exec:s0
/system/bin/nvram_agent_binder u:object_r:nvram_agent_binder_exec:s0
/system/bin/nvram_daemon u:object_r:nvram_daemon_exec:s0
/system/bin/thermald u:object_r:thermald_exec:s0
/system/bin/autokd u:object_r:autokd_exec:s0
/system/bin/thermal_manager u:object_r:thermal_manager_exec:s0
/system/bin/ThermalBenchmarkAutomation.sh u:object_r:thermal_bench_exec:s0
/system/bin/wmt_loader u:object_r:wmt_loader_exec:s0
/system/bin/stp_dump3 u:object_r:stp_dump3_exec:s0
/system/etc/sensor(/.*)?	u:object_r:system_sensor_data_file:s0
/system/etc/syseng\.sh u:object_r:sysengd_exec:s0
/system/vendor/bin/pvrsrvctl u:object_r:pvrsrvctl_exec:s0
/system/vendor/bin/pvrdebug u:object_r:pvrsrvctl_exec:s0
/system/bin/battery_lifetime_data u:object_r:battery_lifetime_data_exec:s0
/system/bin/kpoc_charger u:object_r:kpoc_charger_exec:s0
/system/bin/kisd u:object_r:kisd_exec:s0
/system/bin/rpmb_svc u:object_r:tee_exec:s0
/system/bin/6620_launcher u:object_r:mtk_6620_launcher_exec:s0
/system/bin/hotplug u:object_r:hotplug_exec:s0
/system/bin/devicetype_service u:object_r:dev_type_svc_exec:s0

# Wallpaper file for smartbook
/data/system/users/[0-9]+/smartbook_wallpaper	u:object_r:wallpaper_file:s0

What are these files? Amazon has deleted them?
[Fire Android Development] DragonFire1024:
I've seen the file context and wondered the same. I do know Amazon has modified some of the stock bin files like bootanimation so not sure why they just didn't modify the others. The question is...can we locate these deleted files and replace them? Is there any mention of the ones they modified? With root I can replace them and see what happens.

I setprop dexopt and didn't see any noticeable change. I had to put persist in front or it wouldn't hold.
[Fire Android Development] hwmod:
From my guesses I understand that "secure" and "unsecure" devices correspond to "production" and "engineering" devices.

So "secure" devices have locked bootloader (production) while "unsecure" device have unlocked bootloader (engineering).

The above file section you have found is a list of system files and their related "selinux" contexts in the filesystem they are located.

.:HWMOD:.
[Fire Android Development] Rortiz2:
I have no idea where those files are.

I just discovered one thing, maybe it's nothing but I explain how I did it. My fire was at 0 battery and I connected to my laptop. The logo of the battery has come out and turned off. I have kept the power button and the computer has detected a device called adb interface. I have left the button pressed and in cmd I have written fastboot devices and one has come out. The fire was in bootloader mode but there was no signal on the screen.

These are the steps I have followed:

1- Let the battery run out and when we turn on the fire the piano sound will be heard and this logo will appear:

2- Connect the tablet to the computer and wait for the logo to appear that is charging. The computer will detect it as MTK Preloader.

3- When the logo is gone and the screen is black, press the power button for 10 seconds.

4- The computer will recognize the Fire as android ADB interface:

Maybe this is nothing or is it stupid, but I was impressed that without an image on the tablet the computer detected it as an adb composite interface

PD: Sorry if you do not see the images. I do not find any good place to upload them and copy the url.
[Fire Android Development] diplomatic:
Oh, I see... that's pretty cool. It flashes one img to some devices the second to others. I would say that the unsecure devices are those where they "forgot" to set up the SoC's secure boot parameters at the factory for some reason. The boards of those units must/can boot to the test-key signed preloader. It's probably some board revisions that are floating around out there. There's no indication that those are engineering devices. "Engineering" refers to software rather than hardware. If you have one of those revisions, you are in theory able to modify anything in the boot chain and sign the preloader yourself. Those units are literally unsecure. ;)

It's the universal CHIP_TEST_KEY.ini file that you can find on github for a lot of MTK devices. Like, the mt8163 repo has it at: https://github.com/yos-two/mt8163-v...ustom/yyd8163_tb_m/security/chip_config/s/key

There are some elaborate steps involved in signing it. I can guide you if you ever want to try it...

I think this is new for Fire OS 6.
[Fire Android Development] NFSP G35:
If that's the case, is there a non destructive way to check the device to see if it's 'unsecured'?
[Fire Android Development] diplomatic:
Yeah, just check what the script checks.... Get your board_id variable (from /proc/idme/board_id?) If it matches one of those numbers, then you are in the unsecure club.

-------------------------

Hi, [MENTION=8978978]Rortiz2[/MENTION]! :)
[Fire Android Development] Rortiz2:
Hi :laugh:. Do you also have a fire?:)

---------- Post added at 05:54 PM ---------- Previous post was at 05:53 PM ----------

So are you saying there are fires that come with the bootloader unlocked? Or have I misunderstood it?
[Fire Android Development] hwmod:
I don't think they "forgot" to set the SoC's secure boot parameters at the factory. It seems Lab126 did their work well enough.

I believe instead it has been done intentionally so they can give "unlocked" devices to their developers ensuring code portability.

With that, they also achieved to have a unique developing tree/trunk thus avoiding code conflicts (high risk for this level of security).

I say that because the idea copes with the existence of the hidden "DevoProdConfig" setting that Dragonfire1024 found a few weeks ago.

.:HWMOD:.
[Fire Android Development] Rortiz2:
In proc / idme there is a file called unlock_code but it does not contain anything. I was excited to see it but when I opened it and I saw that there was nothing I was disappointed.

my board_id is: 0037001080000017 is secure or insecure?
[Fire Android Development] NFSP G35:
No such luck...

00320014000200017

Oh well
[Fire Android Development] DragonFire1024:
HD 10 here and my board ID does NOT match the numbers. Mine is 0028001400010017. Not sure where in the script to check?
[Fire Android Development] NFSP G35:
Oh yeah, guess I should have mentioned. 2017 HD8

Which device update did that script come from?
[Fire Android Development] blazinandroid1:
Well I am going to step up and help to get the bootloader unlocked.. It should be that hard. Once I start digging into to it..
[Fire Android Development] hwmod:
Successfully "unbricked" Fire 7 5th Gen after downgrade attempt

Good news friends !

I successfully "unbricked" my Fire 7 5th Gen after almost killing it with a downgrade attempt trying to go from version 5.1.1 to 5.0.1 (previous version).

I know this thread is about "Bootloader Unlock Ideas" so my apologies to the thread owner for this.

I will open a new thread as soon as possible with the relevant information and links to the tool I used.

However I believe I found a way to write directly to the EMMC bypassing most ANTI ROLLBACK checks.

Everything was already said in my previous posts I just needed to find the right tools to do the job.

I hope my findings can help others recover their tablets and hopefully have more control over these MTK devices.

The method doesn't require "fastboot" to be working, it is at a lower level and may lead to a "bootloader unlock" too.

Have fun,

.:HWMOD:.
[Fire Android Development] Tomsgt:
awesome news please get in contact with me at Rootjunky@gmail.com I would love to make a youtube video on this new unbrick process :)
[Fire Android Development] CAL7:
Does this offer any hope for UB on the Fire HD 8/10?
[Fire Android Development] Awesomeslayerg:
Will this let us downgrade our bootloader,?
[Fire Android Development] hwmod:
I really hope so ! It may help with that task since the method allows writing directly to any EMMC memory address.

Also it may be of help with other Mediatek devices and with newer versions of the Amazon FireOS for the Fire 7 5th Gen.

Anyway, for now, it is just a raw "unbrick" method targeting those people that tried to downgrade from 5.1.1 to 5.0.1 and bricked their tablet.

After all, that was my primary objective given the high number of bricked devices.

.:HWMOD:.
[Fire Android Development] Awesomeslayerg:
Any updates on the guide,?
[Fire Android Development] hwmod:
I whish I had more time to quickly publish my findings but currently that's not the case (too much backlog work).

Please be patient, I planned to write down the steps I followed to recover my "bricked" unit during the next weekend.

.:HWMOD:.

---------- Post added at 04:55 PM ---------- Previous post was at 04:45 PM ----------

I don't own one of these and I don't know the processor brand/model used in these Fire HD 8/10.

If they have a Mediatek processor there is a chance this can be done on those tablets too.

.:HWMOD:.
[Fire Android Development] Kramar111:
[MENTION=4381075]hwmod[/MENTION]

https://developer.amazon.com/public...ications/01-device-and-feature-specifications
[Fire Android Development] CAL7:
Fire HD 8/10:

MediaTek MT8135
[Fire Android Development] Vlasp:
[MENTION=4381075]hwmod[/MENTION] Just a bump, because I can't wait for this unbrick method!
[Fire Android Development] ldeveraux:
why do you think that bumping a thread, that he didn't even start, is going to make positive progress? Leave him alone, let him work at his own pace, wait for results, don't try to force them!
[Fire Android Development] armada786:
Bypassing the anti-rollback is great news even if it isn't directly leading to an unlock. I'd much prefer to use TWRP to Flashfire.

[MENTION=4381075]hwmod[/MENTION] you said you write the EMMC directly. Can you only write signed images or can this feasibly be any data?
[Fire Android Development] riverstyxxx:
Stop doing this, we want to see it happen and we're all paying attention but bugging and e-begging is not the way to go about it. Just leave them alone and let them work.
[Fire Android Development] hwmod:
It looks like I can write any data to the EMMC (no need to sign), though it is an incredible slow process.

For example it took almost 2 hours to write the TWRP image to the recovery partition (8 Megabytes).

I tried writing "TWRP_Fire_2.8.7.0.img". It didn't work but the tablet is still alive and working fine.

Maybe I should try using "TWRP_Fire_2.8.7.0_adb.img" instead of the one I used.

I made a backup of the entire original recovery partition (16Mb) before trying to overwrite it.

In this way I have a chance to rollback to the original recovery tomorrow (4 more hours).

For those that cannot wait I highly recommend to read my previous post #23 and all of Sturmflut's docs, especially:

MediaTek details: Partitions and Preloader

The method I am using is based on the CMD_READ32 and CMD_WRITE32 operations described in the above doc.

The Python code I used is Zeroepoch's tools for the Amazon Fire TV 2nd Gen that you can download from here:

Zeroepoch's AFTV2-Tools

Previously I used LuckAS mediatek-utils code to test these methods but Zeroepoch's code is much better/complete.

There is nothing really difficult in what I did but be advised that you may "brick" your tablet by using this stuff.

If your tablet is already "bricked" there are chances you can recover it, but only if you don't make things worst.

You have been warned.

.:HWMOD:.
[Fire Android Development] Vlasp:
Sorry about that post guys, I was just kind of excited for this, and I didn't keep in mind how I looked like I was forcing him to release an unfinished method/product. I'll just wait for the final guide/method to be released patiently.:good:
[Fire Android Development] Awesomeslayerg:
Ehhh I might actually brick it on purpose just to try hwmod methods. I can buy another one and I already own another different ! model .
[Fire Android Development] ldeveraux:
I know it probably won't correlate, but that's how the initial root of the fireTV 2 was done. The entire boot image was rewritten with an A-A cable.
[Fire Android Development] hwmod:
What is an A-A cable ? Did you mean a "fastboot factory cable" ?

If it is a special cable can you send link to information about it ?

.:HWMOD:.
[Fire Android Development] CAL7:
A-A cable (male-to-male): http://www.amazon.com/s/?url=search-alias=computers&tag=aftvn-20&field-keywords=a+to+a+usb+cable
[Fire Android Development] DragonFire1024:
Says above..HD 10

---------- Post added at 11:02 PM ---------- Previous post was at 10:17 PM ----------

Also...I've been trying to modify boot image. When I fail and flash stock, it's supposed to erase and reinstall all the system right? The last three times, all my apps are still there, ADB enabled (no flags set). I however don't have root anymore and it appears anything that was in /system that I put there, was moved to the user space.
[Fire Android Development] Rortiz2:
FIRE 7 (AUSTIN):

if ("0037001010000017" == read_file_str("/proc/idme/board_id") ||
"0037001020000017" == read_file_str("/proc/idme/board_id"))

FIRE HD8 2017 (DOUGLAS):

Not have unsecure and secure devices in updater-script

FIRE HD10 2017 (SUEZ):

Not have unsecure and secure devices in updater-script

FIRE 7 2015 (FORD):

if ("0025001000000015" == read_file_str("/proc/idme/board_id") ||
"0025001000010015" == read_file_str("/proc/idme/board_id") ||
"0025001010000015" == read_file_str("/proc/idme/board_id") ||
"0025001010010015" == read_file_str("/proc/idme/board_id") ||
"0025001020000015" == read_file_str("/proc/idme/board_id"))

FIRE HD8 2016 (GIZA)

Not have unsecure and secure devices in updater-script

FIRE HD10 2015 (THEBES):

Not have unsecure and secure devices in updater-script

FIRE HD8 2015 (MEMPHIS):

Not have unsecure and secure devices in updater-script

---------- Post added at 10:20 PM ---------- Previous post was at 10:18 PM ----------

Wow, after flashing the update.bin are the apps still installed !?
[Fire Android Development] DragonFire1024:
Yes all of them.
[Fire Android Development] DragonFire1024:
So it seems if I have to reflash because I still can't flash a modded boot.img, all apps and settings remain upon reboot and I can reroot right from there. But if I screw up something in the system and reflash, everything is cleared
[Fire Android Development] diplomatic:
Nope, don't have any Fire tablets. But I might be able to offer some assistance, as I'm somewhat of an expert on Mediatek in these parts. ;)

I'm not saying those units are bootloader unlocked out of the box. But there is no real (cryptographic) security stopping you from disabling secure boot. As far as I can tell, you can modify and sign the PL, which is what [MENTION=4381075]hwmod[/MENTION] was talking about. And if you can do that, you can modify the LK and any other parts down the secure boot chain.

Yeah, something I neglected to mention is that you have to check the updater-script for board_ids from your firmware. This loophole only applies to some older models, though (2015 and older).
[Fire Android Development] Rortiz2:
Yeah, that only applies to some models. I think the fire hd8 2015 and the fire hd10 2015 also use it. Now I will look at the update script to check it
[Fire Android Development] Rortiz2:
Thebes and memphis don't have unsecure and secure device in updater-script
[Fire Android Development] hwmod:
===== INFO TO AVOID MORE "BRICKED" TABLETS =====

Dangerous but worth a mention is the fact that if the tablet has been "rooted" it is possible to modify the "board_id" using the "idme" command.

This can be used to trick the system to write the "engineering" (unsecure) version instead of the "production" (secure) version of the firmware.

So if you are not sure about what you are doing, do not try to update of the firmware while the "board_id" has been changed.

The risk is to end up with another "bricked" tablet that will be only recoverable through hardware modding using difficult soldering.

However if you already tried that, or applied an "hard-mod" that will always allow to recover the tablet please share the procedure/outcome.

An "hard-mod" allows a complete rewrite of the original firmware, especially the hidden EMMC partitions (mmcblk0boot0 and mmcblk0boot1).

.:HWMOD:.
[Fire Android Development] DragonFire1024:
How would an engineering firmware get written without flashing? I would be willing to try this on my spare HD 10
[Fire Android Development] Kramar111:
Maybe

adb shell getprop ro.boot.secure_cpu
[Fire Android Development] NFSP G35:
Thanks, but I was mistaken when I asked that question. I thought the snippet from the update script was for the HD8 (which I have) but it is actually for the HD10.

My 'Douglas' doesn't have any such if condition in its update script, or a separate preloader image. So no such luck.

Also, ro.boot.secure_cpu is set to '1'
[Fire Android Development] Rortiz2:
In the update bin there are two preloaders so one will be for secure device and the other for unsecure. I would not flash it because it's likely that you get a brick
[Fire Android Development] Rortiz2:
Hey [MENTION=8165603]DragonFire1024[/MENTION] I have seen that there is a flag that says ro.boot.unlocked_kernel = false

Have you tried to modify it if you are root?
[Fire Android Development] DragonFire1024:
Yes. At least I have in the normal ways...setprop, build.prop. Google's developer page has a couple I tried tomorrow avail. And I also never seen this prop in another device aside from Amazon. At least not out in the open.

Also the preloaded is signed by Amazon right? Then what would be a reason to brick if it's official?

---------- Post added at 04:44 PM ---------- Previous post was at 04:23 PM ----------

Not sure if this is any use. I ran the certificates in the update.bin through IDA and the .SF is interesting.
[Fire Android Development] Rortiz2:
However signed they are, there are many possibilities of brick.

For example:

Downgrade from 5.1.1 to 5.0.1.

The two updates are from amazon and are signed by amazon, but even so, when you downgrade, you brick the fire.

Whenever when we play partitions like lk, uboot or preloader we end up bricking the tablets.

Can you do adb shell cat proc/partitions and adb shell ls -al /dev/block/platform/mtk-msdc.0/11230000.MSDC0/by-name? and publish the output?
[Fire Android Development] DragonFire1024:
As soon as I can you got it.
[Fire Android Development] DragonFire1024:
root@suez:/ # cat proc/partitions
major minor #blocks name

7 0 82796 loop0
7 1 1254 loop1
7 2 10240 loop2
179 0 30535680 mmcblk0
179 1 3072 mmcblk0p1
179 2 4608 mmcblk0p2
179 3 1024 mmcblk0p3
179 4 1024 mmcblk0p4
179 5 1024 mmcblk0p5
179 6 5120 mmcblk0p6
179 7 5120 mmcblk0p7
179 8 40448 mmcblk0p8
179 9 512 mmcblk0p9
179 10 8192 mmcblk0p10
179 11 16384 mmcblk0p11
179 12 17408 mmcblk0p12
179 13 1653248 mmcblk0p13
179 14 434176 mmcblk0p14
179 15 28343791 mmcblk0p15
179 96 4096 mmcblk0rpmb
179 64 4096 mmcblk0boot1
179 32 1024 mmcblk0boot0
179 33 2 mmcblk0boot0p1
179 34 2 mmcblk0boot0p2
179 35 256 mmcblk0boot0p3
179 36 747 mmcblk0boot0p4
179 128 31166976 mmcblk1
179 129 31165952 mmcblk1p1
root@suez:/ # ls -al /dev/block/platform/mtk-msdc.0/11230000.MSDC0/by-name
/dev/block/platform/mtk-msdc.0/11230000.MSDC0/by-name: No such file or directory
1|root@suez:/ #