yashsingh1/xdaforums huggingface dataset:
[Fire Android Development] diplomatic:
Well, I suppose you just set the ADB_ON & ADB_AUTH_DISABLE flags by running this in root shell:

idme fos_flags 21

Then... follow the steps in this thread. Actually, you can skip the fastboot steps. Just run

adb reboot
adb wait-for-device && adb shell

But fair warning: we don't know what kind of unintended consequences this will have. The risk is low, but I'd say it's not impossible that you won't be able to get back into root shell to reset the value. And factory resetting or reinstalling the FW will not restore it.

Also, did you find init yet? It's in the root directory of the ramdisk and the device file system. In addition, take a look at /sbin/adbd. That's more relevant. I think the 'amzn_fos' stuff is all the same code.
[Fire Android Development] DragonFire1024:
Which init? There are a lot. I've looked at all of them before but that was before this discovery so haven't looked at them in a bit. Now let's say this works. Given the script allows unprivileged users to add values, would this be able to be done without root? If we can get a numerical uid of this amzn_fos, it's folder may shed some more light. Is there any way to send some kind of system ping to wake it up for a second? All we would need is a simple log entry I believe.

Ok let me have a cigarette and plug in and see what happens.
[Fire Android Development] DragonFire1024:
Step one complete.
[Fire Android Development] DragonFire1024:
Step two completed...with success. Root shell persisted after reboot.
[Fire Android Development] DragonFire1024:
We have a new addition to android properties. This is via settings database editor. Congrats everyone. It worked. ?
[Fire Android Development] diplomatic:
Success? But you just ran the 'su' from your root manager to get root. If it works, this is supposed to give you adb root without su. Sigh....

What about running 'adb root'?
[Fire Android Development] DragonFire1024:
Oh. Sorry. I run adb root, and the command prompt just returns. But no errors.
[Fire Android Development] diplomatic:
Oh? But then if you run 'adb shell', and inside the shell do 'whoami', what is the output?
[Fire Android Development] DragonFire1024:
Would it necessarily be a root symbol right away though? There's no indication in anything I have seen where a root shell just appeared. I know what you're saying and it's similar to the way we root the Galaxy S7. Flash the eng kernel, you get root shell always and forever so to speak. We know 2 things as a Result of this test now 1) it worked. We just typed a command and a very clear system property appears out of thin air. That's a good indication. 2) we can manipulate at least one very important property with root. Now what else? And what is the extent of the non root fos and can the same commands be sent by non root? This is huge in of itself Regardless of a few oddballs. 3) what is the extent of our newfound powers?

---------- Post added at 08:27 PM ---------- Previous post was at 08:23 PM ----------

It says:

adb shell
shell@suez:/ $ whoami
shell
shell@suez:/ $
[Fire Android Development] diplomatic:
Meh.... then this is probably a whole bunch of nothing. You still need the /proc/cmdline to contain androidboot.unlocked_kernel=true to get auto-root. I thought the disable adb auth flag might start adb in root mode, but it actually just disables the RSA authentication between the host and the device described here. This is the "allow USB debugging?" prompt.

The property you found was added by the script:

if [ $(( $FOS_FLAGS_ADB_AUTH_DISABLE & $FOSFLAGS )) != 0 -o -f $FACTORYMODE ]; then
# set a property to signal higher layers that adb auth is temporarily
# suspended
setprop amazon.fos_flags.noadbauth 1
fi

Nothing mysterious about that.
[Fire Android Development] DragonFire1024:
Factory mode. Mentioned several times. Yet we have a few lines that say true for unlocking the kernel. And if it's a plain old shell, it's being done post build. But not in 1969. Then it's possible there is a fos_flag that does something to unlock the device. There's just too much evidence to suggest otherwise. Now we need to figure out what other fos flags there are
[Fire Android Development] DragonFire1024:
I just tried to flash a rom again to my hd 10. Didn't work, but it still booted. Did a full wipe before flashing. Went to settings and turned on developer options. ADB was already enabled. But it was unauthorized. I had to reset fos_flags to 0 and all is good upon reboot.
[Fire Android Development] diplomatic:
If the bootloader detects a proper unlock code signature, it will pass the unlocked_kernel tag to the kernel via the command line. That's all there is to it. If you can figure out how to add this string to the command line with unprivileged access, you might get your root adb shell.

You can try setting other unspecified fos_flags since you're asking about it, but I'm fairly sure that won't give you root. For example, you might try 'idme fos_flags ffe3'. That includes every bit (of 16) except console, verbosity and ramdump, as described by init.fosflags.sh. But beware, this is even more risky than the last command...
[Fire Android Development] hwmod:
Fire 7 5th Gen in Factory Mode

I see the discussion is proceeding so fast that I can't hardly keep up with the small time I have available for this.

Every time I enter in this forum I see you are "torturing" the tablets through new paths and methods. Ha ... ha, very good training.

Maybe a bit too dispersive, however I see you get very good info from the system and maybe collecting these info and sorting them may yield some neat tricks in the future.

Anyway since we are at that I can throw more info bound to these arguments hoping you can put them on good use with the strategy you are using.

Here are a few info I gathered while searching how to enable the FACTORY MODE. The "dev_flags" comes into play too in the same way "fos_flags" does.

The difference is that "dev_flags", and also "usr_flags", are used to change a few other things for example setting "selinux" to "permissive" mode instead of "enforcing" mode.

Now jumping to another track, today I was able to see the FACTORY MODE menu with the entries scrolling one by one in a very fast sequence without me touching anything.

I just typed the command "factory" once as usual, but this time all the test where performed automatically very fast. I had the time to take a few photos of it.

Here is a link to a few pictures of the FACTORY MODE while testing some of the tablet hardware components:

FACTORY MODE on Fire 7 5th Gen with Fire OS 5.0.1​

Unfortunately I cannot replicate this at will, I just happened to make it work a couple of times randomly on version 5.0.1 when these photos were taken.

The FACTORY MODE can be started by using the "factory" command in "/system/bin", no tricks about that and I can say it is almost sure it is sa non-destructive action.

The menu seems to be in Chinese, the sixth entry it says "Clear eMMC" , if you get the menu I suggest to avoid tapping on it until we are sure on the results that produces.

Notice that, at least on my tablet, the "/system/bin/factory" command is a "one-shot" only command since it works only the first time you launch it from the "shell".

After that it doesn't seem to work a second time. To repeat that, the device must be reset each time.

Also it gives me an error after launching it:

"can't open /dev/tty0: No such file or directory"​

I have tried to recreate the missing device node with different major/minor without success.

If you happen to get better results with FACTORY MODE I would appreciate the help and the info you may have found.

Happy hacking,

.:HWMOD:.
[Fire Android Development] DragonFire1024:
I have ran into that dev error a few times too. It looks like part of the kernel command override options. In the boot image, there is a section called boot-img_cmdline. tty0 is supposed to be there. However if you do look at the split image, the characters aren't what they appear to be. They have the console value at ttyO. Yes the first one is a zero, the second one is the letter O. I don't know if that's supposed to be like that or if they just switched the values by a number/character. I didn't notice it until I wrapped the text in CODE and the zero had a slash through it.

I wonder what makes factory mode go so fast. There has to be a way to slow it down or something. Where can we see the flags? Did I totally miss them?

The adbnoauth flag actually persists after a factory reset, not after flashing. ADB will stay toggled on through the process but because it blocks the pop up confirmation, it never gets authorization. So you have to reset the flag to 0 in order for it to work properly.

I posted a new thread regarding trying to build a ROM. I can't get any type of updater script to work. Assert doesn't work. Flash Fire immediately rejects anything with 'set_metadata' in front of it so the permissions after symlinks can't be granted. I can flash the directory no problem, but seems like I can't flash the system partition. If anyone could she'd some light for me as to why....
[Fire Android Development] hwmod:
If you are rferring to "dev_flags" and "usr_flags" cited in my message above you can find them in "/proc/idme/" directory.

Or you can have them printed out to console by using the "idme print" shell command. The last three lines of output are:

dev_flags: 0
fos_flags: 0
usr_flags: 0

They both have value of "0" by default and they are present in both Fire 7 and FIre HD 8, maybe in FIre HD 10 too.
[Fire Android Development] diplomatic:
Wait, so which bit in dev_flags or usr_flags disables selinux? Because I searched the whole ROM and didn't find any reference to either of those values (other than in the fosflags sh script).

I think maybe the reason factory does not run again is that some property is being set by it, or some file is created/changed on /data. You have to compare the before and after snapshots of the data file system and of system properties to narrow it down. There is also source code of this factory program here.

I'm not even sure if this is in the ballpark, but do you actually make a sparse image out of your system image? That is, convert system.img to system.new.dat + system.transfer.list. Because this is the format that ROMs usually come in.
[Fire Android Development] hwmod:
[MENTION=8132642]diplomatic[/MENTION],

the reason I have come to know that bit about "selinux" and "dev_flags" lies in the fact that recently I have been given a new HD 8 (8th Gen) as a gift.

So I was "reading" the "lk" binary code to see and compare with my other Fire 7 tablet.

The result is that I could find evidences by these strings in the "lk" binary code:

%s androidboot.selinux=enforce
[SELINUX] enforced by dev_flags
[SELINUX] set to permissive mode by dev_flags
%s androidboot.selinux=%s

and this yet more interesting:

%s androidboot.veritymode=eio
[DM-VERIFY] enabled with eio mode
%s androidboot.veritymode=disabled
[DM-VERIFY] disabled by fos_flags on eng devices

Furthermore I have seen that these flags can be passed on the "cmdline" by using the following "fastboot" arguments:

fastboot oem flags 0x%llx​

The above is true for both Fire 7, Fire HD 8 and should be for Fire HD 10 too (maybe Dragonfire1024 can confirm).

The "dev_flags" string is also present in the system partition in "/system/etc/init.fosflags.sh" at least for "Austin" (7th Gen).

I haven't had the time to lookup and confirm the same info for "Ford" (5th Gen) yet but I am almost sure it is the same.

Regarding the FACTORY MODE ... in "/factory_init.rc" there seems to be some lines that maybe explain the reasons it only work once:

service factory_with_image /system/bin/factory
disabled
oneshot
service factory_with_image /sbin/factory
disabled
oneshot

By the way, thank you for the "factory" source code link, I will dig in that too as soon I have the time.

.:HWMOD:.
[Fire Android Development] DragonFire1024:
Yes they are on the HD 10 and we can change the values too. I thought you were saying you saw a list of the options for flags.

---------- Post added at 08:43 PM ---------- Previous post was at 08:38 PM ----------

I'm trying to build a custom rom for the HD 10. I can get everything put together, formatted just like the fire Nexus zip/ROM but fails to get past unpacking the items, erroring on set_metadata. Doesn't recognize the format or something. I forget the exact wording. I don't have a log anymore. I can post it when I try again.
[Fire Android Development] hwmod:
I only found a list of FOS_FLAGS that you probably have already, here they are (the one in "Karnak"):

FOS_FLAGS_NONE
FOS_FLAGS_ADB_ON
FOS_FLAGS_ADB_ROOT
FOS_FLAGS_CONSOLE_ON
FOS_FLAGS_RAMDUMP_ON
FOS_FLAGS_VERBOSITY_ON
FOS_FLAGS_ADB_AUTH_DISABLE

Unfortunately it seems that also the "fastboot oem flags 0x%llx" commands

are restricted on locked hardware, here is the string stating that in the binary:

oem flags command is restricted on locked hw​

I still hope flags can be passed using the "-c" or "--cmdline" fastboot parameters.

Attached is a copy of the "lk" binary of the Fire HD 8 (8th Gen alias Karnak)

.:HWMOD:.
[Fire Android Development] diplomatic:
Whoa... so there is an adb root flag?! That's a nice find. FOS_FLAGS_ADB_ROOT was not listed in the init fosflags script. So it must be the missing bit 0x2. [MENTION=8165603]DragonFire1024[/MENTION], can you try setting 'idme fos_flags 3', and see if it gives you genuine adb root? Most likely it still needs the unlocked_kernel state, but who knows.

Cool... this is all very interesting. I don't think there is a mention of dev_flags relating to selinux in the HD8 7th gen LK. And there is certainly nothing about dm-verity, because that's new to FireOS 6. But what's interesting is 'androidboot.veritymode=eio'. If dm-verity can be set to 'eio' mode through these flags, it might be possible to have root on FireOS 6 using at least the hardware mod. (Or it might be in eio mode by default???)
[Fire Android Development] DragonFire1024:
The flag is listed as being set but I did a few commands, adb root, adb remount and nothing happened. Got permission denied for adb remount. Maybe it needs the adbnoauth too?

I was playing with the dha tool and ran a command without root. The error i got back was interesting. I also noticed it says this is the "Amazon keymaster."
[Fire Android Development] diplomatic:
Hmm, then I don't get why this flag exists. If cmdline contains 'unlocked_kernel=true', then adb goes to root. Whether or not the adb_root bit is set, the behavior still seems to depend only on the unlocked_kernel parameter. (You did reboot after setting idme, right?)

Was the dha_tool printing something different before?
[Fire Android Development] hwmod:
Did you guys realize the extra parameters that exists for the "idme" command ?

root@ford:/ # idme
usage: idme <ARGUMENTS>
help Print this help messages
name <value> set value by idme name
name clear clear the value by idme name
print Shows all existing values
print <name> get value by idme name
copy sensorcal Copy sensor calibration data to /data
copy KB <partition> Copy KB data to KB partition
copy DKB <partition> Copy DKB data to DKB partition

Of special interest are the last two parameters, "copy KB <partition>" and "copy DKB <partition>".

They may have some use bound to the persistence of these parameters, right ?

Further these two partition contain both NVRAM and ENV data for the BL.

Maybe passing the flags and other stuff in the "cmdline" is not enough,

and there must be some sort of helper that activates these values and

make them persist reboots. Also "idme" data are in mmcblk0boot1.

One other thing I need, if ggow is reading or somebody else knows, is there a way to have "boot.img" signed so it passes the bootloader checks ?

I have seen that the kernel of the boot images of LP, Slim and Nexus ROMs are not stock kernel/ramdisk images (I may be wrong though).

Could you point me to the script doing the signature and tell which keys were used for that task ?

Thank you in advance,

.:HWMOD:.
[Fire Android Development] DragonFire1024:
I have talked about the idme before. It seems to be exclusive to amazon. I think it ties into the amzn_dha_tool which also needs root to be run. If you try without root, you get an interesting error. I don't know what the copy partitions does either. Up until now, no one listened to me that we have access to these items, some without root. If we can find a way to edit the two partitions, we could flash them, but the question is how and will it work?

---------- Post added at 05:09 AM ---------- Previous post was at 04:58 AM ----------

Maybe the flag value is wrong? That's the only thing I can think of.

DHA is mentioned in a line of two in several of the binaries i have spoken about. It would now be safe to assume since they use an alternative way of accessing their devices, they need a method of verification of hardware related. Also the error produced when running it without root points to a mediatek folder. Maybe they set it up for Amazon?
[Fire Android Development] DragonFire1024:
In /system/framework there is a fosinit.jar file. Unfortunately it's odexed. I have a tool that can fix that, but I don't know what the result will be if I push it and the arm folder that contains the odex files once completed. If it bootloops the device, then at least I can deodex it on pc and we can look at the classes.dex. I have a tool for that too.
[Fire Android Development] diplomatic:
Well, being able to sign it would be the holy grail, wouldn't it? :D No, there's no known way to self-sign it or forge the signature. If there was, it would be an easy way to systemless root and custom recovery. You can examine it yourself, but the signature format is unique to Amazon. In a nutshell, it is simply a standard x509 certificate that contains the SHA hash of the image. It is signed by the RSA key associated with a root certificate embedded in the bootloader. The root certificate contains the public key used to verify it.

As I mentioned before, amzn_dha has nothing to do with what we're talking about here. And neither does this KB stuff. It has as much to do with unlocking this device as Google Widevine.

Hmm, that's interesting. It might be useful to decompile it and see what it does. (But why would you need to copy it back? It's already installed.)
[Fire Android Development] DragonFire1024:
From what I understand about odex files, the classes.dex in apks are extracted and odexed to save space...that's the general idea. It also stops you from editing a lot of apks because most of the time they won't recompile because certain classes and resources are moved off the app and into that odex. Generally it's not hard to fix such a thing with root. But this is a lollipop/Amazon hybrid and generally speaking, it's not easy to deodex lollipop anything. Usually it's apks that are odexed. Amazon has done it to other things like jar files (android.services) and executable binaries and as exampled, init scripts. It may very well be the reason adb root flag didn't appear to do anything. If the value is set and in the odex file as that set value, changing it with the idme fos_flags command won't have an effect, even if the value holds. Using the tool to repack the odex back into the apk may been precisely why I may have just made a unrelated discovery. Give me a few and I'll see what I can do.

Then what is the dha tool for? Why has it a public key that doesn't appear to match anything? Why is it called the Amazon keymaster if it's not used to verify certificates/signatures of hardware? It doesn't make any sense for it to be unrelated to unlocking or verifying something. Reminder: an Amazon "master keybox" is mentioned several times in all of the same files I have been looking at. It may be the mention of the tool itself and nothing more, just like these little bits we've found.

Has anyone looked at the keystore files and related .so files?
[Fire Android Development] DragonFire1024:
Well well. I'm going to have to upload them. And wow. I tell you...seeing is believing. There's a lot of stuff in them. And by a lot I mean everything. Factorymode? Everything you need for it to work, is in there. Keystore info, dha tool, wifi display, Amazon's infinite lock screen, idme commands, pm. It is incredible to see all of this. There are three in framework folder. Fosinit, fosframework, fosservices. And it's like everything this rom could be, are in these three folders. What lollipop could have been, and was, has come to a few odexed jar files. I tried to flash the deodexed files, boot looped as expected. I have another way of trying though. I'll upload the files in a zip in an hour or so. Be prepared to be amazed. I'd really love to see if we can't bring all these back to life.
[Fire Android Development] DragonFire1024:
here you go. The folders contain the classes.dex and the source folder contains the classes.dex decompiled. Use Notepad++ for Windows. Have fun :D Really interesting stuff.
[Fire Android Development] DragonFire1024:
Has anyone had a chance to look at that yet? From what I understand those items in the files do not necessarily exist inside the actual applications or other files they are tied to and our cases binaries. Now they would have to be manually added into the back end of every one of those apps or binaries. For example I decompile the framework APK and if I were to port in a specific function I would have to go through each and every line of the code and add in that function including the Java and the smali. no I'm pretty good at doing everything except the smali and I have no idea how to edit a binary.

And just an interesting side note. I've downloaded the system image for the original source code that the HD 10 is based on which is lvy48f. I've been able to successfully Port over every single stack application on that device the exception of the proprietary ones such as Qualcomm and Motorola however I have not tried with the system user interface or the framework yet. the interesting part about this is I didn't have to build anything I just simply installed my modified settings application and then replaced it with the settings application from the stock system image of that Google device. And 98% of it works. Of the few links that don't most of them can be manipulated with settings database editor or launched with activity launcher. Now the interesting part about this is either Amazon signed some of their apps with the same signature as those on that Google device or vice versa. Because without any other manipulation such as disabling signature verification in the package manager, this APK works. Its like I tricked the system into thinking it replaced an item of itself. Which is also interesting again because they shouldn't have the same signatures. Now this would be a very easy port of a pure asop ROM if I can get the damn thing to flash the system partition.

All I need to do is test the system user interface and the framework and we're good to go but I can't do that unless I can flash the system partition. I might be able to do the system user interface but I haven't tried yet.
[Fire Android Development] k4y0z:
The permission denied could also come from selinux.

could you check if you are root with the flag being set?

adb shell whoami
[Fire Android Development] DragonFire1024:
Will have to be later today.
[Fire Android Development] DragonFire1024:
Well I just did a factory reset and reflashed fireOS. I activated developer options, and adb was enabled, but still none of the root commands would work. The last command i did was fos_flags 3
[Fire Android Development] diplomatic:
Well, you might want to try 'idme fos_flags 33' as a last resort....
[Fire Android Development] Supersonic27543:
Did it require ADB authorization prompt to be accepted? Also, the source you posted definitely looks interesting. I don't know much about smali, so can someone take a look at fosframework/com/amazon/android/idme/Idme.smali? Looks like that handles some fos flags.
[Fire Android Development] DragonFire1024:
I don't recall. If I recall, I would say no. [MENTION=8132642]diplomatic[/MENTION] what is the fos_flag for noadbauth?