search

ADeadTrousers / twrp_device_Unihertz_Atom_LXL

Common device tree for the Unihertz Atom L and XL
Apache License 2.0
7 stars 3 forks source link

Decryption is not (completely) working #3

Closed ADeadTrousers closed 3 years ago

ADeadTrousers commented 3 years ago

After booting into the recovery and browsing the filesystem, everything looks a little bit "garbled". Especially the /sdcard doesn't seem to be alright. Here you can only see folders with "GUID"-like names and no contents. Also there are two drives with zero bytes able to select when trying to change between external and internal memory. My guess is, that the fstab is either not compatible or flat out wrong. Maybe a switch to that ominous fstab v2 format could fix it, but I need to do some more research.

ADeadTrousers commented 3 years ago

https://github.com/ADeadTrousers/twrp_device_Unihertz_Atom_XL/commit/78cb78abda554bbbe44a95b6330865f11921d9f6

ADeadTrousers commented 3 years ago

Still no luck in getting decryption to work.

ADeadTrousers commented 3 years ago

According to https://github.com/PeterCxy/android_device_umidigi_F1/tree/twrp-9.0 and https://github.com/Vgdn1942/android_device_blackview_bv9500plus one would need a keystore*.so file but I couldn't find any in the stock rom. Latest try prevents a successful boot so as a workaround I deactivated /data completely. Can't factory reset now though.

ADeadTrousers commented 3 years ago

The trustkernel daemon (teed) seems to be operational now: 6a79d27a39a9dabb12995af7c24666a36b2e44d1 I'm more and more convinced that the Atom L/XL uses FBE instead of FDE and according to some sources on the net TWRP only supports FDE.

ADeadTrousers commented 3 years ago

Ok, I need to revoke my previous comment: There is a FBE switch in TWRP e590bd635c0cb3bc2368b05f215370fae3a55aea It's just not working though.

ADeadTrousers commented 3 years ago

By logging through the code I came to the function "decryptWithKeymasterKey" in "KeyStorage.cpp" which fails. So it seems that the problem lies with correctly registering keymaster service. I'm looking at you manifest.xml and compatibility_matrix.xml. Including them at the correct patch ".../etc/vintf" lets TWRP freeze on boot. So something must be going on there. Need more intel.

ADeadTrousers commented 3 years ago

ErrorCode in Keymaster.cpp in function Keymaster::begin at mDevice->begin is -33. According to hardware/interfaces/keymaster/4.0/types.hal this means ErrorCode::INVALID_KEY_BLOB Could it be that a 'wrong' keymaster instance is being used?

ADeadTrousers commented 3 years ago

Maybe a little bit more elaboration: According to KeyStorage.cpp the keyfile is stored in /data/unencrypted/key/keymaster_key_blob. A little bit of research brought me to https://forum.xda-developers.com/t/rom-official-nightly-lineageos-16-0-for-oneplus-3-3t.3866517/post-80122746 The member who analyzed it did quite some research. It's a good read. Also his subsequent findings. So there seems to be a problem with the formatting of the key blob. But I don't know why. I'm using the stock files from vendor and that are the only things common to the LineageOS Rom and that is working perfectly fine.

ADeadTrousers commented 3 years ago

Finally! Decryption is working now. One needs to set PLATFORM_SECURITY_PATCH Now the ErrorCode::KEY_REQUIRES_UPGRADE is thrown. I believe that's because the key blob is created with a lower timestamp than 2099-12-31. Anyway now TWRP logs that it was able to decrypt /data. Checking with File Manager or adb shell confirms that. BUT Everything in the user scope /data/media/0 is still encrypted. According to the logs the file /data/system/gatekeeper.pattern.key is missing. Only that this file doesn't even exists when the system boots and that encrypts just fine. So my guess is that it is either named differently, located somewhere else or another authentication method than gatekeeper is used by LineageOS.

Searching inside /data I couldn't find anything. Even mounting the various other partitions of the phone I didn't get lucky. Tampering with the services didn't help either.

So I guess it's back to doing more research.

ADeadTrousers commented 3 years ago

I'm pretty sure now that LOS (Stock Android 10?) is using the synthetic password method. According to Decrypt.cpp all information is stored in /data/system_de/<userid>. Checking this folder from LOS I can see various key and pwd files but navigating to it from TWRP it's still garbled (= encrypted). As I now already have a decrypted /data/system there needs to be another step in decryption that is still missing for /data/system_de.

ADeadTrousers commented 3 years ago

Found it: 1) PLATFORM_SECURITY_PATCH needs to be the same as the value of ro.build.version.security_patch of the system rom to prevent ErrorCode::KEY_REQUIRES_UPGRADE. This seems to be a "bug" inside keymaster. see https://github.com/sonyxperiadev/bug_tracker/issues/165#issuecomment-431581983

2) function fscrypt_init_user0 fails with return -1 which is not recognized as an error to trigger the appropriate error message in the log. The reason is ReadDefaultFstab fails. So we need to provide a real recovery.fstab and not just the twrp.fstab.

ADeadTrousers commented 3 years ago

76ecfab6baef54647872a46ab82bc4e563cf4ddb Although my pattern is not recognized at least /data/system_de/<userid> gets decrypted now so I think I'm on the right track.

ADeadTrousers commented 3 years ago

Without a pattern or a password everything gets decrypted as expected. So there is still something missing (like a "salt") for the correct generation of the encryption key.

ADeadTrousers commented 3 years ago

Next hurdle: The log tells gatekeeper verification failed. The gatekeeper service respose code is -1 (ERROR_GENERAL_FAILURE). So quite obvious the gatekeeper service is not set up correctly.

ADeadTrousers commented 3 years ago

According to dmesg gatekeeper & teed are running into an error: <7>ERR GATEKEEPER:GetRTCBaseline:127: Warning: No RTC baseline found or it's corrupted, rebuilding <1>ERR GATEKEEPER:__TEE_Panic:42: filename lib/libutee/tee_api_objects.c func_name TEE_CreatePersistentObject lineno 495 code 0xffff0000 <1>ERR GATEKEEPER:unwind_exec_insn:266: unwind: Unhandled instruction c9 <1>ERR TKCore:tee_svc_sys_return_helper:294: TA panicked with code 0xffff0000 usr_sp 0x101e44 usr_lr 0x205488 <1>ERR TKCore:tee_user_ta_enter:1407: TA panicked with code 0xffff0000 <1>DBG TKCore:tee_ta_invoke_command:2201: => Error: ffff3024 of 3 <4>DBG TKCore:elf_load_body:450: Set TLS offset for TA: 0x20e0bc <4>DBG TKCore:tee_ta_load:1172: Loaded TA at 0xf039b000 <4>DBG TKCore:tee_ta_load:1173: ELF load address 0x200000 <4>DBG TKCore:tee_ta_init_session_with_signed_ta:1884: dyn TA : 02662e8e-e126-11e5-b8-6d-9a-79-f0-6e-94-78 <1>DBG TKCore:tee_ta_open_session:1990: [TA 02662e8e: 0] init session

But what's that RTC that is missing? Real Time Clock? Relay Text Client? Searching won't help. :-1:

ADeadTrousers commented 3 years ago

I found tee_api_objects.c: https://github.com/OP-TEE/optee_os/blob/master/lib/libutee/tee_api_objects.c According to that the code 0xffff0000 means TEE_ERROR_GENERIC

ADeadTrousers commented 3 years ago

The text Warning: No RTC baseline found or it's corrupted, rebuilding can be found inside app/t6.

ADeadTrousers commented 3 years ago

Now I feel really dump: d8f963785548c4df5df1eee391d20ec1b9e57937 It seems that I completely missed out on the fact that init.vendor.trustkernel.rc wasn't copied over to the final image. Somehow along the way it was left out. Only during the work on removing the vendor blobs and once more checking if all needed files were found and copied I realized that this integral part of trustkernel was missing.