yashsingh1/xdaforums huggingface dataset:
[Fire Android Development] Supersonic27543:
I have been experimenting with the Safe Mode for some time now, and here are the details I found so far: (Didn't post them because it didn't look useful then)

1. When you enter Safe Mode, I think the apps are just hidden LOL, still you can press recent and you'll see the apps that you were running before you rebooted. Tap one of them and it will open.

2. There is a value in settings database called SAFEMODE_EXPERIENCE with a value of NORMAL. Is there any way to check the values that the system responds to, now that we have root?

3. When you enter Safe Mode and reboot to the normal mode all your accounts (like Google), maybe except Amazon, are gone and you'll have to sign in again.
[Fire Android Development] darkensx:
just curious but has there been a bounty put up for unlocking the bootloader? maybe that might attract some more attention i know sometimes it does.
[Fire Android Development] Supersonic27543:
;) I don't think so. It could be worthwhile to try that if the forum mods are okay with it.
[Fire Android Development] DB126:
Bounty posts do not violate XDA rules.

That said, bootloader unlock hacks are unattractive projects as undiscovered exploitable vulnerabilities on legacy hardware are exceptionally rare.

Look around...see that happening anywhere?
[Fire Android Development] DragonFire1024:
Quite possible I accidentally discovered and got the tablet to go into factory mode last night. I can switch, at will now, between 2 screens at recovery. If I hadn't have made one mistake, might have gotten a real USERDEBUG out of it. It only boots to white Amazon logo. But every thing else works including recovery
[Fire Android Development] darkensx:
so is it just bootlooping at the amazon logo? :confused: "But every thing else works including recovery" you mean its booting twrp cwm ect or just the stock recovery as it supposed to do that. could you explain how you got factory mode or heck a video with the tablet doing the mention things may prove useful.
[Fire Android Development] DragonFire1024:
Meaning I could still use recovery and fastboot. The logs showed the rest dialing home and the system never picks up. So it would hang at the white Amazon logo. I don't know what mode it was in yet or what it was doing. Some of what I posted in another thread showed stuff on the logs I've never seen. A Google search was useless and only found one reference to what I saw and it was all in Japanese or Russian.

See this screen shot of the weird log entry https://xdaforums.com/showpost.php?p=78002495&postcount=910

Only a few Google hits on the letter and number combination https://www.google.com/search?q=kpd...9i58.1306j0j4&sourceid=chrome-mobile&ie=UTF-8

I could switch between this screen and recovery screen freely when in that mode. I haven't tried on fresh stock though. https://xdaforums.com/showpost.php?p=78001977&postcount=908
[Fire Android Development] DragonFire1024:
On the HD 10, there is /vendor/data and it contains two RSA certificates; amz.rsa amd tl1.rsa. I am able to run a command and get some info from these.

First I converted the CERT.RSA (amz.rsa in this case) to a standard pem file:

openssl pkcs7 -in amz.rsa -inform DER -print_certs -out cert.pem

Then I can extract the public portion of the pem:

openssl x509 -in cert.pem -pubkey -noout

Which returns this:

-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEArGDa/hyWJoPkam5bXClF
8PGnXvjyaPZ5lMOEGpNmrseEqxuvfvjJDpVhYnL7xxU1pHiBL4chY+DAelYsblrN
pHXxLseCEro5X/kLIbyMDk/8kny9zsaV2RycNpSBp6IwlW/zFQ9D5bowfDRVWAlf
UsjYML/Tsp4PTIHn4s9xVNwaSue2ZHqYMHklb6UH7vrajKscWcgiDmX+7gwPRvDC
AQ34dJ1AEVCPKuktc9SxYkfl8GjOgmiX/2/hmGpfKWkQq0AvjJYl3t16z0DqFfEb
AS9v3hVpUn12BBOdPX8HKnF0fGvw3gPk/oT6JGqc5YH0g9CSLhAiXnMuYy6YhhZE
vztZGZJwhqKs5EHa7Gv6I32aYepKUpEm99Vd3nQDm62Nv6HVxRuchF9QSySJOihX
ICsbbpy58dB0YUC1jEr/GTRGzSCx0DRiWLM9yO1vxFTYcuJV6MxtNXzESDsUc63y
C7pSQ5ebYzdK6YnYwRtGoTbGmMUlWFk71bvLutO1xCp0orkTh9A9lS3YQJCqAzzD
ayC4eBcTVEsqcElyX3RdnShJyeAZn/bCe7ACgx2+QYO4fK8xGFK8RwkTRBeo9PSI
fwLyxVDP0bzfa/uhUa70N+S7Z6pIMVIkwgUr1uLVwtr1M+AOc4Fohd0w7Bb2sMXr
WHa7L2GZhrow+61oE5xMCMcCAwEAAQ==
-----END PUBLIC KEY-----

This prints the cert:

openssl pkcs7 -inform DER -in CERT.RSA -noout -print_certs

And displays this:

subject=/ST=Nevada C=US/OU=Java Object Signing O=Amazon Services LLC L=Las Vegas/CN=Amazon Services LLC
issuer=/ST=Nevada C=US/OU=Java Object Signing O=Amazon Services LLC L=Las Vegas/CN=Amazon Self-Sign CA

This isn't for OTAs, because the release key is stored in /system/etc/security/otacerts.zip. What would those two keys before and why are they in /vendor? It's worth noting, none of these match the public key in amzn_dha_tool.
[Fire Android Development] hwmod:
Most probably these are the keys developers need to use for building and distributing their signed APPS (apk).
[Fire Android Development] DragonFire1024:
Can't find much of anything doing a search for the amz.rsa key. But what I have found is the CERT.SF supposedly contains a private key the cert.rsa key uses to verify. But there is a public component in the rsa too if I am not mistaken?. I tried to sign an apk with the rsa and it either didn't work or i got a parsing error when trying to install it. I probably did something wrong but will try again tomorrow. So that's at least three certificates, so far, that are on device. I'm going to have to read a bit more about how to convert them into proper signing keys. But I didn't think there would be so many certificates to sign all these components.

The quote from here https://stackoverflow.com/questions...-in-meta-inf-cert-rsa-file-for-an-android-app but the responses just give advice on commands and not an answer to the above quote.
[Fire Android Development] DragonFire1024:
Found a few more in system/vendor/data in a folder called TTP. The Skype ones are self explanatory...But why on a device that can't use it?
[Fire Android Development] DragonFire1024:
So I've looked on other devices for this one and thus far i only see this on my HD 10.

In /sys/fs/selinux there is a booleans folder (this folder is on all the devices i checked) and it is empty except on my HD 10. The file inside says: device_unlocked

???
[Fire Android Development] DragonFire1024:
Guys. Everyone I need your undivided attention please. This might be it. This may be the key we have been seeking. However a once wise man said "these aren't the keys you're looking for" A true geek knows the reference. Now serious business.

Ok I did some research. So this Boolean folder is important. In fact this may be the jem we need.

In /system/bin you have two executables getsebool and setsebool. I'm going to explain this as easy as possible.

Let's play a little game. Unfortunately for this to do anything, you need to be root already i think.

getsebool -a

This will list any booleans set in the SElinux policy and their values (on or off). On the HD 10, there is one boolean present. At the moment, this device is the only one I have run into that has anything set in the booleans. I own about a dozen different devices (phones and tablets) all of them work and are either rooted or boot loader unlocked (only my Moto E4 isnt). Not a single one of them have anything in the booleans in this folder, except for this HD 10. It is wiped clean on every other device. HD 10 boolean:

$ su
# getsebool -a
device_unlocked --> off

Here's the fun part:

# setsebool device_unlocked on
# getsebool device_unlocked
device_unlocked --> on

However there is a problem with changing this value, even being root:

There is a way to change this, running a simple command. However I'm certain the bin file or files have been modified and the commands removed from the policy.

setsebool -P device_unlocked on

In a normal world, the above command would make the value we set persist upon a reboot. So why alter the policy? That doesn't make sense to me. I know as an OEM you can write said policy, but why go through the massive effort if only to leave this boolean in place? Now given this potential massive discovery, what does this now mean? Did I just do what I think I did? Was this really that easy?

References:

https://wiki.gentoo.org/wiki/SELinux/Tutorials/Using_SELinux_booleans

https://www.thegeekdiary.com/understanding-selinux-booleans/
[Fire Android Development] Supersonic27543:
Interesting. Fortunately there is an easy way to test. Just extract the update. BIN and take the boot.img and do fastboot flash boot stock_image.img and see what happens. :cowboy:
[Fire Android Development] DragonFire1024:
That would not work. The value would reset the moment the tablet reboots. So if this is doing what it says it's doing, this thing won't be rebooted until we find out what's going on and how we can exploit this. This is an intentionally placed boolean. So I'm theorizing the actual boolean file could be encrypted which might be why I don't see any on other devices. So this could be something that goes beyond Amazon tablets.
[Fire Android Development] DragonFire1024:
Question. Amazon clearly modified some bin files, like bootanimation. I replaced it with an AOSP bin. Would we be able to do the same with the getsebool and setsebool bins using a flashable zip in flashfire? I know replacing some while booted will brick you softly.
[Fire Android Development] DragonFire1024:
So the Fire 7 even with [MENTION=5749760]ggow[/MENTION] custom ROM has the same boolean and value. This time I got the log entry of the event. Can we jump or cry for joy yet?
[Fire Android Development] diplomatic:
If you want my opinion, I wouldn't get too excited about this yet. The reason is you're talking about a variable that exists only in memory. The changes you make to it are never written to storage. The entire /sys directory is not located on disk but is a pseudo-file system that exists only in kernel memory while the machine is booted. That includes selinux. The selinux policy itself is defined by a file inside the boot img ramdisk and is loaded once at boot time. And of course, we cant change that. So why would it persist when the text you quoted itself says it only lasts until the policy is reloaded?

You're hoping this will unlock the bootloader, right? Well, the bootloader doesn't know or care about selinux. That's strictly the Linux kernel's business. My guess is that the unlock_device boolean is related to this:

When the BL is unlocked, the option androidboot.unlocked_kernel=true is passed to the kernel. And then the kernel or something else sets the device_unlocked boolean to the value based on that parameter. In other words, it's more of a "reponse" value rather than a "cause" value. There may be some apps or native programs that read this variable to determine the unlock state of the kernel.

As a regular user, you can't access this file because of file system permissions. So until an exploit can be found to bypass this, I wouldn't jump for joy.
[Fire Android Development] DragonFire1024:
I can agree with that and figured most of it. The only thing that doesn't add up is why this variable exists, from my observations, only on these tablets. Isn't that folder supposed to be empty unless the other variables mentioned in reference are populated there? I don't think it unlocks the boot loader but poses a possible entry point perhaps? And the -P option, if it was working would or should persist the value. I went and committed the change and just an observation...in this directory the boolean file and the commit file are the only two that changed date. Everything else is December 31 1969.
[Fire Android Development] DragonFire1024:
Ok so after I changed the value, there now appears a constant error in the kernel/system logs. I held this back because I didn't think it was anything. Please see the section "Logging and Auditing". That entry appears in my logs...over and over and over (avc denial). Not a word for word match. http://selinuxproject.org/page/NB_SEforAndroid_1
[Fire Android Development] DragonFire1024:
Idea: the commands to persist this and other options exist as a separate bin file. Problem is we need the bins to be compiled for ARM. if that can be done, we might be able to push them to bin or xbin to regain control and persist the value. Of course that requires root.

https://forum-xda--developers-com.c...ybox-snapshot-building-android-t2857650/page1
[Fire Android Development] DragonFire1024:
Got Kali Linux up and running on my HD 10 again, like a charm again. Downloaded the required files to start building. Let's see what we can do. I will experiment using my Fire 7 at a later point. Right now I need the speed.
[Fire Android Development] diplomatic:
It's not just the binaries. I took a quick look at how the persistent variable system works. You can see the source code of setsebool here. You also need libsemanage, which setsebool uses to save your changed policy. But more importantly, you need some system within the OS which restores your variables at boot time. I'm pretty sure Android doesn't have that. In a Linux distro, those tools would save your modified policy to somewhere inside /etc/selinux on disk. And then I gather that some system service would restore it on boot up. This doesn't exist in Android. The selinux policy is loaded statically from /sepolicy, which is inside the boot image. This file is what defines the existence of device_unlocked, which you were asking about. So obviously, it is intended to be there.
[Fire Android Development] DragonFire1024:
Then why is it? It doesn't make sense for It to be there if it indeed didn't do something. I find it very hard to believe it does nothing given these tablets are the only known devices that have this variable or any variable present or set in this manner. So something is going on here.

What about init.d? There are scripts that do things like that at boot.
[Fire Android Development] DB126:
Not necessarily. These gizmos are positioned as cheap servants for Amazon's ecosystem sourced from whomever could meet price/performance/volume/... specs. Good chance they are sloppy detritus vs golden keys to the kingdom.
[Fire Android Development] DragonFire1024:
I get what you guys are saying and I understand. But in my experience with these tablets and given the hacks I've found, the way they moved things around ever so slightly, this just can't be a coincidence. I do agree with one thing though, this Boolean shouldn't be here. But it is and it's literally telling us to figure out why. If these tablets are the only devices to exist that have a set variable here, there has to be a reason. Too brush it aside i think would be, for lack of better terms right now, ignorant. If nothing was going on here, or this was an echo of times past, this would show up on another device somewhere. I've looked through dozens and dozens of search results and these tablets are so far the only ones with anything happening in this neck of the woods anymore. Even logs confirm something is going on. So we should be focusing on what, how and why.
[Fire Android Development] DragonFire1024:
I just wanted to add something. You once said in not so many words, flash it and follow it. This situation is not very different. Instead of a file, we have a command. It either case, they will or won't work, but there's a log of it somewhere, some kind of trail. We have a distinct log entry. Just one, but says dictinct things. Is there enough information to 'follow the money?' Regardless of what this may or may not do, its doing something. The only file in that that selinux directory I can read anything in is the one called 'policy'. The variable appears at the very end of that binary, followed by a lot of CX where x = numbers. I will get a screen shot later, but that too can't be a coincidence.
[Fire Android Development] despicablebapple:
That sounds like the selinux policy file which is currently being used (as it's in memory only). It contains what restrictions each user, process and executable (command). If you cross reference it with files you can't run it will tell you why. You will need to unpack it though, try copying to your computer then follow this https://serverfault.com/questions/321301

The file is described in a small bit of detail here https://source.android.com/security/selinux/build#selinux-files
[Fire Android Development] DragonFire1024:
It is now worth noting I've only seen this unlock variable in this policy on one other device, my XT907 Droid Razr M...and it's bootloader unlocked. I'll have to show that one later. It appears in the same spot too, but I don't recall if the code there after is the same.
[Fire Android Development] DragonFire1024:
So I was a little wrong. It doesn't say device_unlocked. I thought it had.
[Fire Android Development] diplomatic:
I don't know what the purpose of it is. And it may very well do something. As I said, it may be intended as more of an information variable rather than a switch for something.

Do you mean when I was talking about probing? Yeah, if you just want to experiment with it, sure, go ahead and play with it and see what happens. Based on what you posted, it sounds like you also need to set selinux to permissive, because your log says it's causing things to run up against selinux restrictions. Can you actually use it to escalate privileges to limited users? More than likely, this will turn out to be one of these "you need root to get root" kind of things....

The policy file you found is probably the kernel's interface to selinux. This is where /init loads the sepolicy file. As a root user, there's no doubt you can set that policy to whatever you want....
[Fire Android Development] DragonFire1024:
So in theory, whatever this variable does, it too would be able to he set as well, given it's in the same policy? So I guess the next step is to see what's inside. Though I was disappointed about my XT907, it was still interesting to see the same pattern where the variable is on the tablet. It's going to be interesting to see what's in here.
[Fire Android Development] diplomatic:
[MENTION=8165603]DragonFire1024[/MENTION], yes, I'm pretty sure that as root, you can load any policy you want, and also write to any config file in /sys/fs/selinux. If you understand C, take a look at this. It is the policy loading code used by /init. Those routines ultimately call this system call. /sys/fs/selinux/policy is always going to look similar on every device because it's the same format.
[Fire Android Development] DragonFire1024:
Yes I know that, with small variations based on OEM. So we can replace this file/policy entirely? Now I'm even more interested to see what's going on. If policies are similar, then I wonder what's going on in that spot of it. I mean they could've put this variable almost anywhere in there. I wonder what makes that spot special

.
[Fire Android Development] DragonFire1024:
Addition: maybe it's the key itself. If this is indeed linked to the kernel, perhaps something can be done via fastboot. The DHA and DRM tool is mention a few times and a few other Amazon related things about apps. Time to play.

---------- Post added at 12:03 PM ---------- Previous post was at 11:30 AM ----------

Initial 'I can't wait until I am done with the first few sections' findings.

1. I have come up with three sets of numbers so far. Any reason why serials to a Lenovo Kernel would be here? Specifically the Venom Kernel:

AD5820AF_device
LC898122AF_device
BU64745GWZAF_device

2. Key

keystore_key

keystore

keystore_exec

keystore_service -These are or should be shell commands? If so, it looks like there are a lot of command line here.

There are references to all kinds of files and props, amozon stuff like amazon_kor, amazon_ecs_app, amazon_ota_app. There is so much here.

---------- Post added at 12:41 PM ---------- Previous post was at 12:03 PM ----------

Unfortunately, or maybe not, I don't know. This is the exact start point of device_unlocked. Exactly under the second row of red numbers. This is the line where that variable is:

6F6C6E755F656369h, 164656B63h, 200000001h, 1307300000000h
[Fire Android Development] DragonFire1024:
Idea: device_unlocked is all alone. It needs company. I see a lot of persist props in the policy. Any way we can prop out device_unlocked? What if all we need to do is set the policy of it to on? If prop, how would that look?

persist_device_unlocked

Nothing here has a value. If one could set a prop in the policy to persist, where would the value get set?

Edit: I thought LK stood for 'Little Kernel'? Is it really 'Lenovo Kernel'?

Edit edit: on the persist note. I noticed during installation Kali compiles libsemanage for armhf. I have read some instances where a /bin file was taken from one of these Linux distros and used them on an Android device. It is arm compiled after all. Is that even a possibility?
[Fire Android Development] DragonFire1024:
So I have compiled some arm binaries and installed them into xbin. Take a look here: https://github.com/xmikos/setools-android

-seinfo

-sesearch

-sepolicy-inject

USAGE:

sepolicy-inject -s <source type> -t <target type> -c <class> -p <perm>[,<perm2>,<perm3>,...] [-P <policy file>] [-o <output file>] [-l|--load]
sepolicy-inject -Z type_to_make_permissive [-P <policy file>] [-o <output file>] [-l|--load]
sepolicy-inject -z type_to_make_nonpermissive [-P <policy file>] [-o <output file>] [-l|--load]

For example if you want to allow
[Fire Android Development] diplomatic:
[MENTION=8165603]DragonFire1024[/MENTION], ok, that makes a little more sense than your previous 2 messages, which didn't really explain much. But I'm not sure what you're trying to do here. What is your strategy? Why do you need to mess with selinux when you can simply set it to permissive? This will disable any restrictions caused by it. I did say you can set selinux policy to whatever you want as root. But why you would actually want to do that rather than disabling it, I have no idea. You can also toggle 'device_unlocked' with setsebool, as you already found out.
[Fire Android Development] Supersonic27543:
But SELinux status changes won't persist after a reboot, right? When [MENTION=8714462]LoneFlux[/MENTION] contacted the creator of Safestrap he said that it is only possible to install Safestrap if SELinux is permanently set to permissive. So if there were a way to do that I think we'll be able to install Safestrap.
[Fire Android Development] DragonFire1024:
It couldn't be any clearer what I'm trying to do. I think everyone here knows that. If device_unlocked is in the policy then we can set it's values on a permenant basis, at least with root. I can pull up dozens of screen shots where there is clearly shell based commands being given either while booted or in fastboot some of which completely disabled selinux. Not just turn it off. Because that's technically what we are doing with a toggle. Not to mention the many other oddities. Here's one I've been trying to figure out. If selinux wasn't important, in this particular case, then what does this mean in the build.prop:

ro.boot.selinux=disable

I have no idea and the search I did shows permissive there instead of disable. I don't see this much either. Usually it's ro.build.selinux with a value of 1 or 0.

---------- Post added at 09:10 AM ---------- Previous post was at 09:08 AM ----------

It will if you set the policy right. Which is what I am reading about now. If it can persist there, then whatever device_unlocked is can also be set.
[Fire Android Development] Rortiz2:
I do not know if this will work.

It may be a stupid idea but someone has tried the SeLinuxMode Changer app?

https://xdaforums.com/showthread.php?t=2524485
[Fire Android Development] DragonFire1024:
The switches only set the mode. The mode goes to permissive when the device is done booting the system and what not. So the mode is only changed when the app boots.
[Fire Android Development] DragonFire1024:
So the amz.rsa and tl1.rsa certificates in /vendor/data are private keys (PKCS7)

So just for app signing?