yashsingh1/xdaforums huggingface dataset:
[Fire Android Development] DragonFire1024:
So I managed to look inside the amz.rsa certificate using keytool. The amz.rsa certificate matches the cert.rsa certificate in at least one of the Amazon system apps. The tl1.rsa key is signed by Google so it's an official key of some sort.

There is an ota.cert in /system/etc/security. It is releasekey.x509.pem. also using key tool I was able to determine the release key is the same key used to sign the amazon update.bin. Now if I understand correctly, if we sign zips using this key, while in recovery we can choose update via adb and sideload whatever is signed with this key?
[Fire Android Development] diplomatic:
I'm not sure how safestrap works or what the catch is. But if that's the only hurdle, you should be able to start it. I assume it's an executable or script that launches it, right? So why couldn't it turn off selinux with 'setenforce 0' under root priviledges? But I think there's some other obstacle(s) to it. In any case, tinkering with selinux policy will not make it permanent unless you can change the boot image. It's always going to be loaded from /sepolicy*.

OK, first of all, what do you think is the difference between "turning off" and "completely disabling" selinux? I take it you're talking about permissive vs disabled. The only difference as far as I'm aware is logging. Permissive mode will not prevent you from doing anything that you can do in disabled mode. It will simply log any restricted actions instead of stopping them.

The thing about ro.build.selinux ro.boot.selinux is weird. According to init source code, that should disable selinux when the policy is reloaded after /system is mounted. I wonder if something else is changing that property. What is the runtime value of ro.build.selinux ro.boot.selinux?

*If you want to set an alternative policy on a more persistent basis, I think there's a way to do it with root. According to source code, sepolicy can also be loaded from /data/security/current/ instead of from root directory. If you put your modified policy there, it may be loaded from that directory...
[Fire Android Development] DragonFire1024:
According to getprop and settings database editor there is no 'ro.build.selinux' but there is another ro.boot.selinux according to both and it is enforcing. The build prop configuration is stock on this device and the Fire 7 if I recall. So it's not getting the prop from the build.prop
[Fire Android Development] diplomatic:
Gah... ro.boot.selinux is what I meant of course :)

Well, I'm not sure then.... it could be that the property is loaded too late because it's on /system rather than in default.prop.
[Fire Android Development] DragonFire1024:
Why doesn't that surprises me? Just like amazon to just switch things around...
[Fire Android Development] k4y0z:
Just to add my thoughts:

- Playing with SELinux won't get you anywhere, it won't help with unlocking the bootloader.

- We already have a way to disable SELinux (check my code here: https://github.com/chaosmaster/ford_selinux_permissive) this is also used by the available Custom-ROMs.

- We can't modify anything inside the initramfs (including build.prop/default.prop), if we could, we wouldn't need to unlock the bootloader.

- The certificates you found won't do anything unless you find the matching private-keys (which is very unlikely)
[Fire Android Development] DragonFire1024:
If device_unlocked really does unlock the device, then you wouldn't need to unlock the bootloader...at least not on Amazon devices. Let's just say for a moment my back door theory is right. What if even Amazon doesn't have the keys? What if that's on purpose? If they gain full device access through the selinux policy, the boot loader wouldn't need to get unlocked, at least not how we assume they get access.

I have to convert the rsa certificate i found and run it through the decoder app i have. It will throw two keys at you, a 'pem key' and 'public key'. I believe PEM is the one we seek? Having the proper x509 key however does allow the flashing of roms in flash fire though. It also explains why I haven't been a la to flash a rom properly yet.

Edit: any time I have mentioned seeing references to images being flashed or hints of private keys, it's always been mediatek references. I've only ever seen Amazon tools being used by the type of 'back door' access iby what looks like amazon and that weird uid and pid.
[Fire Android Development] k4y0z:
I don't know what you mean by unlocking the device, but for me that is a synonym to unlocking the bootloader.

This variable will not get you there, it is likely populated by an unlocked bootloader using a kernel_parameter such as

androidboot.unlocked_kernel=true

PEM is just a format for certificate/key.

The certificate will only include the public key.
[Fire Android Development] DragonFire1024:
If it has anything to do with that, which I still don't think that is the case, if I can get it to persist as on, then maybe we can do something in fastboot. Also, we would almost certainly see this variable on another device which so far just amazon tablets.

Then there arises another oddity. In secure settings, there is a variable for an 'update certificate'. This doesn't match the one in the update.bin or in etc/security. It should in theory match those ones correct?
[Fire Android Development] k4y0z:
You will not be able to "persist" the value without unlocking the bootloader/fastboot first, which makes it useless.

Amazon may use different certificates or just store them in different locations.

When comparing the certificates make sure to compare the fingerprint, not just the files.
[Fire Android Development] DragonFire1024:
There is a way to persist the value if I can successfully build the required components to restore the commands.

I will post the rest of my results regarding the certificates tonight or tomorrow. I didn't check the fingerprints, but they were available.
[Fire Android Development] diplomatic:
But the result of that will be the same as you setting the value manually, or having some script or app set it for you.
[Fire Android Development] DragonFire1024:
I give up. If no one is going to pay attention to anything I post, I give up.
[Fire Android Development] DragonFire1024:
So I spent a lot of time trying to get at least the 5.1.1 branch and it's dependencies. I had tried and tried over the past few years, and have failed miserably. No more of that. I got it all downloaded in it's glory. The real neat thing about having the raw source in file form, you can see what's inside everything before it's built. With that said, ive seen inside the stock aosp keystore and grabbed the keys. There are 16 in all, including 3 pk8 keys; DSA, EC and RSA privkey_pk8.der. The rest of the source codes keys are here too.

Now I've looked at everything I can look at in the certificates I found on the HD 10. I did a lot of comparing with ones from different devices. If you look at the CA of the keys "signed" by Amazon and Google, all Amazon did, as they have done right to the user level, is replace a few words here and there. A few characters or codes. These are no different. Where it said Google, Amazon replaced it with Amazon. They didn't bother to change the local either. I know a few apps that you can download and change the stuff they did. So it looks like they didn't even really "sign" some things. They just destroyed the original signature.
[Fire Android Development] DB126:
Good strategy. Keeps it simple.
[Fire Android Development] DragonFire1024:
Not sure it really benefits them. If it's that simple, couldn't we just change them too? Anyways here is a link to the folder of the certificates/keys and private keys from our branch; android-5.1.1_r18 LVY48F. Now the kicker would be if that's all amazon changed. How do we compare the keys public vs private? https://drive.google.com/drive/folders/1KzWh2NuKLOLeuM_NsB9Px2wo_oDp8hoO?usp=sharing
[Fire Android Development] DB126:
No additional processes to sign stuff they don't intend to change or maintain.
[Fire Android Development] DragonFire1024:
Pretty much defeats the whole purpose of signing anything. I can only decode the RSA private key of the 3 I found in the source code. When I put it onto the tablet I was immediately asked if I wanted to install it. Of course I said yes, but it didn't install. That didn't surprise me though. What did surprise me was the other two, the DSA and EC keys would force close the app if I tried to import them. I'm also given the option to change the passcode on the RSA pk8 as well as create a CSR pair from it that can be used to sign other things. Looking at how amazon signed their release key (or lack there of), they likely used a source pk8 to sign other things with. All you have to do is edit the fields. Iincluded a screenshot of the private modular output of the RSA.pk8. if anyone is interested in the app I'm using it's called '{Dory} Cert' available on the play store. If you tap on the settings tab on a decoded certificate, sometimes you can edit the fields, including adding, editng or removing a CA.
[Fire Android Development] DB126:
Not really - depends on intentions and where items in question reside in DiD schema. Gaining access to an outer vestibule may or may not be significant (or at least perceived that way which can be a dangerous assumption).
[Fire Android Development] DragonFire1024:
I'm not sure I entirely get what you mean in regards to gaining access to an outer vestibule.

I've managed to use openssl to extract the 'private certificates' from the three pk8 I found in the source code. I did try flashing them but got unlock code errors. Didn't expect it to work nor on the first time and it didn't. Let's pretend for a second it will work. I'm pretty sure I have the key format wrong. I will upload them later or tomorrow. If Amazon did half-ass the certificates then there's the possibility we can go into them and change the values like they did and possibly gain access to ADB sideload? Also are the release keys the same as the platform keys? And if not why weren't they in the source code? I mean it really would be hilarious if that's all we had to do was change a couple of values.

---------- Post added at 10:34 PM ---------- Previous post was at 10:26 PM ----------

Hey [MENTION=5749760]ggow[/MENTION] question. On stock FireOS for the version you make the ROMs for, what is the key in /system/etc/security/otacerts.zip? Release or test?
[Fire Android Development] ggow:
The keys in here are used to verify an ota update. These are public keys, likely RSA type. Regardless of whether they are release or test, these won't help unlock the boot loader etc.
[Fire Android Development] DB126:
Simply means applying protections proportional to perceived risk which is an indirect assessment of asset value. One may choose not to invest significant effort on outer ring defenses if the layered protections become progressively stronger and/or if compromise is of little consequence.

Eg: I go to great lengths to protect my bank account credentials. In contrast, the password to the local fish wrapper lives in the browser.
[Fire Android Development] DragonFire1024:
That I am aware of. Trying to determine whether it was a release or test key in the otacerts folder. But it will help in determining if a ROM can be flashed or not.
[Fire Android Development] DragonFire1024:
I had a look at the boot.img decompiled and looked at the split. In the folder opposite of ram disk and looked at the cmdline img. There are a few commands there I think can be used in fastboot to override the kernel command line. One of them I've seen before, and the value always seems to be tty00 but no idea what it does or what it's for.

androidboot.console=tty02

I don't have it in front of me so I forget the other one. I looked at most of the files there and the one above plus the one I forget are the only 2 I found.
[Fire Android Development] DragonFire1024:
My last post reminded me of this. I forget where it's located and can't find it right now but there a file called multi_init. There are some what look to be shell commands. This may be interesting:

/proc/idme/fos_flags<6>amzn_fos: ADB: flags=0x%11x
androidboot.prod=0<6>amzn_fos: ADB: eng_device=%d
androidboot.unlocked_kernel=true<6>amzn_fos: ADB: unlocked_kernel=%d
<6>amzn_fos: ADB: auto-root succeeded

If this isn't enough evidence of an alternate way of unlocking the device besides flashing keys amazon may or may not have access to, then I don't know what is. Accompanying screen shot.

The other one I saw in the boot img command line was

androidboot.hardware=bowser

Edit: this makes a clear mention of the MISC partition, but if I recall, when I decompiled it, there was nothing or filled with 0s.
[Fire Android Development] DragonFire1024:
Upon further research, it appears these are kernel command lines and since I am looking at the decompiled boot.img of the HD 10, 5.6.1.0 2017/2018, am I safe to assume these are active? So one can presume we can interact with them while the device is in fastboot. So far these are the few I found in the boot image's

boot.img-cmdline

from IDA Pro (direct copy/paste. Pay attention to the characters):

mem=1G
androidboot.hardware=bowser
console=ttyO2,115200n8
androidboot.console=tty02

This OP on the use of ADB and fastboot makes reference to the the console with a number different from the one I found and appears to be common amongst a large number of devices. This reference is at the very end of the post. Here is the MakeFile for the Amazon soho for another reference:

The command for kernel command line override has changed since then and is now:

--cmdline CMDLINE

Now that we have established that, what can those lines do if anything? Perhaps they moved the commands elsewhere because they clearly use them to unlock the kernel and guess where that command I posted earlier is seen (now that I found the file): /sbin/multi_init. We have execution of the command to unlock the kernel and a binary that executes it. Clear as day. But does this seriously say Amazon has to root themselves to get to the bootloaders et al? Because that's exactly what it looks like. I posted the command lines below. In the same binary, there is also a few lines where they put the device into factory mode, through recovery, but I didn't get those lines yet.

Remember when I said I believed Amazon uses a special UID and PID with one permission, higher than superuser to get access to the device? Now here is the command lines in a more 'reader friendly' format:

(likely had a cd in front of this) /proc/idme/fos_flags
<6>amzn_fos: ADB: flags=0x%11x androidboot.prod=0
<6>amzn_fos: ADB: eng_device=%d androidboot.unlocked_kernel=true
<6>amzn_fos: ADB: unlocked_kernel=%d
<6>amzn_fos: ADB: auto-root succeeded

Doesn't sound too crazy now does it? My theory in a nut shell. Amazon doesn't have the keys to unlock the kernels. Probably never did. Probably why they haven't fixed the HD 10. So Amazon has a special UID and PID to access the device while in hand and we now appear to know exactly what those are; UID=amzn_fos with a PID=<6>. How they get access is probably tied into the app, com.amazon.imp as it is spoken of in a few other files and has the permission 'AMZN_KEY'. Once granted access, they for some reason have to root themselves (maybe to persist a reboot??) which completely disables SELinux and they run the commands to override the kernel and unlock the boot loader. They don't have keys, at least not the keys we think. Their key is 'amzn_fos'.
[Fire Android Development] DragonFire1024:
Hello? Anyone? Not even a little criticism? Silence speaks even more volumes. So just to throw some more icing on the cake I did 'ps' (process ID) in a shell and found it quite odd that 4 and 6 were missing. Not sure what 4 could be but if 6 is missing, we know why. If amazon does have keys in the usual sense, and this is how they access the devices, we now know what the amzn_dha_tool does. It would stand to say thats where the private keys are verified when they do access these. I've also looked In the IMP app. Very very Interesting.
[Fire Android Development] diplomatic:
[MENTION=8165603]DragonFire1024[/MENTION]: about the lines in multi_init, yeah, there may be something to that. But you have to look at init, not multi_init. multi_init is only run under factory or other exotic boot modes. Fortunately, init seems to be the same thing as multi_init at least as far as those strings you found go. What this whole thing looks like is that init might start adb in root mode or behave differently based on some flags inside idme (the data in mmcblk0boo1), or on the kernel command line. It might be worth investigating further.

The other stuff you posted makes little to no sense:

We can't change the kernel command line with fastboot or otherwise. That has already been talked about in this thread. They already patched that option a long time ago.

There is no user higher than root. Amazon engineers can easily access anything they need with root on their debug/factory OS.

Amazon didn't lose their keys. That's just nuts. They might as well have lost their FireOS source code. Even if a key was compromised, they can generate new ones in a firmware update.

The UID for 'amzn_fos' (factory OS?) may have some special priviledges, but it's not higher than root.

The "missing" PIDs are completely meaningless. A PID is just a number that is dynamically assigned to a running program by the kernel. A process is never guaranteed to have the same PID, and most often it will not.

Your idea of "keys" and the definition of an RSA key are very far apart. Everything you want to crack is secured with RSA: boot images, update packages, unlock codes, etc. And you still have not understood the basic principles of public key encryption. There is no "flashing of keys" and no key will be called 'amzn_fos'.
[Fire Android Development] DragonFire1024:
Looked at the boot image and I can't find multi_init anywhere. It's not in sbin. It also doesn't have the same date as the fireOS version of March 22. The files in sbin are all that weird December 1969 date again. I looked everywhere for the binary on the boot image and there's nothing. I can't even get it to execute in a shell as it says 'not found' even if I cd into sbin. I also tried to Google search for amzn_fos and fos_flags and again this seems to be a amazon only thing and returned nothing useful or at least nothing we don't already know. I also took a look at all the 'acct' folders and it doesn't help if we don't know the numerical uid of this 'amzn_fos' user. Also in those folders, some of those UIDs do appear to be issued a specific PID...UID_1000 for example has a PID assigned of 25095 (PID_25095) and PID_4582 (screenshot attached), but none of them 6...assuming it had mattered.

If we can't do anything with the kernel command line, what about the fos values?

I never said they lost keys. But if they have this uid that can do these things, they don't need keys technically. I mean this can't be any clearer of a picture of using a shell for some kind of access for whatever they need it for, clearly to unlock the kernel. So the next question is this. If they kernel command code override doesn't work anymore, how would amazon use that command to unlock it? Where else besides fast boot could this happen if multi_init is to be believed? How would one even log in with this amzn_fos and wouldn't it be listed somewhere else? It's worth noting that the app com.amazon.imp also mentions different device modes like eng, user and userdebug among other oddities I've never seen in an app before. That one permission also stands out, amzn_key. So for a company that supposedly has all the access they need, this would seem excessive. But also smart as hell. If this is how they unlock the kernel, this may explain why we got root but not unlocked. This method of unlocking would almost make it impossible to ever unlock the device unless we access this UID. So it locks us out while in a way locking out amazon too. Not everyone would have this access or even know it existed. So far of all my research on this theory, the multi_init is the only file with a brief mention of a mystery uid. So for once I'll admit I'm a bit lost here as I'm not sure how to proceed, or if there's even a way to do so. I would appreciate any advice you may have.
[Fire Android Development] DragonFire1024:
Screen shot. I'll look over the rest of multu_init later. As I said it does show the device from being booted to getting into factory mode, but if I recall, it's just as cryptic as the amzn_fos lines of commands and doesn't actually tell us the commands it has them commented out like amzn_fos lines.
[Fire Android Development] DragonFire1024:
In the meantime, as I continue to try and build a rom, I noticed in /system/etc a .sh called 'init.fosflags.sh'. This might be part of what multi_init refers to. Snippet below:

#!/system/bin/sh
PATH=/sbin:/system/sbin:/system/bin:/system/xbin

export FOS_FLAGS_ADB_ON=0x1
export FOS_FLAGS_CONSOLE_ON=0x4
export FOS_FLAGS_RAMDUMP_ON=0x8
export FOS_FLAGS_VERBOSITY_ON=0x10
export FOS_FLAGS_ADB_AUTH_DISABLE=0x20

# General FOS flags, shared across devices
fosflagsfile="/proc/idme/fos_flags"
# Optional device specific flags
devflagsfile="/proc/idme/dev_flags"
# User controllable flags (privilege not required to set)
usrflagsfile="/proc/idme/usr_flags"
# adb closed device
adb_cd="/system/etc/adb_cd.sh"
WIPE="/system/bin/wipe_fos_flags"
FACTORYMODE="/data/system/FACTORYMODE"

There's factory mode again. This will let us define at least usr_flags? Not even sure what that means. Maybe you guys can describe what this all means.
[Fire Android Development] Supersonic27543:
If amzn_fos starts adb in root mode based on idme values, will it be possible to flash a long unlock file to overwrite idme fos_flags and get root? Is the idme partition in the same region as unlock partition?
[Fire Android Development] diplomatic:
It might be. ;) But I suggest not getting ahead of ourselves. We first have to find out if setting fos_flags does anything at all. I examined adbd, and it looks like it checks for idme fos_flags as well as the kernel command line (/proc/cmdline) for unlocked_kernel. Now we know that 'androidboot.unlocked_kernel=true' makes adb go root. The question is, is it either/or or both the cmd line and fos_flags? Or is fos_flags something completely different? DragonFire, you want to try this out?
[Fire Android Development] DragonFire1024:
Sure. What should I do? I have a test tablet so bring it on :D

Edit: I'll upload the .sh so you guys can see the rest
[Fire Android Development] DragonFire1024:
Script posted. Just download it and remove the .txt extension.
[Fire Android Development] DragonFire1024:
I just noticed something. In secure settings there is config_update_certificate. That's not news, but the same certificate is in the same place on my Galaxy S4. If I recall this doesn't match otacert.zip. so what does it match?
[Fire Android Development] DragonFire1024:
One last goodie. There's more to be seen in multi_init that I haven't yet explored. I do recall several lines of shell commands/access to factory mode. It showed the steps right from regular boot all the way to factory. So I think there's more to be found. Have a look. Just remove the .txt extension. I hope all this is looking as promising as I'm hoping. This could be a long term thing hopefully over more than just a tablet or two. This fos stuff likely goes across all amazon devices.
[Fire Android Development] DragonFire1024:
This is in the script. This would be why we can't read these values:

# Ensure input is only hexadecimal
in_size=${#FOSFLAGS}
FOSFLAGS=${FOSFLAGS//[!^a-fA-F0-9]/}