Minionguyjpro / android_device_samsung_gtowifi

Device tree for Galaxy Tab A 8.0 (2019) [SM-T290]
0 stars 0 forks source link

Help with adding decryption support #1

Open Minionguyjpro opened 3 months ago

Minionguyjpro commented 3 months ago

@lopestom, I would like to add decryption support for this device. I've seen that there are possibilities with Qualcomm as SoC. I've also seen some other Samsung devices that got successful decryption support to work with a Qualcomm SoC. The recovery partition here is 64MB which should be more than enough to get decryption support implemented. I've tried the steps from https://github.com/TeamWin/android_device_qcom_twrp-common already. I've done everything accordingly, but I still don't get prompted in TWRP to decrypt the data nor is there an option when I look in the Mount menu. Would you have any ideas?

And yes, I've been able to build it successfully since those changes and it boots up. But it's just that there are no prompts or anything that says me that it loads or works (it would be useful for myself to have this implemented too)...

lopestom commented 3 months ago

@lopestom, I would like to add decryption support for this device. I've seen that there are possibilities with Qualcomm as SoC. I've also seen some other Samsung devices that got successful decryption support to work with a Qualcomm SoC. The recovery partition here is 64MB which should be more than enough to get decryption support implemented. I've tried the steps from https://github.com/TeamWin/android_device_qcom_twrp-common already. I've done everything accordingly, but I still don't get prompted in TWRP to decrypt the data nor is there an option when I look in the Mount menu. Would you have any ideas?

And yes, I've been able to build it successfully since those changes and it boots up. But it's just that there are no prompts or anything that says me that it loads or works (it would be useful for myself to have this implemented too)...

Let's go step by step: 1- Know the type of decryption. Show/Detail the files!;

2- Even in Qualcomm, it is necessary to study the possibility of using the common repository, insert the specific flags, the correct file in init.recovery.[qti].rc and ALL the files and folders related to the type of decryption, in addition to the prepdecrypt.sh file. But you pointed to the android-11 branch and you should check according to the Android version. Maybe the android-8.1 or android-9 branch might be better?;

3- In the README.md file of each branch there are instructions, so I don't see anything complicated for you to do as described and test.

It's other device? Other DT?

Minionguyjpro commented 3 months ago

@lopestom, I would like to add decryption support for this device. I've seen that there are possibilities with Qualcomm as SoC. I've also seen some other Samsung devices that got successful decryption support to work with a Qualcomm SoC. The recovery partition here is 64MB which should be more than enough to get decryption support implemented. I've tried the steps from https://github.com/TeamWin/android_device_qcom_twrp-common already. I've done everything accordingly, but I still don't get prompted in TWRP to decrypt the data nor is there an option when I look in the Mount menu. Would you have any ideas?

And yes, I've been able to build it successfully since those changes and it boots up. But it's just that there are no prompts or anything that says me that it loads or works (it would be useful for myself to have this implemented too)...

Let's go step by step: 1- Know the type of decryption. Show/Detail the files!;

2- Even in Qualcomm, it is necessary to study the possibility of using the common repository, insert the specific flags, the correct file in init.recovery.[qti].rc and ALL the files and folders related to the type of decryption, in addition to the prepdecrypt.sh file. But you pointed to the android-11 branch and you should check according to the Android version. Maybe the android-8.1 or android-9 branch might be better?;

3- In the README.md file of each branch there are instructions, so I don't see anything complicated for you to do as described and test.

It's other device? Other DT?

Yes, it's another device. This tablet ended with running Android 11 by stock and that branch seems to run fine. I will try to get some screenshots soon.

Minionguyjpro commented 3 months ago

I have tried twrp decrypt <PASSWORD> but it cannot decrypt the data.

lopestom commented 3 months ago

I have tried twrp decrypt <PASSWORD> but it cannot decrypt the data.

If you add files and all taht decrypt need so no good - you can using multidisabler file (search in any samsung TWRP repository) to try.

Minionguyjpro commented 3 months ago

I have tried twrp decrypt <PASSWORD> but it cannot decrypt the data.

If you add files and all taht decrypt need so no good - you can using multidisabler file (search in any samsung TWRP repository) to try.

Sorry, what do you mean? I know Multidisabler exists but that's permanent and needs a wipe of the data right? I feel like it should be possible to get decryption to work somehow here.

Minionguyjpro commented 3 months ago

@lopestom, I would like to add decryption support for this device. I've seen that there are possibilities with Qualcomm as SoC. I've also seen some other Samsung devices that got successful decryption support to work with a Qualcomm SoC. The recovery partition here is 64MB which should be more than enough to get decryption support implemented. I've tried the steps from https://github.com/TeamWin/android_device_qcom_twrp-common already. I've done everything accordingly, but I still don't get prompted in TWRP to decrypt the data nor is there an option when I look in the Mount menu. Would you have any ideas?

And yes, I've been able to build it successfully since those changes and it boots up. But it's just that there are no prompts or anything that says me that it loads or works (it would be useful for myself to have this implemented too)...

Let's go step by step: 1- Know the type of decryption. Show/Detail the files!;

2- Even in Qualcomm, it is necessary to study the possibility of using the common repository, insert the specific flags, the correct file in init.recovery.[qti].rc and ALL the files and folders related to the type of decryption, in addition to the prepdecrypt.sh file. But you pointed to the android-11 branch and you should check according to the Android version. Maybe the android-8.1 or android-9 branch might be better?;

3- In the README.md file of each branch there are instructions, so I don't see anything complicated for you to do as described and test.

It's other device? Other DT?

  1. It shows random directories with random, ID like names
  2. Answered the previous time.
  3. Agreed, but I did those steps and it still doesn't seem to bring it any further...
lopestom commented 3 months ago
  1. It shows random directories with random, ID like names

Missing files or something in the decryption script may be messing up the final process.

Random letters and numbers = encryption exists but could not be decrypted.

Minionguyjpro commented 3 months ago
  1. It shows random directories with random, ID like names

Missing files or something in the decryption script may be messing up the final process.

Random letters and numbers = encryption exists but could not be decrypted.

I still would like to continue to try to get it to work. Is decryption just temporarily with TWRP? Not that it fully removes the encryption but TWRP can use the password to decrypt it, but still keep the REAL encryption. I'm fine with having to enter my password with an OTA everytime for example, it makes things easier afterwards with addon.d scripts.

lopestom commented 3 months ago

Is decryption just temporarily with TWRP?

script decrypt file work for each booting in the TWRP so not have temporary because you need put password to enable or not putting password so not acess \Data. Therefore you have decrypt working or not have!!

Not that it fully removes the encryption but TWRP can use the password to decrypt it, but still keep the REAL encryption.

Agree with the think. But only you can solve that with tests.

Minionguyjpro commented 3 months ago

Is decryption just temporarily with TWRP?

script decrypt file work for each booting in the TWRP so not have temporary because you need put password to enable or not putting password so not acess \Data. Therefore you have decrypt working or not have!!

Not that it fully removes the encryption but TWRP can use the password to decrypt it, but still keep the REAL encryption.

Agree with the think. But only you can solve that with tests.

That first thing you said is what I meant actually with temporary (ideal in my eyes, you still keep your data protected that way for other things). Not sure what to try now but I will look further into decryption with Qualcomm on Samsung and see...

Minionguyjpro commented 3 months ago

Any idea what to do next on this device here?

lopestom commented 3 months ago

Any idea what to do next on this device here?

Look and search more dependencies as https://github.com/moto8937-twrp/android_device_motorola_msm8937-common/tree/twrp/recovery/root

https://github.com/nichcream/android_device_xiaomi_msm8937-twrp/tree/android-8.1/recovery/root/odm/lib64 https://github.com/nichcream/android_device_xiaomi_msm8937-twrp/tree/fp/cryptfs_hw

https://github.com/SHRP-Devices/device_xiaomi_tiare/tree/android-9.0/recovery/root/vendor/lib64

& others.......

Minionguyjpro commented 3 months ago

This device is using FBE by the way, so I'm not sure whether cryptfs_hw is relevant??? Everyone else is.

Minionguyjpro commented 3 months ago

This part is confusing me: https://github.com/TeamWin/android_device_qcom_twrp-common/tree/android-11#prerequisites

It says vendor service binaries and dependencies, but below that it says that the binaries should be placed in system/bin for Android 10 and newer device trees.

So where should I place what? Should I place the binaries from gatekeeper, qseecomd etc. in vendor or in system (those binaries exist in both partitions by the way).

EDIT: My bad, looking in another Samsung device tree with decryption support and in the Qualcomm common tree with the RC files solved my confusion. Changes have been made accordingly and it's time to rebuild! I feel like it should work. Only problem? I'm running a custom ROM on this tablet. Would decryption work at all with custom ROMs like LineageOS?

lopestom commented 3 months ago

that the binaries should be placed in system/bin for Android 10 and newer device trees.

Yes! Same tip that I wrote here: https://github.com/Minionguyjpro/android_device_samsung_a2corelte/issues/2#issuecomment-2293432431

I'm running a custom ROM on this tablet. Would decryption work at all with custom ROMs like LineageOS?

Depend about version of stock ROM and version of LOS. If same so I think it's confirmed. But if LOS has more tahn stock and support for old/new decrypt. As you write about device Samsung Galaxy Tab A 8.0 so Android 8.0? LOS is really Custom ROM and not GSI?! If Custom ROM: depend of the mainteiner. If GSI: In some GSI A11+ (depend of mainteiner and the GSI name) the FDE decryption mode is obsolete how G ordened so should has only FBE decryption mode.

This device is using FBE by the way, so I'm not sure whether cryptfs_hw is relevant??? Everyone else is.

As you wrote so only tests to know if decrypt working or not. Can happen: Work in stock ROM but not in the GSI/Custom ROM.

With my devices in the stock ROM using Custom ROMs or/and GSI the decryption always worked.

PS:

Minionguyjpro commented 3 months ago

that the binaries should be placed in system/bin for Android 10 and newer device trees.

Yes! Same tip that I wrote here: Minionguyjpro/android_device_samsung_a2corelte#2 (comment)

I'm running a custom ROM on this tablet. Would decryption work at all with custom ROMs like LineageOS?

Depend about version of stock ROM and version of LOS. If same so I think it's confirmed. But if LOS has more tahn stock and support for old/new decrypt. As you write about device Samsung Galaxy Tab A 8.0 so Android 8.0? LOS is really Custom ROM and not GSI?! If Custom ROM: depend of the mainteiner. If GSI: In some GSI A11+ (depend of mainteiner and the GSI name) the FDE decryption mode is obsolete how G ordened so should has only FBE decryption mode.

This device is using FBE by the way, so I'm not sure whether cryptfs_hw is relevant??? Everyone else is.

As you wrote so only tests to know if decrypt working or not. Can happen: Work in stock ROM but not in the GSI/Custom ROM.

With my devices in the stock ROM using Custom ROMs or/and GSI the decryption always worked.

PS:

* I never had device with A8.0 and A8.1;

* like I know the A8.0 not have support to GSI (Treble ROM) so only with A8.1+.

No, this device came with Android 9.0 Pie and got up to Android 11 (by stock). I am running Android 14 with LineageOS on this. That A 8.0 just says that it's 8 inches big.

Minionguyjpro commented 3 months ago

that the binaries should be placed in system/bin for Android 10 and newer device trees.

Yes! Same tip that I wrote here: Minionguyjpro/android_device_samsung_a2corelte#2 (comment)

I'm running a custom ROM on this tablet. Would decryption work at all with custom ROMs like LineageOS?

Depend about version of stock ROM and version of LOS. If same so I think it's confirmed. But if LOS has more tahn stock and support for old/new decrypt. As you write about device Samsung Galaxy Tab A 8.0 so Android 8.0? LOS is really Custom ROM and not GSI?! If Custom ROM: depend of the mainteiner. If GSI: In some GSI A11+ (depend of mainteiner and the GSI name) the FDE decryption mode is obsolete how G ordened so should has only FBE decryption mode.

This device is using FBE by the way, so I'm not sure whether cryptfs_hw is relevant??? Everyone else is.

As you wrote so only tests to know if decrypt working or not. Can happen: Work in stock ROM but not in the GSI/Custom ROM.

With my devices in the stock ROM using Custom ROMs or/and GSI the decryption always worked.

PS:

* I never had device with A8.0 and A8.1;

* like I know the A8.0 not have support to GSI (Treble ROM) so only with A8.1+.

I will check what files are currently in the system partition with my custom ROM. If the same ones are in, then I expect this to probably work??? I did however also see some people using a linkblobs.sh file for different versions of Android, linking some libraries it seemed.

EDIT: Great, seems like I have good luck! Just checked and the same files seem to be in the vendor (I had to take some of the files in system/bin from the vendor partition too), and I know my custom ROM has actually a different boot, system and vendor with the custom ROM (I guess you have those custom with any custom ROM). Going to do another build soon and try it out. Otherwise, I hope I may be able to find some people on XDA that are wanting to test it out (if they still have the stock).

EDIT 2: I am trying to build with the 12.1 branch for now, if it doesn't work then I'll try branch 11 as before.

EDIT 3: Ah great I get issues with the specified architectures when building once again...

Minionguyjpro commented 3 months ago

Stuck on TWRP logo now, gets stuck on: init: Control message: Could not find 'android.hardware.keymaster@4.0::IKeymasterDevice/default' for ctl.interface_start from pid: 370 (/system/bin/hwservicemanager) The manifest that provides it is however included (VINTF manifests).

Minionguyjpro commented 3 months ago

init: Control message: Could not find 'android.hardware.keymaster@4.0::IKeymasterDevice/default' for ctl.interface_start from pid: 370 (/system/bin/hwservicemanager)

Seems like it didn't add the init.recovery.qcom_decrypt.rc and init.recovery.qcom_decrypt.fbe.rc somehow... Seems normal, it did try to start the things it should start though.

It is referenced in the main init RC file plus it's added as package in the device.mk file.

EDIT: Also some libraries seem to be missing. I thought I added all of them but it seems not?

EDIT 2: All of them have now been added.

EDIT 3: Same error, but this is there though: https://github.com/Minionguyjpro/android_device_samsung_gtowifi/blob/twrp-11/recovery/root/vendor/etc/vintf/manifest.xml#L128-L137

lopestom commented 3 months ago

No, this device came with Android 9.0 Pie and got up to Android 11 (by stock). I am running Android 14 with LineageOS on this. That A 8.0 just says that it's 8 inches big.

Great. So device has fully support....

Stuck on TWRP logo now, gets stuck on: init: Control message: Could not find 'android.hardware.keymaster@4.0::IKeymasterDevice/default' for ctl.interface_start from pid: 370 (/system/bin/hwservicemanager) The manifest that provides it is however included (VINTF manifests).

When stucked in TWRP Logo so need fix decryption part (script or and binary/dependencies files). But so is a way to know that's getting something to understand that can work.

What's reason you not enable this? https://github.com/Minionguyjpro/android_device_samsung_gtowifi/blob/5e2b56866b471af8cbb8a0528f4d810f97a4e3ac/BoardConfig.mk#L112-L115

Minionguyjpro commented 3 months ago

No, this device came with Android 9.0 Pie and got up to Android 11 (by stock). I am running Android 14 with LineageOS on this. That A 8.0 just says that it's 8 inches big.

Great. So device has fully support....

Stuck on TWRP logo now, gets stuck on: init: Control message: Could not find 'android.hardware.keymaster@4.0::IKeymasterDevice/default' for ctl.interface_start from pid: 370 (/system/bin/hwservicemanager) The manifest that provides it is however included (VINTF manifests).

When stucked in TWRP Logo so need fix decryption part (script or and binary/dependencies files). But so is a way to know that's getting something to understand that can work.

What's reason you not enable this?

https://github.com/Minionguyjpro/android_device_samsung_gtowifi/blob/5e2b56866b471af8cbb8a0528f4d810f97a4e3ac/BoardConfig.mk#L112-L115

Ah so I have accidentally disabled those. Well anyways HW_DISK_ENCRYPTION should be kept off, this device doesn't use HW disk encryption. /data shows correctly now and has subfolders which have does random character, encrypted directories in it. But still, I don't think that init thing is related to it although I am not completely sure.

lopestom commented 3 months ago

Ah so I have accidentally disabled those. Well anyways HW_DISK_ENCRYPTION should be kept off, this device doesn't use HW disk encryption. /data shows correctly now and has subfolders which have does random character, encrypted directories in it. But still, I don't think that init thing is related to it although I am not completely sure.

I think so.......

Your DT base? https://github.com/Magendanz/android_device_samsung_gtowifi/blob/twrp-11/twrp_gtowifi.mk

Maybe Help?

https://github.com/Magendanz/android_device_samsung_gta4lwifi/blob/3db907f67813b33d99004bb45124389a23bdd216/BoardConfig.mk#L129

https://github.com/Magendanz/android_device_samsung_gta4lwifi/blob/3db907f67813b33d99004bb45124389a23bdd216/BoardConfig.mk#L163

Maybe not?

Need more than https://github.com/Minionguyjpro/android_device_samsung_gtowifi/blob/twrp-11/device.mk so looking for https://github.com/Magendanz/android_device_samsung_gta4lwifi/blob/master/device.mk

Interresting?! https://github.com/Magendanz/android_device_samsung_gta3xlwifi/blob/twrp-11/configs/exynos7885-gta3xlwifi-noknox_defconfig

https://github.com/YZBruh/android_device_samsung_gtowifi/blob/2dbb7955c353961c62fd0f12ef551a98d912180d/twrp_gtowifi.mk#L26-L29

https://github.com/auraknighted/android_device_samsung_gtowifi/blob/twrp-12.1/twrp_gtowifi.mk

https://github.com/LMODroid-Devices/device_samsung_gtowifi/blob/fourteen/BoardConfig.mk

I not see in the LSLS and https://github.com/Minionguyjpro/android_device_samsung_gtowifi/blob/f1163da1bf540b90dcba3e3d2c6e280ce8a1ca14/recovery/root/system/etc/twrp.flags#L18 this https://github.com/Kelsidavis/android_device_samsung_gtowifi/blob/ace21de7feff585e3ce8c1cad640b6429fc9c558/rootdir/etc/fstab.qcom#L41 fileencryption=ice,quota,reservedsize=128M

Show any fstab stock file to know about.

init: Control message: Could not find 'android.hardware.keymaster@4.0::IKeymasterDevice/default' for ctl.interface_start from pid: 370 (/system/bin/hwservicemanager)

this? https://github.com/TheMuppets/proprietary_vendor_samsung_gtowifi/blob/lineage-21/proprietary/vendor/etc/init/android.hardware.keymaster%404.0-service-qti.rc

more libs? https://github.com/TheMuppets/proprietary_vendor_samsung_gtowifi/tree/lineage-21/proprietary/vendor/lib64 https://github.com/TheMuppets/proprietary_vendor_samsung_gtowifi/tree/lineage-21/proprietary/system_ext/lib64

Minionguyjpro commented 3 months ago

Your DT base? https://github.com/Magendanz/android_device_samsung_gtowifi/blob/twrp-11/twrp_gtowifi.mk

Yes, it is. I forked it as you can see.

Maybe Help?

https://github.com/Magendanz/android_device_samsung_gta4lwifi/blob/3db907f67813b33d99004bb45124389a23bdd216/BoardConfig.mk#L129

https://github.com/Magendanz/android_device_samsung_gta4lwifi/blob/3db907f67813b33d99004bb45124389a23bdd216/BoardConfig.mk#L163

Maybe not?

I added them but am not sure what the TW_BIND_SYSTEM does. I also added the others (most of it).

fstab.qcom:

# Copyright (c) 2018, The Linux Foundation. All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are
# met:
#     * Redistributions of source code must retain the above copyright
#       notice, this list of conditions and the following disclaimer.
#     * Redistributions in binary form must reproduce the above
#       copyright notice, this list of conditions and the following
#       disclaimer in the documentation and/or other materials provided
#       with the distribution.
#     * Neither the name of The Linux Foundation nor the names of its
#       contributors may be used to endorse or promote products derived
#       from this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESS OR IMPLIED
# WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT
# ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
# BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
# BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
# WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
# OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
# IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

# Android fstab file.
# 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

#TODO: Add 'check' as fs_mgr_flags with data partition.
# Currently we dont have e2fsck compiled. So fs check would failed.

#<src>                                      <mnt_point>        <type>  <mnt_flags and options>                     <fs_mgr_flags>
/dev/block/bootdevice/by-name/system         /                  ext4    ro,barrier=1,discard                        wait
/dev/block/bootdevice/by-name/userdata  /data   ext4    noatime,nosuid,nodev,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic latemount,wait,check,fileencryption=ice,quota,reservedsize=128M
/dev/block/bootdevice/by-name/config         /frp               emmc    defaults                                    defaults
/dev/block/bootdevice/by-name/misc  /misc   emmc    defaults    defaults,first_stage_mount
/dev/block/bootdevice/by-name/cache /cache  ext4    noatime,nosuid,nodev,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic wait,check
/dev/block/bootdevice/by-name/dsp            /vendor/dsp               ext4    ro,nosuid,nodev,barrier=1                   wait
/dev/block/bootdevice/by-name/apnhlos          /vendor/firmware_mnt   vfat    ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337,context=u:object_r:firmware_file:s0 wait
/dev/block/bootdevice/by-name/modem          /vendor/firmware-modem   vfat    ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337,context=u:object_r:firmware_file:s0 wait
/dev/block/bootdevice/by-name/persist   /mnt/vendor/persist ext4    noatime,nosuid,nodev,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic wait,check
#/dev/block/bootdevice/by-name/efs      /mnt/vendor/efs        ext4    nosuid,nodev,noatime,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic wait,check
#/dev/block/bootdevice/by-name/sec_efs      /efs                   ext4    nosuid,nodev,noatime,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic wait,check
#/dev/block/bootdevice/by-name/omr      /omr                   ext4    nosuid,nodev,noatime,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic wait,check
#/dev/block/bootdevice/by-name/carrier      /carrier               ext4    nosuid,nodev,noatime,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic wait,check,nofail

# VOLD:fstab.samsung (samsung/common/fstab.samsung)
#/devices/soc/7864900.sdhci/mmc_host*         /storage/sdcard1   vfat    nosuid,nodev                                wait,voldmanaged=sdcard1:auto,noemulatedsd,encryptable=footer
#/devices/soc/78db000.usb/msm_hsusb_host*     /storage/usbotg    vfat    nosuid,nodev                                wait,voldmanaged=usbotg:auto
/devices/platform/soc/7864900.sdhci/mmc_host*        auto    vfat    defaults    voldmanaged=sdcard:auto
/devices/platform/soc/78db000.usb/msm_hsusb_host*    auto    auto    defaults    voldmanaged=usb:auto

The binaries are already there. That error should be related due to the missing manifests (of HAL). I've looked through the manifests (from VINTF) and found exactly what it was bothering about. It was however already added, so I'm not sure what's causing it now. I don't think it are libraries, although also not sure what else

EDIT: I'm stupid, I may indeed need that init RC file. It makes sure to load the HALs early, so it is ready for hwservicemanager, keymaster etc.

Minionguyjpro commented 3 months ago
[   14.339255] init: starting service 'keymaster-4-0'...
[   14.344537] init: Service 'keymaster-4-0' (pid 477) exited with status 1
[   14.344622] init: Sending signal 9 to service 'keymaster-4-0' (pid 477) process group...

This happens when init tries to start keymaster from the /vendor/etc/init/android.hardware.keymaster@4.0-service-qti.rc (Yes I edited it accordingly, in my environment).

EDIT: My bad, I know the problem here.

EDIT 2: Yes but nope, the whole problem from init with IKeymaster is still not fixed.

Minionguyjpro commented 3 months ago

YES IT IS BACK TO BOOTING, I didn't get any prompts to decrypt data yet...

EDIT: Decryption doesn't seem to work yet.

lopestom commented 3 months ago

YES IT IS BACK TO BOOTING, I didn't get any prompts to decrypt data yet...

EDIT: Decryption doesn't seem to work yet.

You are on the right track. Keep it up and if you still have problems then think beyond the wall.

Minionguyjpro commented 3 months ago

YES IT IS BACK TO BOOTING, I didn't get any prompts to decrypt data yet... EDIT: Decryption doesn't seem to work yet.

You are on the right track. Keep it up and if you still have problems then think beyond the wall.

I just don't know when it will show the unlock prompt (it doesn't yet). I have heard though about Samsung encryption not working in TWRP 3.x.x, although I have seen Samsung device trees with Qualcomm SoCs where it just works fine. So I guess it must be possible.

Minionguyjpro commented 3 months ago

What if I just enable TW_INCLUDE_CRYPTO_SAMSUNG hmmm...

lopestom commented 3 months ago

What if I just enable TW_INCLUDE_CRYPTO_SAMSUNG hmmm...

https://gerrit.twrp.me/plugins/gitiles/android_bootable_recovery/+/6ff55cefd060b4c8f6c0fa97d5521516f9ee43f1/crypto/cryptfs/cryptfs.c

lopestom commented 3 months ago

fstab.qcom:

https://github.com/TeamWin/android_device_samsung_hltecan/blob/a8ac6c4d744c312707f5504ddcaf56a9c780343b/recovery/root/init.recovery.qcom.rc#L6

https://github.com/TeamWin/android_device_samsung_hlteskt/blob/50dbf438ffff5038d2db2398b496fb4540dd03a3/BoardConfig.mk#L67

https://github.com/TeamWin/Team-Win-Recovery-Project/issues/263

TW_INCLUDE_CRYPTO_SAMSUNG - support for decrypting /data on Samsung devices


https://github.com/TeamWin/android_device_samsung_hlteskt/blob/50dbf438ffff5038d2db2398b496fb4540dd03a3/BoardConfig.mk#L71

Maybe need:

TW_USE_FSCRYPT_POLICY := 1

https://gerrit.twrp.me/c/android_bootable_recovery/+/3570


Understand more FDE&FBE:

https://github.com/Mi-Thorium/twrp_device_xiaomi_mithorium-common/blob/9ca53675126636420b980d05b81644d1cb1fd3af/BoardConfigCommon.mk#L97-L110

https://github.com/Mi-Thorium/twrp_device_xiaomi_mithorium-common/blob/9ca53675126636420b980d05b81644d1cb1fd3af/recovery/root/init.recovery.qcom.rc#L15


Not understand about init.recovery.{hardware}.rc with usb paths?! https://github.com/Minionguyjpro/android_device_samsung_gtowifi/blob/twrp-11/recovery/root/init.recovery.qcom.rc

Where's \firmware and others mountpoint fs??

/dev/block/bootdevice/by-name/apnhlos /vendor/firmware_mnt vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337,context=u:object_r:firmware_file:s0 wait /dev/block/bootdevice/by-name/modem /vendor/firmware-modem vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337,context=u:object_r:firmware_file:s0 wait /dev/block/bootdevice/by-name/persist /mnt/vendor/persist ext4 noatime,nosuid,nodev,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic wait,check

/dev/block/bootdevice/by-name/efs /mnt/vendor/efs ext4 nosuid,nodev,noatime,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic wait,check

/dev/block/bootdevice/by-name/sec_efs /efs ext4 nosuid,nodev,noatime,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic wait,check

https://github.com/Mi-Thorium/twrp_device_xiaomi_mithorium-common/blob/9ca53675126636420b980d05b81644d1cb1fd3af/recovery/root/init.recovery.qcom.rc#L13-L15

Minionguyjpro commented 3 months ago

fstab.qcom:

https://github.com/TeamWin/android_device_samsung_hltecan/blob/a8ac6c4d744c312707f5504ddcaf56a9c780343b/recovery/root/init.recovery.qcom.rc#L6

https://github.com/TeamWin/android_device_samsung_hlteskt/blob/50dbf438ffff5038d2db2398b496fb4540dd03a3/BoardConfig.mk#L67

TeamWin/Team-Win-Recovery-Project#263

TW_INCLUDE_CRYPTO_SAMSUNG - support for decrypting /data on Samsung devices

https://github.com/TeamWin/android_device_samsung_hlteskt/blob/50dbf438ffff5038d2db2398b496fb4540dd03a3/BoardConfig.mk#L71

Maybe need:

TW_USE_FSCRYPT_POLICY := 1

https://gerrit.twrp.me/c/android_bootable_recovery/+/3570

Understand more FDE&FBE:

https://github.com/Mi-Thorium/twrp_device_xiaomi_mithorium-common/blob/9ca53675126636420b980d05b81644d1cb1fd3af/BoardConfigCommon.mk#L97-L110

https://github.com/Mi-Thorium/twrp_device_xiaomi_mithorium-common/blob/9ca53675126636420b980d05b81644d1cb1fd3af/recovery/root/init.recovery.qcom.rc#L15

Not understand about init.recovery.{hardware}.rc with usb paths?! https://github.com/Minionguyjpro/android_device_samsung_gtowifi/blob/twrp-11/recovery/root/init.recovery.qcom.rc

Where's \firmware and others mountpoint fs??

/dev/block/bootdevice/by-name/apnhlos /vendor/firmware_mnt vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337,context=u:object_r:firmware_file:s0 wait /dev/block/bootdevice/by-name/modem /vendor/firmware-modem vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337,context=u:object_r:firmware_file:s0 wait /dev/block/bootdevice/by-name/persist /mnt/vendor/persist ext4 noatime,nosuid,nodev,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic wait,check

/dev/block/bootdevice/by-name/efs /mnt/vendor/efs ext4 nosuid,nodev,noatime,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic wait,check

/dev/block/bootdevice/by-name/sec_efs /efs ext4 nosuid,nodev,noatime,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic wait,check

https://github.com/Mi-Thorium/twrp_device_xiaomi_mithorium-common/blob/9ca53675126636420b980d05b81644d1cb1fd3af/recovery/root/init.recovery.qcom.rc#L13-L15

I can tell you though that there is nothing related to keymaster and cmnlib in the modem, but there are a seperate keymaster, keymasterbak and cmnlib (plus cmnlib64 and cmnlib64bak) partition (although I'm not able to mount it).

Found this in /sec_efs/pdp_bkup:

2022-05-31 02:33:54+0000  [normal] mp3 file copy : done 

2022-05-31 02:33:33+0000  [normal] mp3 file copy : done 

2022-05-31 02:33:48+0000  [normal] mp3 file copy : done 

2020-01-01 00:00:05+0000  [normal] package verification : success
2020-01-01 00:00:13+0000  [normal] -----------------------------------------------------
2020-01-01 00:00:13+0000  [normal] prepare FBE : done 
2020-01-01 00:00:21+0000  [normal] apks size at /d/a= 606907560, just after p.FBE/restore/pre.App-copy
2022-05-31 02:30:34+0000  [normal] result : /d /a apks size= 606907560

2022-05-31 02:30:35+0000  [normal] mp3 file copy : done 

Probably only relevant to copying some APK packages with FBE.

All partitions in this device:

aboot         bota          cmnlibbak     devinfo       efs           keystore      misc          mota          persist       rpmbak        ssd           userdata
abootbak      btd           config        dip           em            limits        mmcblk0       msadp         persistent    sbl1          steady        vbmeta
apdp          cache         ddr           dpo           fsc           logdump       mmcblk0rpmb   oem           product       sbl1bak       syscfg        vbmetabak
apnhlos       cmnlib        debug         dsp           fsg           mcfg          modem         omr           recovery      sec           system        vendor
bksecapp      cmnlib64      devcfg        dspbak        keymaster     mdtp          modemst1      pad           reserved      sec_efs       tz            vk
boot          cmnlib64bak   devcfgbak     dtbo          keymasterbak  mdtpbak       modemst2      param         rpm           splash        tzbak

Firmware image files in apnhlos:

adsp.b00  adsp.b14      cmnlib64.b05  cpe_9335.b29  dhsecapp.b04  fingerpr.b05  isdbtmm.b00  mdtp.b06      qmpsecap.b04  skm.b02      vaultkee.b00  wcnss.b00     widevine.b04
adsp.b01  adsp.mdt      cmnlib64.mdt  cpe_9335.mdt  dhsecapp.b05  fingerpr.b05  isdbtmm.b01  mdtp.mdt      qmpsecap.b05  skm.b03      vaultkee.b01  wcnss.b01     widevine.b05
adsp.b02  cmnlib.b00    cpe_9335.b08  cppf.b00      dhsecapp.b06  fingerpr.b06  isdbtmm.b02  prov.b00      qmpsecap.b06  skm.b04      vaultkee.b02  wcnss.b02     widevine.b06
adsp.b03  cmnlib.b01    cpe_9335.b09  cppf.b01      dhsecapp.mdt  fingerpr.b06  isdbtmm.b03  prov.b01      qmpsecap.mdt  skm.b05      vaultkee.b03  wcnss.b04     widevine.mdt
adsp.b04  cmnlib.b02    cpe_9335.b11  cppf.b02      fingerpr.b00  fingerpr.mdt  isdbtmm.b04  prov.b02      securemm.b00  skm.b06      vaultkee.b04  wcnss.b06
adsp.b05  cmnlib.b03    cpe_9335.b14  cppf.b03      fingerpr.b00  fingerpr.mdt  isdbtmm.b05  prov.b03      securemm.b01  skm.mdt      vaultkee.b05  wcnss.b09
adsp.b06  cmnlib.b04    cpe_9335.b16  cppf.b04      fingerpr.b01  gptest.b00    isdbtmm.b06  prov.b04      securemm.b02  soter64.b00  vaultkee.b06  wcnss.b10
adsp.b07  cmnlib.b05    cpe_9335.b18  cppf.b05      fingerpr.b01  gptest.b01    isdbtmm.mdt  prov.b05      securemm.b03  soter64.b01  vaultkee.mdt  wcnss.b11
adsp.b08  cmnlib.mdt    cpe_9335.b19  cppf.b06      fingerpr.b02  gptest.b02    mdtp.b00     prov.b06      securemm.b04  soter64.b02  venus.b00     wcnss.b12
adsp.b09  cmnlib64.b00  cpe_9335.b20  cppf.mdt      fingerpr.b02  gptest.b03    mdtp.b01     prov.mdt      securemm.b05  soter64.b03  venus.b01     wcnss.mdt
adsp.b10  cmnlib64.b01  cpe_9335.b22  dhsecapp.b00  fingerpr.b03  gptest.b04    mdtp.b02     qmpsecap.b00  securemm.b06  soter64.b04  venus.b02     widevine.b00
adsp.b11  cmnlib64.b02  cpe_9335.b24  dhsecapp.b01  fingerpr.b03  gptest.b05    mdtp.b03     qmpsecap.b01  securemm.mdt  soter64.b05  venus.b03     widevine.b01
adsp.b12  cmnlib64.b03  cpe_9335.b26  dhsecapp.b02  fingerpr.b04  gptest.b06    mdtp.b04     qmpsecap.b02  skm.b00       soter64.b06  venus.b04     widevine.b02
adsp.b13  cmnlib64.b04  cpe_9335.b28  dhsecapp.b03  fingerpr.b04  gptest.mdt    mdtp.b05     qmpsecap.b03  skm.b01       soter64.mdt  venus.mdt     widevine.b03

Interesting, in the persist partition:

gtowifi:/persist # ls
WCNSS_qcom_wlan_nv.bin     alarm      bms        data     drm      hlos_rfs    iar_db      misc  secnvm   time
WCNSS_wlan_dictionary.dat  bluetooth  coresight  display  factory  hvdcp_opti  lost+found  rfs   sensors  vpp
gtowifi:/persist # cd data
gtowifi:/persist/data # ls
keymaster64  sfs  tz  vaultkeeper
gtowifi:/persist/data # cd keymaster64/                                                                                                                                                             
gtowifi:/persist/data/keymaster64 # ls
EbhOQv67PFvnB0XdBqG60QZKTqAAUV15KkqYN+ug3y      fdqo6HXR4uA8AxncB21faLAtRnImrkRYI5HHODiVQu      keymaster64
EbhOQv67PFvnB0XdBqG60QZKTqAAUV15KkqYN+ug3y.bak  fdqo6HXR4uA8AxncB21faLAtRnImrkRYI5HHODiVQu.bak  keymaster64.bak
lopestom commented 3 months ago

All partitions in this device:

Yes so very partitions to think about.

persist; rpmbak; userdata; mmcblk0rpmb; apnhlos; sec; sec_efs; tz; keymaster; rpm; keymasterbak; tzbak;

Firmware image files in apnhlos:

secure..... soter64....... vaultkee.....

They seem interesting.

Interesting, in the persist partition:

I believe you found the treasure: keymaster64 sfs tz vaultkeeper

keymaster64  sfs  tz  vaultkeeper
gtowifi:/persist/data # cd keymaster64/                                                                                                                                                             
gtowifi:/persist/data/keymaster64 # ls
EbhOQv67PFvnB0XdBqG60QZKTqAAUV15KkqYN+ug3y      fdqo6HXR4uA8AxncB21faLAtRnImrkRYI5HHODiVQu      keymaster64
EbhOQv67PFvnB0XdBqG60QZKTqAAUV15KkqYN+ug3y.bak  fdqo6HXR4uA8AxncB21faLAtRnImrkRYI5HHODiVQu.bak  keymaster64.bak
lopestom commented 3 months ago

Has any cryptfs file in the formware? If yes so: https://github.com/vasishath/android_device_xiaomi_beryllium/blob/b544229de83607ad47678354927aa48b44c43307/BoardConfig.mk#L103-L108

https://4pda.to/forum/index.php?showtopic=964238&view=findpost&p=88788048

I didn't see any changes in your DT from my previous suggestions.

https://github.com/vasishath/android_device_xiaomi_beryllium/blob/b544229de83607ad47678354927aa48b44c43307/recovery/root/init.recovery.qcom.rc#L28-L35

Maybe help MicroSD? https://github.com/vasishath/android_device_xiaomi_beryllium/blob/android-9.0/recovery/root/init.recovery.usb.rc https://github.com/vasishath/android_device_xiaomi_beryllium/blob/7fc074d8166f3f16b999ec47dfdf5fba576b0595/omni_beryllium.mk#L25

https://github.com/lopestom/twrp_device_fplus_H166/blob/4cf035860a45dd2c53b444841834cffd5c459ba9/BoardConfig.mk#L209-L218 https://github.com/lopestom/twrp_device_fplus_H166/blob/4cf035860a45dd2c53b444841834cffd5c459ba9/system.prop#L29-L38

https://4pda.to/forum/index.php?showtopic=636604&view=findpost&p=74193556 https://4pda.to/forum/index.php?showtopic=636604&view=findpost&p=89536087 https://4pda.to/forum/index.php?showtopic=636604&view=findpost&p=69439381

Minionguyjpro commented 3 months ago

All partitions in this device:

Yes so very partitions to think about.

persist; rpmbak; userdata; mmcblk0rpmb; apnhlos; sec; sec_efs; tz; keymaster; rpm; keymasterbak; tzbak;

Firmware image files in apnhlos:

secure..... soter64....... vaultkee.....

They seem interesting.

Interesting, in the persist partition:

I believe you found the treasure: keymaster64 sfs tz vaultkeeper

keymaster64  sfs  tz  vaultkeeper
gtowifi:/persist/data # cd keymaster64/                                                                                                                                                             
gtowifi:/persist/data/keymaster64 # ls
EbhOQv67PFvnB0XdBqG60QZKTqAAUV15KkqYN+ug3y      fdqo6HXR4uA8AxncB21faLAtRnImrkRYI5HHODiVQu      keymaster64
EbhOQv67PFvnB0XdBqG60QZKTqAAUV15KkqYN+ug3y.bak  fdqo6HXR4uA8AxncB21faLAtRnImrkRYI5HHODiVQu.bak  keymaster64.bak

If that's so then what should I do now we know about those partitions? Link things in the init file for those or...?

I will try to do your suggestions soon by the way. As you know microSD issues were for the other devices although I feel like those parameters may do some forcing and may make the external SD card get detected (although it doesn't feel logic but you never know).

lopestom commented 3 months ago

If that's so then what should I do now we know about those partitions? Link things in the init file for those or...?

Create a correctly init.recovery.{hardware}.rc and init.recovery.usb.rc files to mount/symlink/execute services, permissions, etc, etc....

Minionguyjpro commented 3 months ago

Has any cryptfs file in the formware? If yes so: https://github.com/vasishath/android_device_xiaomi_beryllium/blob/b544229de83607ad47678354927aa48b44c43307/BoardConfig.mk#L103-L108

https://4pda.to/forum/index.php?showtopic=964238&view=findpost&p=88788048

I didn't see any changes in your DT from my previous suggestions.

https://github.com/vasishath/android_device_xiaomi_beryllium/blob/b544229de83607ad47678354927aa48b44c43307/recovery/root/init.recovery.qcom.rc#L28-L35

Maybe help MicroSD? https://github.com/vasishath/android_device_xiaomi_beryllium/blob/android-9.0/recovery/root/init.recovery.usb.rc https://github.com/vasishath/android_device_xiaomi_beryllium/blob/7fc074d8166f3f16b999ec47dfdf5fba576b0595/omni_beryllium.mk#L25

https://github.com/lopestom/twrp_device_fplus_H166/blob/4cf035860a45dd2c53b444841834cffd5c459ba9/BoardConfig.mk#L209-L218 https://github.com/lopestom/twrp_device_fplus_H166/blob/4cf035860a45dd2c53b444841834cffd5c459ba9/system.prop#L29-L38

https://4pda.to/forum/index.php?showtopic=636604&view=findpost&p=74193556 https://4pda.to/forum/index.php?showtopic=636604&view=findpost&p=89536087 https://4pda.to/forum/index.php?showtopic=636604&view=findpost&p=69439381

It has libcryptfs files, but as we know no hardware disk encryption, so again I'm not sure (here the gtowifi with Android 9-11, not the a2corelte with Android 8.1 Oreo only) whether it's relevant.

lopestom commented 3 months ago

It has libcryptfs files, but as we know no hardware disk encryption, so again I'm not sure (here the gtowifi with Android 9-11, not the a2corelte with Android 8.1 Oreo only) whether it's relevant.

I just guide and indicate something. If he has this or that, you must confirm it! Therefore, you must be sure whether it is FDE (cryptfs) or FBE.

So the https://github.com/Minionguyjpro/android_device_samsung_gtowifi/blob/twrp-11/recovery/root/init.recovery.qcom.rc is not the good script. So where's init.recovery.usb.rc? But can this work? Each TWRP author can choose how to do it as long as it works as intended. If not, change the situation and see if anything changes with it.

The rest you already know, make log files to debug errors/problems/issues.

Minionguyjpro commented 3 months ago

It has libcryptfs files, but as we know no hardware disk encryption, so again I'm not sure (here the gtowifi with Android 9-11, not the a2corelte with Android 8.1 Oreo only) whether it's relevant.

I just guide and indicate something. If he has this or that, you must confirm it! Therefore, you must be sure whether it is FDE (cryptfs) or FBE.

So the https://github.com/Minionguyjpro/android_device_samsung_gtowifi/blob/twrp-11/recovery/root/init.recovery.qcom.rc is not the good script. So where's init.recovery.usb.rc? But can this work? Each TWRP author can choose how to do it as long as it works as intended. If not, change the situation and see if anything changes with it.

The rest you already know, make log files to debug errors/problems/issues.

It's FBE, I'm sure. I am not sure whether an USB init file is needed, as MTP and USB-OTG already work correctly on this device. I will see if I can get dmesg logs tomorrow (and the recovery.log from /tmp). Some errors may show up there which are probably or (1 not relevant or (2 Don't really matter and affect anything.

lopestom commented 3 months ago

t's FBE, I'm sure.

TW_IS_FBE := 1

I am not sure whether an USB init file is needed, as MTP and USB-OTG already work correctly on this device. I will see if I can get dmesg logs tomorrow (and the recovery.log from /tmp).

Great. The usb.rc file is for more organization so separate what really need for each part. But that's works good so as I wrote so your decision.....

Minionguyjpro commented 3 months ago

t's FBE, I'm sure.

TW_IS_FBE := 1

I am not sure whether an USB init file is needed, as MTP and USB-OTG already work correctly on this device. I will see if I can get dmesg logs tomorrow (and the recovery.log from /tmp).

Great. The usb.rc file is for more organization so separate what really need for each part. But that's works good so as I wrote so your decision.....

Let me try...