yashsingh1/xdaforums huggingface dataset:
[Fire Android Development] DragonFire1024:
so this is in init.rc. If I read this correctly,the start command would essentially start the service? We might have been going about this a little wrong.

##ACOS_MOD_BEGIN {fos_flags}
service fosflags /system/etc/init.fosflags.sh
class core
oneshot
disabled

on property:ro.amazon.fosflags=1
start fosflags

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

on property:amazon.fos_flags.wipe=1
start wipe_fosflags
##ACOS_MOD_END {fos_flags}

debug. u:object_r:debug_prop:s0
debug.db. u:object_r:debuggerd_prop:s0
log. u:object_r:shell_prop:s0
service.adb.root u:object_r:shell_prop:s0
service.adb.tcp.port u:object_r:shell_prop:s0
# ACOS_MOD_BEGIN {amazon_sepolicy}
amazon.fos_flags.wipe u:object_r:shell_prop:s0
amazon.fos_flags.noadbauth u:object_r:shell_prop:s0
# ACOS_MOD_END {amazon_sepolicy}

We know the wipe works. The build prop on the HD 10 is already set to '1' by stock. So the above is why the init scripts don't do anything.

An rild script supposedly grants a user root access, I would presume a technician

## ACOS_MOD_BEGIN
## refactored into vendor-specific init.rc file
# service ril-daemon /system/bin/rild
# class main
# socket rild stream 660 root radio
# socket rild-debug stream 660 radio system
# user root
# disabled
# group radio cache inet misc audio log
## ACOS_MOD_BEGIN

Does anyone know anything about mtk aee? It is supposedly activated on this board and gives several props for it. A Google search shows a lot of talk about porting recovery. From property_contexts

#=============allow AEE==============
# persist.mtk.aee.mode && persist.mtk.aee.dal
persist.mtk.aee u:object_r:persist_mtk_aee_prop:s0

# persist.aee.core.dump && persist.aee.core.direct
persist.aee u:object_r:persist_aee_prop:s0

# debug.mtk.aee.db
debug.mtk.aee u:object_r:debug_mtk_aee_prop:s0

#=============allow AEE_Dumpstate==============
debug.bq.dump u:object_r:debug_bq_dump_prop:s0
[Fire Android Development] DragonFire1024:
MTK AAE is apparently called the 'Android Exception Engine (or Enhancement)'. https://android.googlesource.com/ke...id-mtk-3.18/drivers/misc/mediatek/aee/Kconfig

That's about all I can find on it aside from this:

https://labs.mwrinfosecurity.com/advisories/information-disclosure-via-aee-extension-to-debuggerd/

Not sure if this is even any help. information if anything.
[Fire Android Development] DragonFire1024:
How would one go about recovering a deleted partition? According to 'recovery.fstab' in /system/etc on the HD 10, there are two LK partitions, lk and lk2 both in .../by-name. However when in root explorer and in that same directory, only one appears, lk. Screen shot of the directory first then fstab below.
[Fire Android Development] DragonFire1024:
Other didn't save
[Fire Android Development] hwmod:
Well FOS is surely the acronym of "Fire OS" and my guess is that AEE would be the acronym of "Amazon Execution Environment" which should correspond to the ARM "Trusted Execution Environment"

It looks like Amazon is in the mood of assigning his own naming/branding to many of the already existing technologies that it is using, probably to enforce their dominance of the market by distinguishing themselves from the manufacturer crowd.

And speaking about the "fos_flags", after what you said above, we are sure the functionality exists in current tablets, it is not something they have taken away and we have partial knowledge of how that works and proofs that it can trigger services.

So now reverse engineering of that process is necessary to achieve permanent root, I am confident that is the correct way to trigger the "Auto-root" process we have found in several places ("vold" is he last place we found tracks of "Auto-root").

I only have to regret that at the moment I am suffering a complete lack of time to put on this which makes this process so long. Still worth it though. ;)

.:HWMOD:.
[Fire Android Development] Rortiz2:
They are probably not erased but hidden. You can try the following command:

dd if=/dev/block/platform/mtk-msdc.0/by-name/lk2 of=/storage/emulated/0/lk2-suez.bin

To get lk2.bin

PS: Merry Christmas to all!
[Fire Android Development] hwmod:
Strange functionality in recovery mode - "Mounted /system."

I discovered a strange functionality / behavior that I don't know how to put into good use. I am passing here a simple procedure to try for those having a Fire 7 tablet (either 5th or 7th Generation) it should work on both:

- put the tablet in recovery" mode, either by pressing "Vol-" and "Power On" buttons at the same time, or by giving the command "adb reboot recovery" from your OS or just "reboot recovery" from inside a shell session

- once the "recovery" has started, start pressing repeatedly first only "Vol-" then only "Vol+" and alternating them quickly for at least 4 or 5 times without interruptions

after the fourth alternated repetition of the two volume buttons, at the bottom of the tabled display a the text "Mounted /system." will appear in yellow.

I have done this several time and I know it works with v5.0.1, 5.1.1 (5th Gen) and 5.4.0 (7th Gen)

Please confirm (or deny) that the same also happens in your tablet Fire 7.

I am still not sure why that happens and what is it useful for.

.:HWMOD:.

---------- Post added at 12:48 AM ---------- Previous post was at 12:34 AM ----------

Trust what you have in "/proc/partitions" not what "Root Explorer" says, the latter being generic cannot have model specific info for all existing tablets.

Having two "preloaders" and two "littlekernels" could be a life saver. If one of the path is damaged the secondary may become the only one usable, saving from a "brick".

The old Huawei Mediapad S301u, S302u, S303u had double boot and double recovery partitions.

.:HWMOD:.
[Fire Android Development] Rortiz2:
Fire 7 Austin Fire Os 5.6.1.0 mounts system in recovery.
[Fire Android Development] DragonFire1024:
I had already tried that very first thing. not formatted exactly the same as yours but got the same result 'no file or directory'.

---------- Post added at 08:14 AM ---------- Previous post was at 08:08 AM ----------

wouldn't this normally allow for media to be ADB sideloaded via SD cards external or internal, while in recovery mode? And isn't that a stock Android recovery function?

---------- Post added at 08:17 AM ---------- Previous post was at 08:14 AM ----------

Still no clear sign of lk2. It might be the rpmb one.

u0_a28@suez:/ $ cat /proc/partitions
major minor #blocks name

7 0 82796 loop0
7 1 1254 loop1
7 2 10240 loop2
179 0 30535680 mmcblk0
179 1 3072 mmcblk0p1
179 2 4608 mmcblk0p2
179 3 1024 mmcblk0p3
179 4 1024 mmcblk0p4
179 5 1024 mmcblk0p5
179 6 5120 mmcblk0p6
179 7 5120 mmcblk0p7
179 8 40448 mmcblk0p8
179 9 512 mmcblk0p9
179 10 8192 mmcblk0p10
179 11 16384 mmcblk0p11
179 12 17408 mmcblk0p12
179 13 1653248 mmcblk0p13
179 14 434176 mmcblk0p14
179 15 28343791 mmcblk0p15
179 96 4096 mmcblk0rpmb
179 64 4096 mmcblk0boot1
179 32 1024 mmcblk0boot0
179 33 2 mmcblk0boot0p1
179 34 2 mmcblk0boot0p2
179 35 256 mmcblk0boot0p3
179 36 747 mmcblk0boot0p4
179 128 31166976 mmcblk1
179 129 31165952 mmcblk1p1
u0_a28@suez:/ $
[Fire Android Development] hwmod:
Lk2 should not appear in the list of mount points presented by the "mount" command. Lk2 is not a filesystem it is a "raw" partition like "lk", "pl", "boot" and "recovery".

The "mount" command should only list mound filesystem partitions, like "cache", "system" and "userdata" all having "ext4" format. So the output above is correct.

.:HWMOD:.
[Fire Android Development] Rortiz2:
And how is it possible that this command does not work?

dd if=/dev/block/platform/mtk-msdc.0/by-name/lk2 of=/storage/emulated/0/lk2.bin
[Fire Android Development] DragonFire1024:
In one or two of the binaries I've seen in the past months did very briefly mention dual booting, but I didn't think anything of it.

Secondly my original question still stands: how would one possibly go about recovering said partition?
[Fire Android Development] DragonFire1024:
Well this is odd but sadly explains some things but really doesn't.

I am attaching recovery-resource.dat as a zip. Extract it and right click it with 7 zip to open as archive. 1. There is your exclamation mark when playing with volume and No Command. Also I have no clue what any of the text is.

How much you want to bet the key file has recovery keys. Just open as archive. File title 'keys'
[Fire Android Development] DragonFire1024:
I am at work so don't have it in front of me right now, but in the root directory there is another file, 'fstab.mt8173' it lists all the partitions, same as the fstab.recovery, including confirming the presence of a second 'bootloader (it does say bootloader), listing 'lk' and 'lk2'. So given this discovery, how do we get at it?
[Fire Android Development] DB126:
Believe this is fairly common on Amazon (likely most/all Android) devices and probably will be of little use in the absence of method for forging signatures. I will give that some thought in the context of other devices that have seen boot exploits.
[Fire Android Development] DragonFire1024:
Well maybe I can help in that field, at least with the HD 10. I just happen to have everything related to the mt8173 chipset...ram disk, kernel, boot image...the whole 9 yards. All of it is blank material...as in it's not yet been assigned to a device therefore nothing is yet signed. Let's say we do find a way to access this second lk...would it be possible to use those pieces? I'll find somewhere to upload the files anyways.
[Fire Android Development] DB126:
Attached are the two requested files from an early 5th gen Fire. Nothing very interesting IMO.
[Fire Android Development] Rortiz2:
You're right, they're just mount points. How can that help?
[Fire Android Development] DragonFire1024:
It's a whole nother partition likely empty. This actually proves the device can dual boot. If we can access it we can use it to dual boot a custom rom along side fireOS. We of course would need to build or adapt a rom to the device. I will contact someone I know who wrote a program to allow dual booting of ROMs. I put in a pull request a while back and I dont think it went through yet.
[Fire Android Development] DragonFire1024:
well that doesn't look the same. On the HD 10, the fstab.mt8173 says there are two booloaders on the tablet, lk and lk2. It specifically lists it as a bootloader. Attached mine in a zip and copy pasted below:

# Android fstab file.
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK

/dev/block/platform/mtk-msdc.0/by-name/system /system ext4 ro	wait
/dev/block/platform/mtk-msdc.0/by-name/userdata /data ext4 noatime,nosuid,nodev,noauto_da_alloc wait,check,resize,encryptable=/dev/block/platform/mtk-msdc.0/by-name/metadata
/dev/block/platform/mtk-msdc.0/by-name/cache /cache ext4 noatime,nosuid,nodev,noauto_da_alloc wait,check

/devices/soc/11240000.mmc* auto vfat defaults voldmanaged=sdcard1:auto,noemulatedsd
/devices/soc/11270000.usb* auto vfat defaults voldmanaged=usbotg:auto

/dev/block/platform/mtk-msdc.0/by-name/proinfo /proinfo emmc defaults defaults
/dev/block/platform/mtk-msdc.0/by-name/lk /bootloader emmc defaults defaults
[B]/dev/block/platform/mtk-msdc.0/by-name/lk2 /bootloader2 emmc defaults defaults[/B]
/dev/block/platform/mtk-msdc.0/by-name/boot /boot emmc defaults defaults
/dev/block/platform/mtk-msdc.0/by-name/recovery /recovery emmc defaults defaults
/dev/block/platform/mtk-msdc.0/by-name/tee1 /tee1 emmc defaults defaults
/dev/block/platform/mtk-msdc.0/by-name/tee2 /tee2 emmc defaults defaults
[Fire Android Development] DB126:
Not surprising, different architecture.
[Fire Android Development] DragonFire1024:
Now how to access or use it.
[Fire Android Development] Droidriven:
I don't think that can be done, if it could, there would be no reason to have the 2nd bootloader in the first place. I think you might be trying to hunt something that can't be killed and you're doing it with a dog that don't hunt, if you understand the expression.
[Fire Android Development] DragonFire1024:
Maybe, maybe not. It'll be added to my list. I would agree with having a second bootloader...if the second one was even mounted. Just strange to be sitting there.

Also it seems persist.sys.usb.config=mtp,adb has held on my HD 10, even after flashing.
[Fire Android Development] DragonFire1024:
So I'm hunting for the second bootloader. I went to dd one of the partitions 'mmcblk0rpmb' and got this:

u0_a40@suez:/ $ su
root@suez:/ # dd if=/dev/block/mmcblk0rpmb of=/sdcard/wtf.bin
dd: /dev/block/mmcblk0rpmb: I/O error
0+0 records in
0+0 records out
0 bytes transferred in 0.001 secs (0 bytes/sec)
1|root@suez:/ #

I realize there is nothing set at the end of path for 'if' as there is nothing in the by-name folder with 'mmcblk0rpmb'. It does go down to the by-number folder though. How would one dd such a partition then?
[Fire Android Development] Droidriven:
I don't think that bootloader gets mounted, that's why it doesn't show in the "by-name" folder. It will probably only show the partitions associated and used by the ROM that you installed. The original bootloader just sits there in a "dormant" like state, doing nothing and having no activity while the device is on. The original bootloader only becomes active at boot and it only does it long enough for the 2nd bootloader to take over, then the original bootloader goes to the basement, lays down and goes to sleep like it was never there.

It effectively doesn't exist as far as the installed and mounted system is aware of. That "wall" is there for a reason, you would not be able to use TWRP or a custom ROM without that wall being there, trying to break it down will only bring the roof down on your head.

If you don't leave the original bootloader alone, all you're going to acheive is bricking the device. You might be able to extract a copy of the original bootloader, but you can't remove/replace/modify it, if you do, the device will no longer be able to boot the original OS or your custom ROM, your 2nd bootloader will not boot/load/function without the original bootloader because the 2nd bootloader requires the unmodified original bootloader to function because the original bootloader is what loads the 2nd bootloader, it can't function without it. Leaving it alone is the only way you can continue using TWRP and custom ROMs.

Messing with the original bootloader risks putting the device in a state that won't be able to boot anything at all, not even its own stock recovery, maybe not even fastboot mode, if that happens, not even a fastboot cable would be able to help you unbrick/recover the device.

I think you are wasting your time but if you have the time to waste and if it the cost of the device doesn't matter to you, then go for it.

But if the device matters to you and you don't want to destroy it or have to pay to repair/replace it then I would suggest leaving it alone.
[Fire Android Development] DragonFire1024:
I have a tablet that I can test on and is of no consequence to me. The only downside would be losing the test device and I don't have a backup.

I'm not trying to bring down the wall. I'm trying to take a peek. Copy it if at all possible. There are three possible partitions it could be, assuming it's mounted and the path name is changed (amazon has a habit of moving things a spot to the left or right and renaming them rather than overwriting or deleting).

-mmcblk0

-mmcblk0boot0

-mmcblk0boot1

-mmcblk0rpmb see here: https://lwn.net/Articles/682276/ There is a good chance the private keys are in this one.

Forgive me if this sounds dumb. But what about replacing the second bootloader if we got access? I have blank, stock mt8173 (HD10) boot, recovery, all the loaders, ram img etc. Could any of those be built and used?
[Fire Android Development] Droidriven:
I don't know, I would try getting in touch with [MENTION=4243514]Hashcode[/MENTION] and the other member that you mentioned that posted the root method for your device. They would be able to tell you how they can help if doing what you're trying to do is possible. They would probably also be able to tell you if isn't possible and exactly why.
[Fire Android Development] DragonFire1024:
Ok. In the mean time, it appears my suspicions are correct. The second boot loader isn't in that path. Did a dd on these in .bin output. Just glanced at them with a text editor for now. Will upload them in a zip tomorrow. There is a lot going on here.

Bootloader1: /dev/block/mmcblk0boot0

Bootloader2: /dev/block/mmcblk0boot1 'beefdeed2'

The last known reference to beefdeed was fireOS 8.1.2 (i think this is a typo and is for the jem) https://github.com/verygreen/u-boot-amazon-jed/blob/master/common/cmd_idme.c

Did they actually recycle the bootloaders from the Amazon JEM 8.9?
[Fire Android Development] DragonFire1024:
So I've been looking over the bootloader. It's going to take some time to read through. IDA does a great job. Has anyone heard of 'usbdl'? It looks like some kind of command interface. It's used in verifying the DA from what I can see. Also the second bootloader is tied into idme. All the variables are there. So far I haven't seen any idme variables in bootloader 1.

In one of the init.rc files in root, there are options to set ro.build.type....one of those is 'eng'. I haven't tried to set it yet.
[Fire Android Development] Droidriven:
Maybe usbdl could have something to do with some type of "download mode" and flashing via usb.

The ro.build.type 'eng' seems like it has something to do with putting the device into engineering mode for testing/debugging purposes.
[Fire Android Development] DragonFire1024:
If that's the case with usbdl, then there are a lot of commands intact. I forgot to upload the zips which I'll do tomorrow.
[Fire Android Development] Droidriven:
I did a search for "Amazon kindle fire engineering mode". This is one of the first links I took a look at:

http://mobilespecs.net/tablet/codes/Amazon/Amazon_Kindle_Fire_HD_7_16GB.html

I have this device, I might poke around on mine to see what I find.

I also found this here at XDA:

https://xdaforums.com/hd8-hd10/general/amazon-fire-easter-eggs-secret-codes-t3773583

Edit: I see that you are already mentioned in that thread[emoji19]

I thought you might find this interesting if you haven't seen it.

Edit:

This page has a list of various Kindle devices. If you click on them, they each have a "secret codes" tab that shows the codes for that model.

http://mobilespecs.net/tablet/Amazon/
[Fire Android Development] DragonFire1024:
Can't wait to see what the rest of the bootloader holds. This is the first time in this tablet I've seen intact commandlines in any of these areas. Usually amazon deletes them.

---------- Post added at 07:21 AM ---------- Previous post was at 07:15 AM ----------

Also...what is persist.sys.usb.config=acm?
[Fire Android Development] Droidriven:
persist.sys.usb.config is what controls the various USB modes, i.e. MTP, adb, diag, etc..). It seems to me that acm refers to linux drivers, also involved in USB protocols.

I found this, 2nd post, seems related:

https://community.nxp.com/thread/309730
[Fire Android Development] DragonFire1024:
Says the same exact thing in init.mt8173. though still not a clue what it does or means. Also this is interesting. Again no clue but it does mention more build type variables

#
#emsvr service (start)
#
on property:ro.build.type=eng
start emsvr

on property:ro.build.type=user
start emsvr_user

on property:ro.build.type=userdebug
start emsvr_user

service emsvr_user /system/bin/em_svr
disabled
user system
group system radio diag

service emsvr /system/bin/em_svr
disabled
user root

#
#emsvr service (end)
#

Do I read this right that it says it enables root user?
[Fire Android Development] Droidriven:
Yeah, down at the end where it says:

user root

#

I would take that to mean that root is being enabled since it drops to the # symbol, that would make whatever is running next to run under root.
[Fire Android Development] DragonFire1024:
I found a bin that works for em_svr but it requires a library file libem_support_jni.so. I found one but either it doesn't work or I have to install it before the bin. I'll test more later.
[Fire Android Development] DragonFire1024:
Put my test tablet to ro.build.type=eng. Rebooted and the screen was flashing a red border around the frame and I couldn't get any screen to stay on. Apparently it's strict mode. I didn't know that and did a factory reset. So now I'm reflashing. So good news is, it doesn't brick you. Just have to do a setprop in a root shell or adb:

persist.sys.strictmode.visual 0
persist.sys.strictmode.disable 1

Supposedly that fixes the issue. I haven't gotten to that point yet.

In beefdeed news, I may have found it's fingerprint. It is a fingerprint, the question is of what?
[Fire Android Development] DragonFire1024:
Well I am fairly confident usbdl is still active or at least can be activated. It looks like the whole command lines are all there still.

What is or might be 'CA Training'? It's mentioned a few times after some kind of operations are done with DRAM.

Lastly for tonight, there are a string of shell commands where DA verifying is done. In that set there is a line that says the device is "a production device with an unsigned kernel. Flash device with eng kernel". I don't know how much weight that holds if any.

So far that's all the interesting stuff I have found and I'm not even 1/4 the way through. I've been busy so I haven't been home much. As soon as I have time I will zip these bad boys for you guys.
[Fire Android Development] DragonFire1024:
Ok so I switched test tablet to ro.build.type=eng and used some persist props to disable strict mode on reboot. The device reboots, adb works but I think the systemui crashes because I get a black screen and a minute later the device soft reboots. So I had to setprop userdebug. This needs more investigating.

Secondly I also did a setprop to persist.sys.usb.config=mtp,adb,acm and got an immediate response. A driver needs to be installed and my PC didn't find it:

CDC ACM Data (No driver found).

Another driver also was installed or at least is now being used:

MediaTek USB VCOM (Android) (COM 37)

So we have something here. If anyone could elaborate.. [MENTION=8132642]diplomatic[/MENTION] ?

---------- Post added at 10:55 AM ---------- Previous post was at 10:46 AM ----------

CDC ACM Data:

https://simba-os.readthedocs.io/en/7.0.1/library-reference/drivers/usb_device/cdc.html

Well...is this of any use to us? At least we know it works and we can get drivers for it.

---------- Post added at 10:59 AM ---------- Previous post was at 10:55 AM ----------

Holy crap. MediaTek USB VCOM (android) (COM37) is Mediaek Preloader driver. It's activated upon adding the USB persist prop acm :D