yashsingh1/xdaforums huggingface dataset:
[Fire Android Development] DragonFire1024:
Well can't get ADB to work on my spare HD 10. Had to reflash and with the fos_flag 33 set, I can't grant ADB access. There is a file in /system/bin wipe_fos_flags and I can't get it to execute (root or not). Can someone find out how to wipe the flags using that file?
[Fire Android Development] diplomatic:
Oof... do you still have root/supersu? If you do, you can use a terminal app to run that command on the tablet. Wipe_fos_flags is basically the same at its core as idme. It's just a shortcut for 'idme fos_flags 0'. The way it's wiped intentionally is by this code in init.rc:

service wipe_fosflags /system/etc/init.fosflags.sh wipe
class core
oneshot
disabled

on property:amazon.fos_flags.wipe=1
start wipe_fosflags

So setting the property amazon.fos_flags.wipe to 1 should trigger it. But I don't know if you can do that with unprivileged user.
[Fire Android Development] DragonFire1024:
No more root :( Would that he done with setprop in a shell? Also can more than one fos flag be set? I am pretty sure the adbnoauth and either fos_flags 3 or 33 together gets ADB where we want.
[Fire Android Development] diplomatic:
Yeah, try 'setprop amazon.fos_flags.wipe 1'. But I think you need the adb shell UID to set it. Ugh....

The flag value of "33", aka 0x33, is already combining 4 bits: 0x1+0x2+0x10+0x20. It's just a bitwise OR operation. That's exactly what you're asking about. So you had 4 flags activated: adb_on, adb_root, verbosity, & adb_noauth. With 0x3, it's 2 bits: 0x1+0x2.
[Fire Android Development] DragonFire1024:
Just got home. And guess what...it worked :D

Set the prop, reboot and flags are wiped. No root required. Now we are onto something. That means parts of Amazon fos are definitely executable without root.
[Fire Android Development] diplomatic:
Nice! That's a relief....

Yes, the wiping step is executable without root, but not much else. The flags don't seem to do anything useful anyway.
[Fire Android Development] Supersonic27543:
In light of DragonFire's post above, I tried several setprop commands including creating new props, and they all worked. Only the ro props failed to set.
[Fire Android Development] DragonFire1024:
If that's the case then you'll be able to set the fos flags for at least adbnoauth and the other one that locked me out briefly. I will get the props tomorrow unless [MENTION=8132642]diplomatic[/MENTION] can post them

---------- Post added at 06:25 AM ---------- Previous post was at 05:59 AM ----------

Did they hold after a reboot?
[Fire Android Development] diplomatic:
How? There is only one property that triggers the wipe command. That's it. You already listed the flags in post 481. There is also a FOS_FLAGS_ADB_ROOT, which is presumably 0x2.

The only properties that would carry over after a reboot are ones that start with persist.* .

[MENTION=7860599]Supersonic27543[/MENTION], did you use an adb shell or a terminal app? Because adb has higher privileges than an app. I tried setprop in terminal shell, and it gave me permission denied.
[Fire Android Development] Supersonic27543:
I used an adb shell on HD 8 5.6.1.0 with UID 2000.

[MENTION=8165603]DragonFire1024[/MENTION] I forgot to test, anf I don't have my device right now, I can check tomorrow. I think setprop is meant to work for root users only? As I remember setprop on UID 2000 failed on 5.6.0.0 / 5.6.0.1.

EDIT: Could it be possible that there is a property which allows adb root? I remember service.adb.root on some devices.
[Fire Android Development] DragonFire1024:
These are what I know off the top of my head, but probably useless.

setprop
persist.sys.usb.config mtp,adb
persist.service.adb.enable 1
persist.service.debuggable 1

I have links at home. I also sent you a PM a quite a while ago that had some commands where you could persist ADB root in a tmp folder without being root. There is also a tool I recall called setpropx or ex that exploited /data to set props. I wonder if a local.prop can still be made in /data/local.

---------- Post added at 12:02 PM ---------- Previous post was at 11:52 AM ----------

Just found this. Some of these closely resemble the fos_flags https://android.googlesource.com/platform/system/core/+/master/adb/daemon/main.cpp
[Fire Android Development] DragonFire1024:
Anyone know what this might be? It is in /data/misc/keystore/user_0 and the file is called '.masterkey' I did a brief search and this does appear to be the master key. This isn't used in Android 6.0+ so maybe this is an advantage for us?

Ref: https://stackoverflow.com/questions/42994075/using-the-android-hardware-backed-keystore

There is a tool that supposedly decrypts and extracts the data from .masterkey https://github.com/nelenkov/keystore-decryptor
[Fire Android Development] DragonFire1024:
And why would Amazon put their keychain in secure settings? Their public key and serial black lists from the same directory but in 'keychain' are sitting in secure settings. The value for serial is empty though
[Fire Android Development] EditedReality:
if the bootloader cant be modified using SU why not try to find what you can modify it with? or somehow modify the SU in a way it ignores what makes it not modify the bootloader (if this sounds dumb im sorry just trying to think of ideas)
[Fire Android Development] Supersonic27543:
Actually IMO it is okay to ask out any ideas... ;)

The bootloader can be modified with su, but if the bootloader is modified the device will refuse to boot.

There is a chain-like security mechanism here, the boot ROM (which is burned into the hardware and cannot be modified) verifies the preloader (bootloader) is not modified and loads it. The preloader then verifies the boot image is not modified and loads it, and the boot image loads the system (the OS, apps, etc.), but not necessarily verifies it. So we can only modify the system without breaking the chain at some point. (And in versions newer than 6.0.0 the boot image verifies the system, so we can't even edit that)
[Fire Android Development] EditedReality:
i think i might of had a better idea in fire-OS-5.3.1-update-kindle-global-37.5.5.2_user_552153420.bin when you install update through adb it replaces boot.img with preloader_prod.img inside it, not sure if this is useful in any way but its a thing (im not 100% sure it just said it did in the on screen messages as i installed it)

also what checks does it to do to see if it is not modified?
[Fire Android Development] DragonFire1024:
What if I told you I just figured out how to disable selinux in the boot.img? IDK if it works yet though. Using carliv_imafe_kitchen you supposedly can eeadd command lines to the boot.img.
[Fire Android Development] EditedReality:
i would search it up because i forgot what it means and then i would congratulates you for your epic discovery and then ask what awesome things do you think you could achieve with it
[Fire Android Development] Supersonic27543:
Can you please clarify on this!? :D It is straightforward to disable SELinux by editing the boot.img but I have a feeling that you are not talking about that. But still my initial statement should be correct: If the bootloader is not unlocked, the boot image cannot be modified.
[Fire Android Development] DragonFire1024:
Not entirely sure if you're being sarcastic or not. but Arie added to my post my point is is using that tool you could supposedly riad command lines back to the boot.img without actually altering it I guess?

---------- Post added at 06:59 PM ---------- Previous post was at 06:52 PM ----------

Depending on what tools you use they all do things differently including showing you which files are actually extracted or unpack from the images or system images. I have several of those tools and all of them show me different things aside from the basic stuff that we all look for in them. Carliv image kitchen gives you a boot.img-infos.txt. I was just doing a search on what's left of the command line in the HD 10 image. And came across a thread that says you can eeadd command lines to the boot.img using that file and they are added when repacked. I don't know if it's true or if it even works.
[Fire Android Development] EditedReality:
ok sounds cool could you confirm this works? it would be cool if it does

also does that mean we could get back booting custom recovery?
[Fire Android Development] DragonFire1024:
From what I've been able to read it does for some it doesn't for some. Well if it does work you know let's hope there's the potential that I can work on even non rooted varieties doubtful but I can always be hopeful. I've been trying various tools to edit the ram disk on the HD 10 and I've come up unsuccessful every single time. I think the farthest I've gotten in the flashing process in adb sideload was 51% and that would be just before it unconditionally patches the system. I have yet to be able to be successful in flash fire either.

Edit: not sure I'll be able to get much more done today

---------- Post added at 07:23 PM ---------- Previous post was at 07:18 PM ----------

I mean theoretically I would assume yes maybe I have to read up more on it.
[Fire Android Development] Rortiz2:
So if we modify the boot.img the fire will not turn on? Because if we want to disable the selinux we will have to edit the boot.img but if we flash it and the tablet does not start then it's not worth it.

I do not know if flashfire has an option to flash raw img's but that would be the only way to flash a boot.img.

I tried to unpack the fire's hd8 2018 boot.img with no result. CarlivImageKitchen and Michfood's Unpack tool do not work
[Fire Android Development] hwmod:
B

Nearly all you said above is correct, the exception being that I am almost sure the boot ROM (the one inside the chip itself) does not verify the first stage "preloader" (bootloader).

The first verification step is done by the "preloader" on the "lk" (little kernel in the UBOOT partition) about its signature, hash and its pairing with the correct preloader version.

For this reason I believe our primary target should be the first component of this "chain-of-trust", thus flashing the "preloader.bin" instead of the "preloader_prod.bin".

This has been tried before by me and others by using "dd" with the "eng" preloader directly on "mmcblk0boot0", yielding various unrecoverable "bricks" on the board.

I have no understanding yet on why it is not as easy as to flash the "eng" preloader in place of the "prod" preloader but somebody may have found out and tell.

.:HWMOD:.
[Fire Android Development] hwmod:
Also, on 5.x versions (were I did my testings), I saw that it is possible to add "cmdline" kernel parameters without having to re-sign the image, but only if you boot that image with:

fastboot boot boot.img

It is still necessary to recalculate the hash value and adjust some starting addresses but it will work perfectly yielding a full rooted device, no need of "su" and/or "su/managers".

Instead, if the "cmdline" modified image is written/flashed to the boot partition it doesn't work because "lk" has a chance to verify it after loading it and before jumping to it's start address.

In the "lk" binaries there are strings related to the fact that in DOWNLOAD_BOOT mode that verification is disabled, the string to search for says exactly:

[LK] boot mode is DOWNLOAD_BOOT
DA verification disabled
=> Downloading ...

DOWNLOAD_BOOT mode has a decimal value of 100, now I am trying to find a way to boot the device in that mode.

===== OTHER SPARSE INFO RELATED TO CURRENT INVESTIGATIONS (done by Dragonfire1024/diplomatic and others) =====

- the "Auto-root" mentioned in other posts, maybe triggered by values in "fos_flags", is also present it in the "vold" binary in "/system/bin"

- until now we found strings related to this feature in the following files: /init, /sbin/adbd, /sbin/multi-init (of ramdisk) and /system/bin/vold (of system)

- we have tried some "fos_flags" values (8bits) with "small to none" interesting behaviors, however from the binaries it seems "fos_flags" may be a 32 bit (0x%llx)

- other persistent memory areas in our devices are the 3 partitions KB, DKB and MISC which contain the LK environment variables (currently only "off-mode-charge=1")

- the KB and DKB contains the "idme" structure and its related values including "fos_flags", "dev_flags", "usr_flags", "unlock_code", "bootmode", "bootcount" and others

- the "idme" command has two sub-command: copy KB <partition> & "copy to DKB <partition>, so the full command for each of the two partitions should be as follow:

idme copy KB /dev/block/platform/mtk-msdc.0/by-name/KB
idme copy DKB /dev/block/platform/mtk-msdc.0/by-name/DKB

- it seems that those extra sub-commands will allow saving and persist properties through reboots for any of the properties set in a live session using "idme <name> <value>"

As always treat this information as a product of "guessing", not of "knowledge" and I cannot be held responsible of what happens to your tablets.

However I have tested those properties with different values and I used also the "copy KB" and "copy DKB" without noticing any destructive behavior.

Even if the results were of scarce interest up to now and without much success in "unlocking" either, I believe there have been signs of increasing probabilities.

I didn't expect it was easy though, but yes ... I am still positive about a future success, so don't throw your tablet :)

.:HWMOD:.
[Fire Android Development] DragonFire1024:
In our case it isn't about them not working. I've tried nearly a dozen unpacking tools, and have yet to get a boot.img to flash. So I'm pretty sure its not the tools. What about using the 'dd' command to push a boot.img? I've not tried that yet.

I still have a few more things to try before I give up on the boot.img though.
[Fire Android Development] diplomatic:
Actually, the boot ROM absolutely verifies the preloader. This is the cornerstone of hardware-based secure boot. If it didn't, the whole secure boot scheme would be near-useless, as you could easily modify the PL any way you wanted and get rid of any security in the system. The preloader is signed with RSA similarly to every other image blob. The chip actually has some efuse parameters set at the factory that control the verification step. Those include the SBC (secure boot check) bit and the hash of the public key used to sign the PL. The full public key is embedded in the PL image.

The engineering PL may not have been signed with the same key used for that device. Every model has a different key. Or you might not have flashed it to the right offset of boot0.

That's because the signature isn't actually checked when you do a 'fastboot boot...' The hash at the top of the boot image is not part of the signature. It's just used to check for image corruption. But the hash in the signature is entirely different.

That's interesting. But I think, after checking the source code, the DA has to already be loaded and verified by the preloader before getting to that stage in LK.

That doesn't matter what the bit width is. The known flags are all within the first 16 bits. The actual data is stored in ascii coded hex. This is how you give it to the idme command.

The KB/DKB stuff is just the factory-provisioned encryption keys for a device. It's Mediatek's implementation of a hardware keybox. Those keys are used for high level DRM stuff like Widevine, Amazon's DRM and similar. So they have nothing to do with fos_flags and other variables. And probably not that interesting as far as unlocking, etc. When you factory reset the device the KB blobs are copied to their partitions where they can be used by the OS, but their permanent storage is in the idme database. The KB stuff itself is encrypted in storage and is only decrypted (temporarily) and used within the TEE.

Also, any valid property you set with "idme <name> <value>" will be persistent. The idme tool flashes it directly to the boot1 region.

-------------------------------------------------
[MENTION=8165603]DragonFire1024[/MENTION], you are wasting your time trying to modify boot.img. The fact that it's signed and verified is what prevents us from getting systemless root, custom recovery, custom ROMs, etc. Changing even 1 bit of that image will fail the signature check because the hash will be entirely different. The signature encompasses the entire image, including the command line.
[Fire Android Development] EditedReality:
okay how about some type of hardware mod or somehow modifying it and keeping the hash the same?
[Fire Android Development] DragonFire1024:
Also has anybody looked into the possibility of using any of the old tools or modifying them to modify the boot image?

---------- Post added at 11:27 AM ---------- Previous post was at 10:41 AM ----------

I forget which unpacker, but there is something left in the cmd line on the HD 10:

cmdline = 'bootopt=64s3,32n2,64n2'

---------- Post added at 11:53 AM ---------- Previous post was at 11:27 AM ----------

So I figured out why at least for the moment but part of the problem is with the boot.img when we modify it. None of these tools actually unpack the ramdisk that's in gzip form which is inside the split image folder. However when I was looking up this problem I discovered another device which also the same problem. The Zenfone. it also direct me to another unpacking tool that supposedly fixes this issue when unpacking and repacking the boot.img...andimgtool. I haven't tried it yet though. I will when I get home. https://basketbuild.com/filedl/devs?dev=dgadelha&dl=dgadelha/ASUS_T00F/Tools/AndImgTool.exe
[Fire Android Development] DB126:
Lol - doesn't work that way; if it were that easy device (and transactional) security would be a joke.
[Fire Android Development] DragonFire1024:
That's a good sign. If it works, then maybe I can get it to flash. It's progress at least.

The fos_flag.sh we've seen. However it's listed as init.fos_flags sh in the etc of system. The one thing I noticed is dexopt_boot. It is NOT in the sh that's in etc. No clue what it means either. [MENTION=1564548]Dipl[/MENTION]imatic might know.
[Fire Android Development] hwmod:
What I meant is that neither "preloader.bin" (engineering) nor "preloader_prod.img" (production) contains Amazon Lab 126 CA certificates as is instead for "lk.bin", "boot.img", "recovery.img".

[root@ns images]# binwalk preloader.img
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 Mediatek EMMC Flash Image Version 1
512 0x200 Mediatek Boot Header Version 1
532 0x214 Boot section Start 0x800 End 0x1EC00 Load-by-Bootrom
2056 0x808 Mediatek File Info File Type: ARM-Bootloader EMMC-Boot-Region Signature Type: SINGLE and PHASH Load Address: 0x200D00 File Length: 123740 Maximum Size: 131072 Content Offset: 0x300 Signature Lenght: 292 Jump Offset: 768 POST_BUILD_DONE
122548 0x1DEB4 SHA256 hash constants, little endian

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 Mediatek EMMC Flash Image Version 1
512 0x200 Mediatek Boot Header Version 1
532 0x214 Boot section Start 0x800 End 0x1EC00 Load-by-Bootrom
2056 0x808 Mediatek File Info File Type: ARM-Bootloader EMMC-Boot-Region Signature Type: SINGLE and PHASH Load Address: 0x200D00 File Length: 123740 Maximum Size: 131072 Content Offset: 0x300 Signature Lenght: 292 Jump Offset: 768 POST_BUILD_DONE
122548 0x1DEB4 SHA256 hash constants, little endian

Ant that is the reason such tools like "Mediatek DA Tool" exists (alias "fbtool" or "fastboot tool"):

Mediatek DA Tool

This doesn't mean security is easily fooled because we can't flash the "preloader" partition, since "fastboot flash" commands doesn't work on locked hw.

Once the device can be "rooted", the "preloader" can be simply written to the "mmcblk0boot0" partition by "dd" or "cat".

The boot ROM will still verify the "preloader" but using the above "DA Tool" will allow for custom signed "preloaders".

That is the point were I believe that "chain-of-trust" can be interrupted, later will be harder (also still possible).

I may be wrong but that's what I understand by reading the documentation of the above "DA Tool".

.:HWMOD:.
[Fire Android Development] DragonFire1024:
I'll post some imgs of the HD 10 later when I get home. If this holds true, I hope the HD 10 has the same ability. Hopefully the boot.img tool I discovered while on break last night will yeild a result. One report so far says there's some hope.
[Fire Android Development] NFSP G35:
The device can be rooted via a hardware mod though...
[Fire Android Development] DragonFire1024:
So far only the HD 8 2018 though.
[Fire Android Development] diplomatic:
Yes, I understand exactly what you meant. Believe me, I know what I'm talking about. Sorry, there's no free lunch here. I'm no stranger to signing a preloader. I have successfully modded and signed a PL image for another device. That was possible because that tablet used the default MTK signing key (i.e. the vendor didn't bother changing it from the known RSA key pair), something that is not the case for FireHD. The mod I made was to change embedded DA verification key so it would work with the default SPFT DA. I have also tried to self sign the PL for my Asus ZenPad. That failed to boot completely as expected, because the chip uses a custom key. So I'm pretty familiar with the structure of the preloader as far as its security goes. I can tell immediately whether a PL image uses the default key or not or if two devices are signed with the same or different key.

The tool I use to sign preloaders is the actual MTK tool used for signing during the build process. It's called PBP, and you can check it out here: https://github.com/yos-two/mt8163-v...oprietary/bootable/bootloader/preloader/tools . I imagine the DA tool does something similar. But it does not bypass security in this part, I can pretty much guarantee you. It even alludes to that in the doc:

3.2 usage with secure chip (enable DAA)
command : fbtool -a auth_file preloader lk

Generate an auth_file which contains the corresponding public key of private-key.pem (private-key.pem is used to sign preloader)
(just like SP Flash tool).

IOW, the auth_file is not YOUR custom generated file. It needs to be the file corresponding to the key embedded in the chip. (And I think they meant SBC, not DAA.)

And yes, I'm very aware of how to use dd to flash partitions. But being able to access the raw emmc, either through root, fastboot, or direct HW access, it not what boot security rests on. If it did, it would be a bad security design. Flashing something is actually trivial when compared to cracking RSA 2048-bit encryption. That's why the root of trust IS the chip itself.

Lastly, the PL does not contain the formal x509 root certificates that LK has. It doesn't use the openssl code that can process them. Instead, it has raw public keys. (I believe it's the same key as in those certificates.) Binwalk will probably not detect them, but you can spot them with a hex editor if you know what to look for....
[Fire Android Development] DragonFire1024:
Binwalk did extract certificates from the lk for me on the HD 10. Two if I recall.
[Fire Android Development] hwmod:
Correct the "lk.bin" (UBOOT) should contain at least two certificates to be able to cope with "eng" or "prod" chain of trust (in Amazon Lab 126 scheme).

Other vendors may choose a different scheme than that used by Amazon Lab 126 (production or engineering).

.:HWMOD:.