Doesn't work with Android 9

[jfeise]

Unfortunately, this app doesn't work with Android 9. Google has taken away the ability to use raw vdc cryptfs commands.

[utack]

Is there anything we can do?
Do I have to downgrade to Android 8, encrypt+vdc cryptfs, and then install Android 9 on top of that already encrypted data partition?

[jfeise]

Is there anything we can do? Do I have to downgrade to Android 8, encrypt+vdc cryptfs, and then install Android 9 on top of that already encrypted data partition?

I tried that, didn't work. The reason is that when you select a screen lock pin/password/pattern on first boot of Android 9, it sets it for the encryption as well (or, if you select not to use it for encryption, it clears the encryption password.) I have tried this with LineageOS 16.0 on my OnePlus 3 phone. Since I build the OS myself, I actually modified the code to not change the encryption key when setting the screen lock. I believe it should be possible to call the function in the Android StorageManager from an app. Haven't tried that yet, though. In the LineageOS 16.0/Android 9 code, this is in frameworks/base/services/core/java/com/android/server/StorageManagerService.java, the function is called changeEncryptionPassword(int type, String password)

[bastei]

As a workaround, you can do the following (on your own risk):

1. set the desired password for the screen lock
2. backup lockscreen files:
   1. all files under /data/system_de/0/spblob/
   2. files containing "_synthetic_password_" in /data/misc/keystore/user_0/
   3. /data/system/locksettings.db
3. set the desired password for the device encryption
4. restore / replace all lockscreen files

If something went wrong, sqlite into /data/system/locksettings.db and set the values of sp-handle and lockscreen.password_type to 0 to reset the screen lock.

[dartraiden]

As a workaround, you can do the following

Does not work with Pixel Expirience on my Redmi Note 4X, but I found a much easier method:

1. set the desired password for the device encryption
2. restart, check the encryption
3. delete /data/system/locksettings.db from recovery (this removes the screen lock)
4. set the desired password for the screen lock and reject the offer to use it for device encryption

[utack]

4. set the desired password for the screen lock and reject the offer to use it for device encryption

for me this resets the encryption password and it is disabled

[dartraiden]

Maybe it depends of firmware...

Just tested again (Redmi Note 4X with Pixel Experience):

• installed the firmware (without setting the lock screen)
• Settings → Security and Location → Screen lock → Password → Yes

• rebooted with my password
• rebooted to recovery, decrypted /data
• deleted /data/system/locksettings.db (also deleted locksettings.db-wal and locksettings.db-shm just in case)
• rebooted to system with my password
• Settings → Security and Location → Screen lock → PIN → No

Rebooted to system with my password and unlocked screen with my PIN.

[utack]

@dartraiden exactly what I did, but then encryption was "disabled" (emtpy password) once I selected "no" on encrypted startup Maybe they changed the behaviour

[jfeise]

@dartraiden exactly what I did, but then encryption was "disabled" (emtpy password) once I selected "no" on encrypted startup

That's the behavior I see in the LineageOS 16.0 source code, I assume that came from AOSP. Maybe some manufacturers have changed it.

[myfirstnameispaul]

I performed the following steps with my Galaxy S5 SM-G900T: Formatted data from recovery Installed LineageOS 16, gapps pico, and Lineage SU Booted into system Set password and required on boot Rebooted to system, entered password to boot Enabled encryption Rebooted to system, entered password to boot Rebooted to recovery, entered password to decrypt data Deleted /data/system/locksettings.db and associated files Rebooted to system, entered password to boot Set screen lock PIN and selected NO to require PIN on start Rebooted to system, not prompted to enter password to boot.

What did I do wrong?

Note that the phone is still encrypted.

[jfeise]

I performed the following steps with my Galaxy S5 SM-G900T: Formatted data from recovery Installed LineageOS 16, gapps pico, and Lineage SU Booted into system Set password and required on boot Rebooted to system, entered password to boot Enabled encryption Rebooted to system, entered password to boot Rebooted to recovery, entered password to decrypt data Deleted /data/system/locksettings.db and associated files Rebooted to system, entered password to boot Set screen lock PIN and selected NO to require PIN on start Rebooted to system, not prompted to enter password to boot.

What did I do wrong?

Note that the phone is still encrypted.

That's how LineageOS works. If you select NO to require pin or password on start LineageOS clears the password.

[dartraiden]

Yes, some firmware (LineageOS) remove encryption, some (PE) leave it on

[thedroidgeek]

I've added support for Android 9 on my fork and included an .apk for download, but in order for this to work, the app has to be systemized and privilege whitelisted (both of which can be done using the 'App Systemizer' module which can be downloaded directly through the Magisk Manager, though be sure to choose '/system/priv-app' when prompted for the install location) so it can be allowed the CRYPT_KEEPER permission in order for it to be able to access the StorageManager stuff and work its magic.

[k4tfish]

I had no luck with your fork on LOS 16, the CRYPT_KEEPER permission doesn't exist.

systemize -d cryptfs-app-debug.apk                                         
 Checking APK size - 1M
 Transfering cryptfs-app-debug.apk(org.nick.cryptfs.passwdmanager) to '/system/priv-app'...
 Granting Permissions
 org.nick.cryptfs.passwdmanager - Done
 android.permission.CRYPT_KEEPER doesn't exist!

[thedroidgeek]

I had no luck with your fork on LOS 16, the CRYPT_KEEPER permission doesn't exist.

systemize -d cryptfs-app-debug.apk                                         
 Checking APK size - 1M
 Transfering cryptfs-app-debug.apk(org.nick.cryptfs.passwdmanager) to '/system/priv-app'...
 Granting Permissions
 org.nick.cryptfs.passwdmanager - Done
 android.permission.CRYPT_KEEPER doesn't exist!

Yeah I don't know why it complains about the permission with the -d option, but the way I did it is by installing as a regular app first, then I ran systemize in prompt mode (no args) and chose the Systemize Installed Apps (Listed) option.

It's also worth to check that there's a /system/etc/permissions/privapp-permissions-org.nick.cryptfs.passwdmanager.xml after the script runs, with something like:

<?xml version="1.0" encoding="utf-8"?>
<!--
        Generated by App Systemizer (Terminal Emulator) by veez21
-->
<permissions>
    <privapp-permissions package="org.nick.cryptfs.passwdmanager">
        <permission name="android.permission.CRYPT_KEEPER"/>
    </privapp-permissions>
</permissions>

[icescalar]

I was able to install cryptfs-password-manager on LOS 16.0 as @thedroidgeek suggested. The privapp-permissions-org.nick.cryptfs.passwdmanager.xml is also were it should be.

but when i try to change the password using the app, i just got an error "Password change error. Failed to change device encryption password."

Any idea?

[thedroidgeek]

I would need a logcat to find out what happened.

[icescalar]

I would need a logcat to find out what happened.

05-03 19:29:29.273 3207 12932 W s.passwdmanage: Accessing hidden method Landroid/os/storage/IStorageManager$Stub$Proxy;->changeEncryptionPassword(ILjava/lang/String;)I (dark greylist, reflection) 05-03 19:29:29.273 3207 12932 W s.passwdmanage: Accessing hidden method Landroid/os/storage/IStorageManager;->changeEncryptionPassword(ILjava/lang/String;)I (dark greylist, reflection) 05-03 19:29:29.273 3207 12932 W System.err: java.lang.NoSuchMethodException: changeEncryptionPassword [int, class java.lang.String] 05-03 19:29:29.278 3207 12932 W System.err: at java.lang.Class.getMethod(Class.java:2068) 05-03 19:29:29.278 3207 12932 W System.err: at java.lang.Class.getMethod(Class.java:1690) 05-03 19:29:29.285 3207 12932 W System.err: at org.nick.cryptfs.passwdmanager.CryptfsCommands.changePasswordNoVerifyPie(CryptfsCommands.java:268) 05-03 19:29:29.286 3207 12932 W System.err: at org.nick.cryptfs.passwdmanager.CryptfsCommands.changeCryptfsPasswordPie(CryptfsCommands.java:236) 05-03 19:29:29.288 3207 12932 W System.err: at org.nick.cryptfs.passwdmanager.MainActivity$ChangePasswdTask.doInBackground(MainActivity.java:264) 05-03 19:29:29.290 3207 12932 W System.err: at org.nick.cryptfs.passwdmanager.MainActivity$ChangePasswdTask.doInBackground(MainActivity.java:212) 05-03 19:29:29.295 3207 12932 W System.err: at android.os.AsyncTask$2.call(AsyncTask.java:333) 05-03 19:29:29.295 3207 12932 W System.err: at java.util.concurrent.FutureTask.run(FutureTask.java:266) 05-03 19:29:29.300 3207 12932 W System.err: at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:245) 05-03 19:29:29.304 3207 12932 W System.err: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) 05-03 19:29:29.304 3207 12932 W System.err: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) 05-03 19:29:29.304 3207 12932 W System.err: at java.lang.Thread.run(Thread.java:764)

[thedroidgeek]

Lol, I didn't even realize they also added reflection restrictions on Pie 😮 I also don't know why my device running on official LineageOS 16 nightlies didn't have this greylist... Oh well, here's a build targeting API 27 which should hopefully cause these checks to be bypassed, let me know if it works. Oh, and make sure to unsystemize the old app, reboot, install the new one, systemize and reboot.

[icescalar]

seems to work, thanks a lot...

[532910]

@thedroidgeek, it works, thank you!

[t-aus-m]

Worked for me as well! :+1:

[LevN0]

The latest version of the fork linked above does not seem to work on Pixel 3. Obtain "Password change error. Failed to change device encryption password"

07-24 14:06:34.078 639 661 D SurfaceFlinger: duplicate layer name: changing org.nick.cryptfs.passwdmanager/org.nick.cryptfs.passwdmanager.MainActivity to org.nick.cryptfs.passwdmanager/org.nick.cryptfs.passwdmanager.MainActivity#1 07-24 14:06:34.865 4159 7983 W s.passwdmanage: Accessing hidden method Landroid/os/ServiceManager;->getService(Ljava/lang/String;)Landroid/os/IBinder; (light greylist, reflection) 07-24 14:06:34.865 4159 7983 W s.passwdmanage: Accessing hidden method Landroid/os/storage/IStorageManager$Stub;->asInterface(Landroid/os/IBinder;)Landroid/os/storage/IStorageManager; (light greylist, reflection) 07-24 14:06:34.865 4159 7983 W s.passwdmanage: Accessing hidden method Landroid/os/storage/IStorageManager$Stub$Proxy;->changeEncryptionPassword(ILjava/lang/String;)I (dark greylist, reflection) 07-24 14:06:34.928 639 1970 D SurfaceFlinger: duplicate layer name: changing org.nick.cryptfs.passwdmanager/org.nick.cryptfs.passwdmanager.MainActivity to org.nick.cryptfs.passwdmanager/org.nick.cryptfs.passwdmanager.MainActivity#2 07-24 14:06:34.942 639 660 D SurfaceFlinger: duplicate layer name: changing Dim Layer for - Task=10530 to Dim Layer for - Task=10530#1 07-24 14:06:35.106 639 1970 W SurfaceFlinger: Attempting to set client state on removed layer: org.nick.cryptfs.passwdmanager/org.nick.cryptfs.passwdmanager.MainActivity#1 07-24 14:06:35.106 639 1970 W SurfaceFlinger: Attempting to destroy on removed layer: org.nick.cryptfs.passwdmanager/ org.nick.cryptfs.passwdmanager.MainActivity#1 07-24 14:06:35.122 639 1970 W SurfaceFlinger: Attempting to set client state on removed layer: Dim Layer for - Task=1 0530#0 07-24 14:06:35.122 639 1970 W SurfaceFlinger: Attempting to destroy on removed layer: Dim Layer for - Task=10530#0

Do not see any errors in logcat yet still does not work.

[thedroidgeek]

@LevN0 Your device does not use Full-Disk Encryption (#24).

[LevN0]

Learn something new every day. Seems like it fundamentally means the device is insecure when bootloader is unlocked unless your lock screen is a very long password?

[eugenesan]

@LevN0 According to https://source.android.com/security/encryption/file-based#dependencies it seems file encryption keys are still derived from a combination of user's key and a key stored in H/W protected buffer and derivation process is handled by a "gatekeeper" ( https://source.android.com/security/authentication/gatekeeper), which have "throttling" built in to resist brute force attacks. The question is: Is the gatekeeper a software-only solution and can be attacked/replaced by altering OS with an unlocked bootloader? I really hope the gatekeeper is somehow H/W dependent.

Hopefully, someone more competent will chime in.

[innir]

@thedroidgeek Thanks for your fork, worked flawlessly for me!

BTW: I didn't need this Magisk stuff, just installing as system app via adb worked for me:

adb root
adb remount
adb push app-debug.apk /system/priv-app/
adb shell chmod 644 /system/priv-app/app-debug.apk
adb reboot

And uninstalling it afterwards with adb shell pm uninstall -k --user 0 org.nick.cryptfs.passwdmanager should be fine, right?

Edit: I'm on LineageOS 16.0 [unofficial build though]

[jfeise]

Looks like at least for LineageOS 16 they are putting the changepw functionality back in: https://review.lineageos.org/c/LineageOS/android_system_vold/+/254062

[gcvl]

I've added support for Android 9 on my fork and included an .apk for download, but in order for this to work, the app has to be systemized and privilege whitelisted (both of which can be done using the 'App Systemizer' module which can be downloaded directly through the Magisk Manager, though be sure to choose '/system/priv-app' when prompted for the install location) so it can be allowed the CRYPT_KEEPER permission in order for it to be able to access the StorageManager stuff and work its magic.

@thedroidgeek Your fork works wonders on LineageOS 16 and Galaxy S5, thank you!

[jhdohrmann]

Lol, I didn't even realize they also added reflection restrictions on Pie open_mouth I also don't know why my device running on official LineageOS 16 nightlies didn't have this greylist... Oh well, here's a build targeting API 27 which should hopefully cause these checks to be bypassed, let me know if it works. Oh, and make sure to unsystemize the old app, reboot, install the new one, systemize and reboot.

@thedroidgeek Thanks for providing a fork that apparently solved the issue for some users. I am happy that someone is working on the issue.

1.) My Problem: I am using a Fairphone 2 with LineageOS 16 , rooted via AddonSU (see https://download.lineageos.org/extras ). I presume for this case any Magisk-based solution to be not suitable to make the app privileged and systemized. Is there any idea, how I still can make use of it?

I tried the workaround of innir (see https://github.com/nelenkov/cryptfs-password-manager/issues/25#issuecomment-522025046 ), but this rendered LineageOS unbootable for me. (Hangs in the boot animation, then...)

2.) If the change mentioned by jfeise above ( https://github.com/nelenkov/cryptfs-password-manager/issues/25#issuecomment-523072963 ) is now part of LineageOS, shouldn't the original app work again for any recent LineageOS version? I am wondering -- I tried (as far as i can remember: with lineage-16.0-20200120) but apparently failed: It states that my existing password -- which I believe to have entered correctly -- was wrong...

[rodrigoaguilera]

Looks like at least for LineageOS 16 they are putting the changepw functionality back in: https://review.lineageos.org/c/LineageOS/android_system_vold/+/254062

Does this means that this app works again since last August? I am thinking if I should move to lineageOS 16