Minionguyjpro / android_device_samsung_a2corelte

TWRP device tree for the Samsung Galaxy A2 Core (a2corelte)
0 stars 0 forks source link

Decryption Support #2

Open Minionguyjpro opened 3 months ago

Minionguyjpro commented 3 months ago

@lopestom, the new issue. So far I tried:

Minionguyjpro commented 3 months ago

/vendor/etc/init: afbeelding

/system/etc/init (there's more on the top of the directory but it doesn't seem relevant): afbeelding

lopestom commented 3 months ago

Same Issue of Few partitions not mounting because \Data is part of internal storage (sdcard or emulate/0 or storage) and the device manage both so external_sd (MicroSD or sdcard1) too.

The external SD card also doesn't mount, but looking at the dmesg logs it does seem that the driver was loaded and it is looking to detect the card. It finds the slot but never the card...

USB-OTG works fine!

For know the adress to MicroSD and place in the twrp.flags or recovery.fstab https://github.com/TeamWin/android_device_samsung_j7xelte/blob/b0c65814289a4d3e7bd2e7089ec498993fa7cce7/recovery/root/etc/recovery.fstab#L21-L23

https://github.com/farfromrefug/android_device_samsung_universal7870-common/blob/9e16a69524b6e869f68dc53388228f310235cc9b/rootdir/etc/fstab.samsungexynos7870#L18-L21

https://github.com/farfromrefug/android_device_samsung_universal7870-common/blob/9e16a69524b6e869f68dc53388228f310235cc9b/rootdir/etc/twrp.fstab#L13-L14

https://github.com/SHRP-Devices/android_device_samsung_j5y17lte/blob/946ee4b4870fb9ced5a007461281a45b3d469b5b/recovery.fstab#L24

https://github.com/physwizz/m10lte-TWRP-11-dt/tree/main/recovery/root/system/etc

so you need search that in your device: https://gist.github.com/lopestom/3c1f3eaa66248c56e61acf19ddd4b96c#android_device_brand_devicename Read recovery in the android_device_brand_devicename/recovery/root/system/ part of

The recovery.fstab, twrp.fstab or twrp.flags files must.........

and 2.3.4 \recovery\root\system\ specially in the

If the Custom Recovery not mount MicroSDCard and or OTG, you..........

About \Data so look two conditions like same in the https://github.com/KekHunterOS/Samsung-DT/blob/8ce60a4f4614c372238d08d9b7bccaea4d7a4aa9/universal7870-common/rootdir/etc/fstab.samsungexynos7870#L11-L12

maybe wrong? https://github.com/SHRP-Devices/android_device_samsung_j5y17lte/blob/946ee4b4870fb9ced5a007461281a45b3d469b5b/BoardConfig.mk#L48

What I know?! You think writing TW_ flags the Custom Recovery decrypt the device??!! LOL Need stock files in the DT for decrypt so need more in the script decrypt too. Some notes I made prior to this message but I still have doubts because I didn't see any folders\files.

https://github.com/Minionguyjpro/android_device_samsung_a2corelte/blob/621ec0c09fc091f615f66665162fcc7b49b1ad30/recovery/root/prebuilt_file_contexts#L546

https://github.com/Minionguyjpro/android_device_samsung_a2corelte/blob/621ec0c09fc091f615f66665162fcc7b49b1ad30/recovery/root/prebuilt_file_contexts#L854

https://github.com/Minionguyjpro/android_device_samsung_a2corelte/blob/621ec0c09fc091f615f66665162fcc7b49b1ad30/recovery/root/prebuilt_file_contexts#L1392

/dev/ecryptfs           u:object_r:ecryptfs_device:s0
/system/bin/trustonic_tee_proxy u:object_r:trustonic_tee_proxy_exec:s0
/system/bin/mcDriverDaemon      u:object_r:mobicoredaemon_exec:s0
/system/bin/mcDriverDaemonQC    u:object_r:mobicoredaemon_exec:s0
# conflict with Qcom BSP, /system/bin/qseecomd  u:object_r:qseecomd_exec:s0
#SEC use qseecom_device, not tee_device. neverallow Google CTS-android-5.0.2_r1 : 
/dev/qseecom                                    u:object_r:qseecom_device:s0
/system/bin/qseecomd                            u:object_r:tee_exec:s0
/system/vendor/bin/qseeproxydaemon              u:object_r:qseeproxy_exec:s0
/data/misc/qsee(/.*)?                                               u:object_r:data_qsee_file:s0
/data/misc/sshdcpapp(/.*)?                            u:object_r:data_qsee_file:s0
/teesst(/.*)?           u:object_r:teesst_data_file:s0
/data/tee(/.*)?                         u:object_r:tee_data_file:s0
# for tz
/system/bin/teec_sstd_ca        u:object_r:teecsstdca_exec:s0
https://github.com/Minionguyjpro/android_device_samsung_a2corelte/blob/621ec0c09fc091f615f66665162fcc7b49b1ad30/recovery/root/init.rc#L99-L107

With time I answer your messages 1/2/3........

Minionguyjpro commented 3 months ago

I don't think that it's that easy, it's just that this device is a bit apart from some of the other ones. I will however try adding the ext4 thing to the fstab. Should I however add it to the fstab.samsungexynos7870 or one of the others? I don't feel like TWRP sources the fstab.samsungexynos7870 file, but I could be wrong.

EDIT: I feel like the recovery.fstab is the best suited for this.

Minionguyjpro commented 3 months ago

Mounting the USERDATA as F2FS gives permission denied, with EXT4 gives invalid argument.

Minionguyjpro commented 3 months ago

https://github.com/Minionguyjpro/android_device_samsung_a2corelte/blob/621ec0c09fc091f615f66665162fcc7b49b1ad30/recovery/root/prebuilt_file_contexts#L854

Oh also a bit confusing, I copied that prebuilt_file_contexts from another tree (may not have been the smartest but it at least made the recovery boot, I had no idea where else to get it from) so it may contain things that aren't relevant to the tree with the Exynos 7870 SoC here.

Minionguyjpro commented 3 months ago

This small video showing a bit of the main structure may help (I here my microphone was on, OOPS):

https://github.com/user-attachments/assets/fad2c92b-d2f7-4858-bfe7-ac7dfa62feb2

Minionguyjpro commented 3 months ago

Also I have done stuff but under the hood without pushing it yet. I will now so you can see.

EDIT: All right so now the init.recovery.samsungexynos7870.rc file is working. Data is however still returning those mount errors, SD is still not working, USB-OTG is and MTP is not.

EDIT 2: Interesting, I think SELinux is in the way:

[   15.360894]  [5:    logd.auditd: 2421] type=1400 audit(1723564145.109:127): avc: denied { open } for pid=2375 comm="recovery" path="/sys/devices/13540000.dwmmc0/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p26" dev="sysfs" ino=19253 scontext=u:r:recovery:s0 tcontext=u:object_r:sysfs:s0 tclass=dir permissive=1

Although it's on permissive so I'm not sure...

lopestom commented 3 months ago

/vendor/etc/init

gatekeeper@1.0-service.so & keymaster@3.0-service.so files

/system/etc/init (there's more on the top of the directory but it doesn't seem relevant):

hwservicemanager.rc & servicemanager.rc files maybe more....

Need look in the \bin\ folder too.....

lopestom commented 3 months ago

This small video showing a bit of the main structure may help (I here my microphone was on, OOPS):

Your luckly because my sound is muted. in the boot.img and recovery.img not have files to decrypt.... In some Xiaomi and Realme already has.

In the video, the \vendor\ is good but since A8.1 has \system as principal so some files in that and \vendor is the way. If your files in the DT is from stock firmware so as I wrote before so device has trustonic mode. You can confirm in the init.rc file. In the \vendor\tee has files?

so if has any firmware repo in the github or gitlab so link that.....

Minionguyjpro commented 3 months ago

Your luckly because my sound is muted. in the boot.img and recovery.img not have files to decrypt.... In some Xiaomi and Realme already has.

Ah yeah great :joy:.

In the video, the \vendor\ is good but since A8.1 has \system as principal so some files in that and \vendor is the way. If your files in the DT is from stock firmware so as I wrote before so device has trustonic mode. You can confirm in the init.rc file.

I don't seem to find anything about trustonic mode back in any of the init.rc files. I will double check.

In the \vendor\tee has files?

Yes, it does: afbeelding

so if has any firmware repo in the github or gitlab so link that..... https://github.com/Rabikishan001/a2corelte_dump Probably another firmware version but it's pretty much but the same (I checked multiple files, all were identical in both that dump and my local one). Do mind though that some mount directories were kept back there. E.g. in my video you see that there's a data folder, which you won't see in this dump. But that's because it's just an empty folder as placeholder for the mount point. So not important.

Minionguyjpro commented 3 months ago

/vendor/etc/init

gatekeeper@1.0-service.so & keymaster@3.0-service.so files

/system/etc/init (there's more on the top of the directory but it doesn't seem relevant):

hwservicemanager.rc & servicemanager.rc files maybe more....

Need look in the \bin\ folder too.....

Files have been added, will push the changes.

EDIT: Used ldcheck to find out that I had to add ld-android.so in system/lib and vendor.samsung.security.skeymaster@3.0_vendor.so in vendor/lib.

Minionguyjpro commented 3 months ago

Don't know whether it helps but this is what /proc/mounts returns from within the booted system:

rootfs / rootfs ro,seclabel,size=420272k,nr_inodes=105068 0 0
proc /proc proc rw,relatime,gid=3009,hidepid=2 0 0
sysfs /sys sysfs rw,seclabel,relatime 0 0
magisk /sbin tmpfs rw,seclabel,relatime,mode=755 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,seclabel,relatime,mode=600 0 0
selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0
/dev/block/platform/13540000.dwmmc0/by-name/ODM /odm ext4 ro,seclabel,relatime 0 0
/dev/block/platform/13540000.dwmmc0/by-name/SYSTEM /system ext4 ro,seclabel,relatime 0 0
/dev/block/platform/13540000.dwmmc0/by-name/VENDOR /vendor ext4 ro,seclabel,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
none /dev/memcg cgroup rw,relatime,memory 0 0
/sys/kernel/debug /sys/kernel/debug debugfs rw,seclabel,relatime 0 0
tmpfs /mnt tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
none /config configfs rw,relatime 0 0
tmpfs /mnt/secure tmpfs rw,seclabel,relatime,mode=700 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
pstore /sys/fs/pstore pstore rw,seclabel,relatime 0 0
/dev/block/platform/13540000.dwmmc0/by-name/CACHE /cache ext4 rw,seclabel,nosuid,nodev,noatime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,errors=panic,data=ordered 0 0
/dev/block/platform/13540000.dwmmc0/by-name/EFS /efs ext4 rw,seclabel,nosuid,nodev,noatime,journal_checksum,journal_async_commit,noauto_da_alloc 0 0
/dev/block/platform/13540000.dwmmc0/by-name/OMR /omr ext4 rw,seclabel,nosuid,nodev,noatime,journal_checksum,noauto_da_alloc 0 0
tmpfs /storage tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
adb /dev/usb-ffs/adb functionfs rw,relatime 0 0
tracefs /sys/kernel/debug/tracing tracefs rw,seclabel,relatime 0 0
/dev/block/dm-0 /data f2fs rw,lazytime,seclabel,nosuid,nodev,noatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,reserve_root=12800,reserve_core=10240,resuid=0,resgid=5555,usrquota,grpquota,alloc_mode=reuse,fsync_mode=nobarrier 0 0
/data/media /mnt/runtime/default/emulated sdcardfs rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,multiuser,mask=6,derive_gid 0 0
/data/media /storage/emulated sdcardfs rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,multiuser,mask=6,derive_gid 0 0
/data/media /mnt/runtime/read/emulated sdcardfs rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=23,derive_gid 0 0
/data/media /mnt/runtime/write/emulated sdcardfs rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=7,derive_gid 0 0
/dev/block/platform/13540000.dwmmc0/by-name/HIDDEN /preload ext4 ro,seclabel,nosuid,nodev,relatime 0 0
/dev/block/vold/public:179,33 /mnt/media_rw/EC9B-086E sdfat rw,dirsync,nosuid,nodev,noexec,noatime,fs=vfat:32,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,utf8,shortname=winnt,namecase=0,delay,smart,ausize=32768,adj_hid,adj_req,symlink=0,bps=512,errors=remount-ro 0 0
/dev/block/vold/public:179,33 /mnt/secure/asec sdfat rw,dirsync,nosuid,nodev,noexec,noatime,fs=vfat:32,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,utf8,shortname=winnt,namecase=0,delay,smart,ausize=32768,adj_hid,adj_req,symlink=0,bps=512,errors=remount-ro 0 0
/mnt/media_rw/EC9B-086E /mnt/runtime/default/EC9B-086E sdcardfs rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,mask=6 0 0
/mnt/media_rw/EC9B-086E /storage/EC9B-086E sdcardfs rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,mask=6 0 0
/mnt/media_rw/EC9B-086E /mnt/runtime/read/EC9B-086E sdcardfs rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,mask=18 0 0
/mnt/media_rw/EC9B-086E /mnt/runtime/write/EC9B-086E sdcardfs rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,mask=18 0 0

Maybe it helps troubleshoot some of the mount issues. I just reinstalled the stock system (did a try to install an arm 32 bit with 64 bit binder GSI but failed, keeps booting into download mode without any messages). So I can better test the decryption, but last attempt failed.

lopestom commented 3 months ago

I don't seem to find anything about trustonic mode back in any of the init.rc files.

https://github.com/Minionguyjpro/android_device_samsung_a2corelte/blob/twrp-9.0/recovery/root/init.recovery.samsungexynos7870.rc#L98-L102

admore so \vendor \tee\ has tz file.....

Minionguyjpro commented 3 months ago

I don't seem to find anything about trustonic mode back in any of the init.rc files.

https://github.com/Minionguyjpro/android_device_samsung_a2corelte/blob/twrp-9.0/recovery/root/init.recovery.samsungexynos7870.rc#L98-L102

admore so \vendor \tee\ has tz file.....

The .tzar file? I think I should add just the whole tee directory.

Also, mcRegistry is in vendor/app. Add or not? It contains the file to which the Mobicore part in the init file is referencing to.

lopestom commented 3 months ago

I don't seem to find anything about trustonic mode back in any of the init.rc files.

https://github.com/Minionguyjpro/android_device_samsung_a2corelte/blob/twrp-9.0/recovery/root/init.recovery.samsungexynos7870.rc#L98-L102 admore so \vendor \tee\ has tz file.....

The .tzar file? I think I should add just the whole tee directory.

no. copy folder&files to DT \vendor Obvius create a new DT.........

Also, mcRegistry is in vendor/app. Add or not? It contains the file to which the Mobicore part in the init file is referencing to.

yes! that and other files too......

Need look in the \bin\ folder too.....

https://github.com/Minionguyjpro/android_device_samsung_a2corelte/blob/twrp-9.0/recovery/root/init.recovery.samsungexynos7870.rc#L104-L107

Minionguyjpro commented 3 months ago

I don't seem to find anything about trustonic mode back in any of the init.rc files.

https://github.com/Minionguyjpro/android_device_samsung_a2corelte/blob/twrp-9.0/recovery/root/init.recovery.samsungexynos7870.rc#L98-L102 admore so \vendor \tee\ has tz file.....

The .tzar file? I think I should add just the whole tee directory.

no. copy folder&files to DT \vendor Obvius create a new DT.........

Also, mcRegistry is in vendor/app. Add or not? It contains the file to which the Mobicore part in the init file is referencing to.

yes! that and other files too......

Need look in the \bin\ folder too.....

https://github.com/Minionguyjpro/android_device_samsung_a2corelte/blob/twrp-9.0/recovery/root/init.recovery.samsungexynos7870.rc#L104-L107

That file where the Qualcomm case is referring to doesn't exist however. The other one does.

lopestom commented 3 months ago

That file where the Qualcomm case is referring to doesn't exist however. The other one does.

so no copy..... Lmao

You can have similar reference here 3.2 Trustkernel

Minionguyjpro commented 3 months ago

mcDriverDaemon_static also nowhere in sbin or anywhere in the dump...

Minionguyjpro commented 3 months ago

It's not Trustkernel is it? It has some comparable files but not all of them (I guess that's why you say similar).

lopestom commented 3 months ago

It's not Trustkernel is it? It has some comparable files but not all of them (I guess that's why you say similar).

Similar case.... only to have reference files.......

mcDriverDaemon_static also nowhere in sbin or anywhere in the dump...

https://github.com/Rabikishan001/a2corelte_dump/blob/main/vendor/bin/tzdaemon

Look https://github.com/search?q=repo%3ARabikishan001%2Fa2corelte_dump%20mcdriver&type=code

Minionguyjpro commented 3 months ago

Added some more changes.

Minionguyjpro commented 3 months ago

Eyyy, seems like adding that event-log-tags file fixed nano and logcat!

Minionguyjpro commented 3 months ago

I still have no idea what to do about that unable to load crc32 driver error (it's the data partition by the way, dmesg spams this): [ 11.850451] [4: recovery: 2379] F2FS-fs (mmcblk0p26): Cannot load crc32 driver.

EDIT: I can add a patch to a file in the kernel which preloads some of the things, related to crypto and crc32. Will test.

lopestom commented 3 months ago

Now is the time to read and learn a little more about decryption.

Don't go too fast, because the pain will be greater in disappointments.

Let's take a moment and look at the files, references and something in script files like rc or xml so we can get our bearings. https://github.com/Rabikishan001/a2corelte_dump/blob/fe01b6c7f321e48d22fbee30027db0ed1be5e406/recovery/ramdisk/res/recovery.do#L428-L429

https://github.com/Rabikishan001/a2corelte_dump/blob/fe01b6c7f321e48d22fbee30027db0ed1be5e406/system/bin/proxy_daemon

https://github.com/Rabikishan001/a2corelte_dump/blob/fe01b6c7f321e48d22fbee30027db0ed1be5e406/system/bin/tzdatacheck

Add keystore files to DT https://github.com/Rabikishan001/a2corelte_dump/tree/fe01b6c7f321e48d22fbee30027db0ed1be5e406/system/lib/hw

also https://github.com/Rabikishan001/a2corelte_dump/blob/fe01b6c7f321e48d22fbee30027db0ed1be5e406/system/lib/libgatekeeper.so

vendor.samsung.security.skeymaster@3.0.so

https://github.com/Rabikishan001/a2corelte_dump/tree/fe01b6c7f321e48d22fbee30027db0ed1be5e406/system/tee

Also, I don't know if the TeamWin twrp-9.0 repo is good for decryption. Everything will be tests and confirmations.

lopestom commented 3 months ago

Compile img file with CRYPTO enable. After unpack that img file and look if has libicui18n.so

this is good?? libsec_ode_integirty.so libsec_ode_keymanager.so libsec_ode_keymaster.so libsec_ode_keystorage.so libsec_ode_keystorage_fbe.so libsec_ode_keystorage_fde.so libsec_ode_pbkdf.so libsec_ode_sdcardencryption.so libskeymaster.so

That's a samsung keymater? for secure (sec) mode?

SD is still not working, USB-OTG is and MTP is not.

maybe libmtp.so libmtp_samsung.so libmtp_samsung_jni.so

Minionguyjpro commented 3 months ago

Compile img file with CRYPTO enable. After unpack that img file and look if has libicui18n.so

this is good?? libsec_ode_integirty.so libsec_ode_keymanager.so libsec_ode_keymaster.so libsec_ode_keystorage.so libsec_ode_keystorage_fbe.so libsec_ode_keystorage_fde.so libsec_ode_pbkdf.so libsec_ode_sdcardencryption.so libskeymaster.so

That's a samsung keymater? for secure (sec) mode?

SD is still not working, USB-OTG is and MTP is not.

maybe libmtp.so libmtp_samsung.so libmtp_samsung_jni.so

It doesn't have a libicui18n.so. Am I supposed to add all of the things you listed here?

Yup, my dump also contains those libraries.

Am also not sure why an FBE library file is included, the device has Secure Startup and supports SD-card encryption (optional but my current SD card isn't) AND it's Android 8.1 so it's supposed to use FDE.

For MTP, there is usb_mtp_gadget in /dev. My phone shows up on my computer but mounting it however is not working... Maybe because data nor the SD card mounting and thus there's nothing to list which causes this? Or should it mount then but just show Internal and SD as 0MB without any files?

lopestom commented 3 months ago

It doesn't have a libicui18n.so

Need add in the omni_ with

# Additional Libraries
TARGET_RECOVERY_DEVICE_MODULES += libicui18n

RECOVERY_LIBRARY_SOURCE_FILES += $(TARGET_OUT_SHARED_LIBRARIES)/libicui18n.so

add in \vendor android.hardware.gatekeeper@1.0-impl.so android.hardware.keymaster@3.0-impl.so gatekeeper.exynos7870.so keystore.mdfpp.so vendor.samsung.security.skeymaster@3.0-impl.so libMcClient.so

libion_exynos.so libkeymaster2_mdfpp.so libkeymaster_helper.so libteecl.so vendor.samsung.security.skeymaster@3.0_vendor.so

maybe others so files?!

Read/Searh and look about, not know about prepare_param.sh

Minionguyjpro commented 3 months ago

It doesn't have a libicui18n.so

Need add in the omni_ with

# Additional Libraries
TARGET_RECOVERY_DEVICE_MODULES += libicui18n

RECOVERY_LIBRARY_SOURCE_FILES += $(TARGET_OUT_SHARED_LIBRARIES)/libicui18n.so

add in \vendor android.hardware.gatekeeper@1.0-impl.so android.hardware.keymaster@3.0-impl.so gatekeeper.exynos7870.so keystore.mdfpp.so vendor.samsung.security.skeymaster@3.0-impl.so libMcClient.so

libion_exynos.so libkeymaster2_mdfpp.so libkeymaster_helper.so libteecl.so vendor.samsung.security.skeymaster@3.0_vendor.so

maybe others so files?!

Read/Searh and look about, not know about prepare_param.sh

Added all of those files (will push). The param partition is a completely different thing, it contains images for the boot process like the Samsung boot logo, bootloader warning etc.

EDIT: PUSHED!

lopestom commented 3 months ago

Am also not sure why an FBE library file is included, the device has Secure Startup and supports SD-card encryption (optional but my current SD card isn't) AND it's Android 8.1 so it's supposed to use FDE.

Android Souce Code Security say put FDE but with future support to FBE after A8 so your device has A8.1.........

For MTP, there is usb_mtp_gadget in /dev. My phone shows up on my computer but mounting it however is not working... Maybe because data nor the SD card mounting and thus there's nothing to list which causes this? Or should it mount then but just show Internal and SD as 0MB without any files?

Your PC already has MTP drivers installed? Always changed manually to confirm that's working? So maybe need looking usb.rc file in DT??

Minionguyjpro commented 3 months ago

Am also not sure why an FBE library file is included, the device has Secure Startup and supports SD-card encryption (optional but my current SD card isn't) AND it's Android 8.1 so it's supposed to use FDE.

Android Souce Code Security say put FDE but with future support to FBE after A8 so your device has A8.1.........

For MTP, there is usb_mtp_gadget in /dev. My phone shows up on my computer but mounting it however is not working... Maybe because data nor the SD card mounting and thus there's nothing to list which causes this? Or should it mount then but just show Internal and SD as 0MB without any files?

Your PC already has MTP drivers installed? Always changed manually to confirm that's working? So maybe need looking usb.rc file in DT??

Oh well I'm using Xubuntu right now, so Linux and not Windows. But yes it works when booted into the system. I think indeed looking into the USB rc file is a good idea.

lopestom commented 3 months ago

EDIT: PUSHED!

from your firmware obviusly?!

Next step is creating a script file to start and execute the binary files..... Example with android.hardware.keymaster@3.0-service.rc

service keymaster-3-0 /vendor/bin/hw/android.hardware.keymaster@3.0-service
    class early_hal
    user root
    group root drmrpc
    disabled
    seclabel u:r:recovery:s0

on post-fs-data
    mkdir /efs/DAK 0775 root root
    restorecon -R /efs/DAK

android.hardware.gatekeeper@1.0-service.rc

service gatekeeper-1-0 /vendor/bin/hw/android.hardware.gatekeeper@1.0-service
    class hal
    user root
    group root
    disabled
    seclabel u:r:recovery:s0

and others..... But now I haven't time to do more.

Minionguyjpro commented 3 months ago

EDIT: PUSHED!

from your firmware obviusly?!

Next step is creating a script file to start and execute the binary files..... Example with android.hardware.keymaster@3.0-service.rc

service keymaster-3-0 /vendor/bin/hw/android.hardware.keymaster@3.0-service
    class early_hal
    user root
    group root drmrpc
    seclabel u:r:recovery:s0

on post-fs-data
    mkdir /efs/DAK 0775 root root
    restorecon -R /efs/DAK

android.hardware.gatekeeper@1.0-service.rc

service gatekeeper-1-0 /vendor/bin/hw/android.hardware.gatekeeper@1.0-service
    class hal
    user root
    group root
    disabled
    seclabel u:r:recovery:s0

and others..... But now I haven't time to do more.

I added those already.

lopestom commented 3 months ago

I added those already.

Now you can understand this?

https://github.com/TeamWin/android_device_qcom_twrp-common/blob/android-11/crypto/init.recovery.qcom_decrypt.rc

Minionguyjpro commented 3 months ago

I added those already.

Now you can understand this?

https://github.com/TeamWin/android_device_qcom_twrp-common/blob/android-11/crypto/init.recovery.qcom_decrypt.rc

I think so.

Minionguyjpro commented 3 months ago

I will probably compile the kernel with the patch tomorrow.

Minionguyjpro commented 3 months ago

I think I will have to add a seclabel to the init file(s) so SELinux will allow the services to start:

[  809.956768]  [0:           init:    1] init: Could not ctl.start for service keymaster-3-0: File /vendor/bin/hw/android.hardware.keymaster@3.0-service(labeled "u:object_r:rootfs:s0") has incorrect label or no domain transition from u:r:init:s0 to another SELinux domain defined. Have you configured your service correctly? https://source.android.com/security/selinux/device-policy#label_new_services_and_address_denials
Minionguyjpro commented 3 months ago

New kernel image has been built, time to test!

Minionguyjpro commented 3 months ago

I also have the following in the keymaster init file:

on post-fs-data
    mkdir /efs/DAK 0775 system system
    restorecon -R /efs/DAK

How's this relevant? My device has an EFS partition, but hmm...

Minionguyjpro commented 3 months ago

Patched kernel with change is still not working, hmm...

Minionguyjpro commented 3 months ago

Is it me or should vold be used here?

service vold /system/bin/vold \
        --blkid_context=u:r:blkid:s0 --blkid_untrusted_context=u:r:blkid_untrusted:s0 \
        --fsck_context=u:r:fsck:s0 --fsck_untrusted_context=u:r:fsck_untrusted:s0
    class core
    socket vold stream 0660 root mount
    socket cryptd stream 0660 root mount
    ioprio be 2
## Frigatebird
    socket frigate stream 0660 system system
    writepid /dev/cpuset/foreground/tasks
    shutdown critical    
## Samsung ODE >>>
    socket dir_enc_report stream 0660 root mount
## Samsung ODE <<<
Minionguyjpro commented 3 months ago

Ah now comes the next problem! The system partition is 32 bit and the SoC is 64 bit (I compiled TWRP for 64 bit). Now some binaries like vold and mtpd freak out (and so does the recovery when running them) because they need a library that's 32 bit, but one of 64 bit was found. Can I maybe overwrite binaries like vold and mtpd with 64 bit versions? I have the dump of another ROM that also contained the vold binary, and it's 64 bit so...

Minionguyjpro commented 3 months ago

Time to enable some debug configs in the kernel for MMC, I'm done. I just want to find this cause.

lopestom commented 3 months ago

I also have the following in the keymaster init file:

on post-fs-data
    mkdir /efs/DAK 0775 system system
    restorecon -R /efs/DAK

How's this relevant? My device has an EFS partition, but hmm...

I not know because i only put reference by file from your link firmare dumped.

Search in your firmware and analize. You know about EFS so maybe can knew about DAK..............

lopestom commented 3 months ago

Is it me or should vold be used here?

service vold /system/bin/vold \
        --blkid_context=u:r:blkid:s0 --blkid_untrusted_context=u:r:blkid_untrusted:s0 \
        --fsck_context=u:r:fsck:s0 --fsck_untrusted_context=u:r:fsck_untrusted:s0
    class core
    socket vold stream 0660 root mount
    socket cryptd stream 0660 root mount
    ioprio be 2
## Frigatebird
    socket frigate stream 0660 system system
    writepid /dev/cpuset/foreground/tasks
    shutdown critical    
## Samsung ODE >>>
    socket dir_enc_report stream 0660 root mount
## Samsung ODE <<<

Look TWRP source code and you find vold.rc integrate?!

Ah now comes the next problem! The system partition is 32 bit and the SoC is 64 bit (I compiled TWRP for 64 bit). Now some binaries like vold and mtpd freak out (and so does the recovery when running them) because they need a library that's 32 bit, but one of 64 bit was found. Can I maybe overwrite binaries like vold and mtpd with 64 bit versions? I have the dump of another ROM that also contained the vold binary, and it's 64 bit so...

Some devices arm32-binder64-ab or a64 has TWRP with decryption working, How TWRP was compiled is the question? For me the way is putting informations and files correctly. After can compile 64 or 32 to tests......

Minionguyjpro commented 3 months ago

Is it me or should vold be used here?

service vold /system/bin/vold \
        --blkid_context=u:r:blkid:s0 --blkid_untrusted_context=u:r:blkid_untrusted:s0 \
        --fsck_context=u:r:fsck:s0 --fsck_untrusted_context=u:r:fsck_untrusted:s0
    class core
    socket vold stream 0660 root mount
    socket cryptd stream 0660 root mount
    ioprio be 2
## Frigatebird
    socket frigate stream 0660 system system
    writepid /dev/cpuset/foreground/tasks
    shutdown critical    
## Samsung ODE >>>
    socket dir_enc_report stream 0660 root mount
## Samsung ODE <<<

Look TWRP source code and you find vold.rc integrate?!

Ah now comes the next problem! The system partition is 32 bit and the SoC is 64 bit (I compiled TWRP for 64 bit). Now some binaries like vold and mtpd freak out (and so does the recovery when running them) because they need a library that's 32 bit, but one of 64 bit was found. Can I maybe overwrite binaries like vold and mtpd with 64 bit versions? I have the dump of another ROM that also contained the vold binary, and it's 64 bit so...

Some devices arm32-binder64-ab or a64 has TWRP with decryption working, How TWRP was compiled is the question? For me the way is putting informations and files correctly. After can compile 64 or 32 to tests......

I compiled TWRP targeting 64 bit, so ARMv8. The OS (so the ROM, Samsung Experience) however is 32 bit, running the SoC in ARM-V7a or like armeabi-v7a using the 32 bit mode integrated into the kernel. The vendor partition also only seems to contain 32 bit libraries.

lopestom commented 3 months ago

I compiled TWRP targeting 64 bit, so ARMv8. The OS (so the ROM, Samsung Experience) however is 32 bit, running the SoC in ARM-V7a or like armeabi-v7a using the 32 bit mode integrated into the kernel. The vendor partition also only seems to contain 32 bit libraries.

Are you writing a report for other people to read?

If not, remember who started helping you with DT and saw the firmware images containing only \vendor\lib ?!

I didn't understand why you wrote that.....

Minionguyjpro commented 3 months ago

You say how TWRP was compiled is the question?, which is confusing me. I already thought like I'd said that just before it. (But next time I won't give any info that's already there, then it's up to the reader to just look well to find out). Anyways, what to try next?

lopestom commented 3 months ago

You say how TWRP was compiled is the question?, which is confusing me.

Me too because Exynos is not my expertise so if you search DT to that so you look arm(32) & arm(64) and arm32-binder64-ab or a64 with TWRP so u can look encrypt/decrypt working good and others not. All doubts about kernel should be tested by u.

For me, it's indifferent but I undertand if some process not working with 32 but working with 64. All depend by device and what the company make settings/process/executables for encrypt/decrypt work.

You say how TWRP was compiled is the question?,

Therefore only you can answer the doubts about kernel.

About this

Look TWRP source code and you find vold.rc integrate?!

All is clean and directlly.

Upd: here's to android-9.0 https://github.com/search?q=repo%3ATeamWin%2Fandroid_bootable_recovery%20vold&type=code

Minionguyjpro commented 3 months ago

You say how TWRP was compiled is the question?, which is confusing me.

Me too because Exynos is not my expertise so if you search DT to that so you look arm(32) & arm(64) and arm32-binder64-ab or a64 with TWRP so u can look encrypt/decrypt working good and others not. All doubts about kernel should be tested by u.

For me, it's indifferent but I undertand if some process not working with 32 but working with 64. All depend by device and what the company make settings/process/executables for encrypt/decrypt work.

You say how TWRP was compiled is the question?,

Therefore only you can answer the doubts about kernel.

About this

Look TWRP source code and you find vold.rc integrate?!

All is clean and directlly.

Upd: here's to android-9.0 https://github.com/search?q=repo%3ATeamWin%2Fandroid_bootable_recovery%20vold&type=code

It would work with arm32, but I found using aarch64 just the best option, so that if someone manages to patch the vendor it can integrate well with 32 bit and 64 bit at the end. I see vold is available there, but I also saw a reference in the regular init file that was looking to import /init.recovery.vold_decrypt.rc, which was missing. I made this file in my local environment (not sure whether I pushed this change yet) With details to start the vold service. Best bet is to set the option to include the SBIN vold with crypto (which is probably 64 bit) and change the reference in the RC file to the one in /sbin.

Minionguyjpro commented 3 months ago

I feel like this device isn't that different from other Exynos 7870 devices. It's just that this device seems to need some patches in the kernel to let it boot (there was a hardcoded max. ramdisk length in this device. I am pretty sure since I had a recovery image that could fit on the device with the correct offset flags and everything but it said invalid ramdisk length. Compressing it with LZMA and enabling the config for it in the kernel made it boot. It still boots actually pretty quickly so I'm happy). And e.g. the Synaptics driver containing an if statement which prevented it from loading in the recovery. Fortunately both of these issues are fixed, but I'm pretty sure that the external SD card does NOT depend on the data partition. It uses a seperate driver for the host controller (pretty much any device does).

I have read about a kernel patch that could allow MMC to work when using device trees or ACPI. Maybe it's worth trying this and see?

EDIT: Okay I managed to patch a few C files of the dw_mmc host controller driver. Will push changes now and check later on.

EDIT 2: okay I failed and reverted the changes. I don't expect it to be the cause since I see other trees with the same code for the driver and those don't seem to have any issues with it.