Decryption (still) isn't working #6
Comments
ADeadTrousers
added
bug
|
I also tried to copy the Changing the |
|
Hi AD; looking for anything about: or read the |
|
hi. Yes I'm on A11 (matter of factly). |
|
|
I have 2+ devices with A9 &A10........ 3 devices with A11 and one have same trustkerne that you have..... I read about some case that need put something for \data can "working" or "read" before/after mount points. So because that maybe need put Looking for |
|
I think your file layout is a little bit odd. |
ADeadTrousers
changed the title
|
The logs I mentioned in the first post also happen under LOS and the decryption works fine there. The black screen rebooting felt the same as under LOS while debugging an error in the rules. The phone simply reboots or boots into the bootloader. So I thought maybe setting selinux to permissive would at least let me boot with decryption enabled. But this seems to be impossible. When setting the kernel command line to |
|
So either unihertz or mediatek "disabled" the switching of the selinux mode in the kernel (for their trustkernel environment?) OR this is a new "security" feature of android all along. |
|
I was able to patch up the kernel so that selinux is running in "permissive" mode. So I decided to start from scratch and remove all vendor files. Now the kernel is booting with crypto enabled??? WTF??? |
|
Placing |
|
Even renaming the file to something completely different didn't help either, |
ADeadTrousers
changed the title
|
Aaarghh... This took me way too long to figure out than I'm comfortable to admit. So now I can REALLY start to work on the decryption. Although The error code Oh, and I neither know why the recovery is querying for |
|
Leaving out the CMD_UPGRADE_KEY by using the same Taken from a particular source file which matches the mentioned line numbers from the log I got these command ids: #define CMD_GENERATE_KEY 13
#define CMD_GET_KEY_CHARACTER_SIZE 14
#define CMD_GET_KEY_CHARACTER 15
#define CMD_BEGIN 16
#define CMD_UPDATE 17
#define CMD_FINISH 18
#define CMD_IMPORT_KEY 19
#define CMD_EXPORT_KEY 20
#define CMD_DELETE_KEY 21
#define CMD_DELETE_ALL_KEY 22
#define CMD_ABORT 23
#define CMD_ATTEST_KEY 24
#define CMD_CONFIGURE 25
#define CMD_UPGRADE_KEY 26
#define CMD_GET_HMAC_SHARING_PARAM 27
#define CMD_COMPUTE_SHARED_HMAC 28
#define CMD_VERIFY_AUTHORIZATION 29So the second call of CMD_UPDATE returns with an empty result ("Update output 0B") |
|
If I'm not mistaken in |
|
I've also checked all the involved binaries for properties that are being read: keymaster: Comparing the values between twrp and system they are identical so this also cannot be the problem. |
|
EDIT: |
If you enable on property:hwservicemanager.ready=true on property:ro.crypto.state=unsupported on property:ro.crypto.state=unencrypted on property:twrp.decrypt.done=true Anything different happen? in your fstab: aes-256-cts:v1 is better write TW_USE_FSCRYPT_POLICY := 1??
|
|
Trust me I've tried both versions for In that same matter |
|
As expected
Comparing my logs from twrp with those from los the keys retrieved for |
Matthias Leitl If yes so Maybe not need because TeamWin placed in the \init the keystore2.rc |
|
There is neither a |
I was just thinking about your message about keymaster3.0...... so is the first attempt to use 3.0 for the FDE and then use 4.0 for the FBE? So if the first attempt fails will the full encryption/decryption fail? Click to openFrom bdcdb237bf88de33687be58ecf6e173399b33acc Mon Sep 17 00:00:00 2001 From: anonymous Date: Sat, 9 Nov 2019 19:55:54 -0600 Subject: [PATCH 06/15] Save and restore crypto footer for vold decrypt that's on a separate partition Change-Id: Id380f4fc5d4dea5fdae699eb63b3b1737dc0d503crypto/vold_decrypt/vold_decrypt.cpp | 52 ++++++++++++++++++---------- diff --git a/crypto/vold_decrypt/vold_decrypt.cpp b/crypto/vold_decrypt/vold_decrypt.cpp #define CRYPT_FOOTER_OFFSET 0x4000 int footer_br(const string& command) {
@@ -826,12 +840,12 @@ int footer_br(const string& command) {
-- Click to openFrom 6d45eb8b93a719f1e5eb6deb2b1a52518a267bcd Mon Sep 17 00:00:00 2001 From: anonymous Date: Sat, 9 Nov 2019 19:59:22 -0600 Subject: [PATCH 07/15] Do not use native FDE decrypt & libs if SYSTEM_VOLD is defined. Change-Id: I460663ba3bf8a40f051ed5cebfed503fe2f8cd07Android.mk | 24 ++++++++++++------------ diff --git a/Android.mk b/Android.mk
+ifeq ($(TW_CRYPTO_USE_SYSTEM_VOLD),)
include $(CLEAR_VARS) LOCAL_MODULE := libcryptfsfde -ifeq (
-ifeq (
+#ifndef TW_CRYPTO_USE_SYSTEM_VOLD -#ifdef TW_CRYPTO_USE_SYSTEM_VOLD
|
|
I've already tried to use vold but wasn't able to get it to compile (some header files cannot be found and so on) so I assume it wasn't planned/tested to be useable for twrp-11. AFAIK starting from twrp-11 when they switched from omni to aosp they included all of vold's functionality into the recovery. For the both changes/patches can you get me the urls (github, gerrit, ...)? The code here in text format is a little bit hard for me to read and understand. |
ext4crypt: change to upgrade key if export fails https://gerrit.omnirom.org/c/android_bootable_recovery/+/21050/ https://gerrit.omnirom.org/c/android_bootable_recovery/+/32481 I forgot about the speciallist....... Maybe @bkerler can help........ |
|
FDE isn't part of twrp-11 anymore. Same for EXT4CRYPT. |
|
Forgot mention about Ah! Other question is about this: That's running correctly? I finded this in other DT: https://github.com/LuciferMorningStar733/device_xiaomi_pissarro/blob/c06022b798b3346eaf61ad14bf1eef8e47bdbce3/recovery/root/microtrust.rc#L233 |
|
I don't know if this file is in your ROM in \system\system\bin\gatekeeperd but I've seen it in many ROMs on Android 11. I wondered why it exists and what it's for. Maybe it's good to leave this as a good read, since in Android 14 we will again have another form of encryption. https://source.android.com/docs/security/features/authentication/gatekeeper#architecture https://source.android.com/docs/security/features/encryption/file-based#encryption-policy https://source.android.com/docs/security/features/encryption/metadata#prerequisites I have a question in your fstab. For what reason your put in the twrp.fstab so you not put this like your stock recovery.fstab?? |
|
Hi.
|
|
Hi @lopestom |
https://github.com/lopestom/android_hardware_mediatek/wiki/analisys-rpmb |
|
I think I'm on the right way now. It's still not letting me decrypt my storage though. According to Next it's preparing the But now it's not able to read the password file any more as it's attempting to fallback on According to the source code in My best guess would be an unmount or something similar between the the first successful read an the pattern read. |
Why did you not include |
Because they are part of the stock rom, don't need to be changed at all and therefore copied directly from the stock rom/the device: |
|
The fstab I use for recovery is the same I use for system. Therefore I don't think I should have it differ too much as these settings are crucial for the first time initialization and also for every decryption attempt afterwards.
TWRP for Android 11 and up does not include |
|
Something in To make sure that no "switch" to a different part of the recovery (e.g. to the decrypt_screen) is interfering with the overall decryption I identified this function to be solely responsible for the overall process (at least for default password) by dissecting the The first few lines are from calling So that means between the first two attempts to read the password type where it was able to read the system encrypted info ( |
|
Eureka! |
|
It looks like the guys at TeamWin already fixed that ... in |
|
With this patch I'm now able to at least decrypt /data if no password or pattern is set. Trying to decrypt with a password or pattern results in an endless loop. So there is still some tweaking need, but that's for another day. |
|
I just had to revert some changes I did in init.recovery.trustkernel.rc and now also the decryption of a pattern or password encrypted user works as it should. |
|
Hi @ADeadTrousers, flags in here You can use the script for removing stock recovery if you want. That already work for other device. I not remember if device need in RW. Test and let me know. You can add too if decrypt not work: # Crypto
TW_FORCE_KEYMASTER_VER := truesystem.prop |
|
The |
|
|
Doubts: 4- Generally trustkernel mode has large files compared to microtrust and trustonic. So this is also something that gets in the way. If we could know whether this or that file with large size would not be useful for decryption, then it would be more interesting. If not, it really is a huge dependency. Finally, what I find strange is that I did a recovery.img on twrp-12.1 with trustkernel mode and the img file was compiled. When unpacking and repackaging, the img file went from 32MB to 29.8MB. Why didn't this happen to you?
Comparinng the kernel file by Atom so 9.54 MB so has some strange thing than mine.....
Others files tthat you see: Pictures - Click to open
|
|
ad 1) Vendor/Kernel is A11. LOS/System is A12. As A11 stopped getting security updates I tried to switch to A12 and it worked (at least with LOS). Now I'm trying to get decryption to work (again). The thing with 32MB vs. 29.8MB is that I need a recovery.img with the size of 32MB to properly load. Therefore I'm required to set There are two particular huge files So these are my main concerns right now: Of course I could try that by modifying the resulting ramdisk but I want to be able to do that during building of TWRP and therefore be able to reproduce it later when security updates need to be applied or when upgrading (e.g. to A13 if that's ever going to happen). |
|
Fixing bugs in the trustkernel driver - 4pda What are your thoughts on that? |
First boot messages look promising
But as soon as it starts to load the certs shit hits the fan
The trustkernel intialization is taken from stock rom
https://github.com/ADeadTrousers/twrp_device_Unihertz_Atom_LXL/blob/twrp-11.0-nocrypt/recovery/root/vendor/etc/init/trustkernel.rc#L57
In comparison to the old stock rom a few more parameters need to be set
https://github.com/ADeadTrousers/twrp_device_Unihertz_Atom_LXL/blob/twrp-10.0/recovery/root/vendor/etc/init/trustkernel.rc#L54
The most notable one is
--rpmbdevwhich is mentioned in the error messages. But it doesn't help to leave them out. So my guess is thatteedNEEDS those. The same goes with the second--prot.So the whole problem is:
teedis not able to load the certs[email protected]is not able to authenticate itself againstteed[email protected]is not able to authenticate itself againstteedvoldis not able to utilize gatekeeper and keymaster to decryptTWRP isn't booting, the screen goes blank and after a few seconds the phone reboots.
Deactivating
TW_INCLUDE_CRYPTOlets TWRP boot but without decryption.The text was updated successfully, but these errors were encountered: