Decryption unsuccessful on N5 running Stock 6.0 with ElementalX 6.03

[tejus]

Nexus 5 D821 Stock 6.0 build MRA58K TWRP 2.8.7.1 ElementalX kernel 6.03 SuperSU v2.52 Bootloader state Unlocked SELinux Enforcing

Initially had a PIN and location based Smart Lock enabled. Encrypted it successfully and rebooted a couple of times to make sure. Then changed disk encryption password using this app, confirmed the password I entered was correct in the pop up after it was done. Rebooted to TWRP recovery, saw that the password was reported as wrong. Rebooted to System, again password seems wrong. Earlier pin isn't not working either, of course.

I am 100% sure the password I'm entering is correct, but decryption fails during boot up and in TWRP. I do have the necessary backups (Nandroid, Titanium) on my computer of course, so I will try again on 100% stock (/system, /data, /recovery, but with chainfire's /boot so as to root) after battery charges up and report back.

[mirko]

This exactly happens to me right now, using a CM13 (6.0) nightly build on my Oneplus One and the vdc command (which afaik the cryptfs-password UI is using under the hood). I tried the whole procedure several times to make sure it is not me. TWRP as well as Android itself are reporting wrong password, after changing it via cryptfs-password or vdc. Last string I tried was 'foobar' with quotes and without. I also tried to enter the hex version, with quotes and without in TWRP as well as Android. No luck.

[nelenkov]

Android 6.0 uses a plain string, so no need to convert to hex. You can check if the password is set correctly with vdc cryptfs verifypw. For OnePlus the password needs to be set both to the crypto footer, and the TEE, but the vdc command should take care of this automatically if compiled with the right options.

[mirko]

I see. But I tried that scenario and it doesn't work (for me). Maybe a CM13 bug - but I'd like to have a second experience backing that up.

[gavinhungry]

I'm running CyanogenMod 13 on my Nexus 6P (cm-13.0-20151213-NIGHTLY-angler), here's what I found:

Changing the encryption password with vdc cryptfs changepw password <plaintext> did not work (from looking at the source code here, 200 0 0 indicates success, 200 0 1 indicates failure. @nelenkov can correct me if I'm wrong on that):

# vdc cryptfs changepw password foobar
200 0 0

# vdc cryptfs verifypw foobar
200 0 1

It seems like changepw also expects the current password to be passed:

# vdc cryptfs changepw
500 0 Usage: cryptfs changepw default|password|pin|pattern [currentpasswd] default|password|pin|pattern [newpasswd]

So, I tried passing the default password:

# vdc cryptfs changepw password default_password foobar
200 0 0

# vdc cryptfs verifypw foobar
200 0 0

Which seems to have worked! Note that it doesn't seem to matter what value you pass as the current password - I passed the default password, but passing anything seems to work.

Android and TWRP 2.8.7.2 now decrypt properly with foobar.

[nelenkov]

Thanks! That's interesting, could be a change in 6.0.1, as it works without the current password in 6.0. I'll checkout the latest AOSP source and confirm.

[nelenkov]

This seems to be a CM modification, the change is not in AOSP (as of android-6.0.1_r3).

[gavinhungry]

@nelenkov,

You're right - compare cryptfs_changepw in cryptfs.c in AOSP 6.0.1_r3 to CyanogenMod 13: https://android.googlesource.com/platform/system/vold/+/android-6.0.1_r3/cryptfs.c#3241 https://github.com/CyanogenMod/android_system_vold/blob/cm-13.0/cryptfs.c#L3365

Seems to have been introduced with this commit: https://github.com/CyanogenMod/android_system_vold/commit/a7219c6c66b1bdcad495f3b76be0eb773180b78a#diff-b6e842eb16158d66860db2bb0b11a9daL3237

[nelenkov]

I don't quite see why they need the currentpw parameter. I'll try to support it, but CM has been quite unstable for a while now, not sure if it's really worth it.

[gavinhungry]

I'm not clear on it either, especially since it doesn't seem to be enforced (at least not via vdc cryptfs changepw).

These are early nightlies, though - unstable by definition. So far, these CM13 nightlies have given me far less trouble than the first CM12 nightlies.

[damaestro]

Using cm-13.0-20151226-NIGHTLY-himaul resulted in the following causing me to be unable to unlock encryption:

# vdc cryptfs changepw password default_password foobar
200 0 0

# vdc cryptfs verifypw foobar
200 0 0

I'm taken back that verifypw worked but on reboot I could not unlock with TWRP nor on-boot as usual. How are you initially setting up encryption? It seems if I have a lock screen enabled (pin, pattern or password) encryption is failing to use those settings and I'm unable to unlock on reboot. If I don't have a lock screen, encryption sets up and boots work, but I don't know what to unlock with in TWRP. I'm going to try this default password via TWRP with a fresh install to verify it's actually used.

[damaestro]

Just tried a default encryption without pin, pattern or password set unlocking with TWRP 2.8.7.0 and both https://github.com/CyanogenMod/android_system_vold/blob/cm-13.0/cryptfs.c#L82-L83 with no luck.

[nelenkov]

Sounds like CM broke something again.

[xor-freenet]

@damaestro It would be interesting to know what happens if you use the screen lock pin instead of "default_password" here:

vdc cryptfs changepw password default_password foobar

[xor-freenet]

@damaestro Because it doesn't make sense to use the default_password as old password if you actually have configured a screen lock pin as device encryption password. I've read the cryptfs code a bit and it does pass the old password to the hardware.

[lithorus]

I was able to change the password with the following command :

vdc cryptfs changepw password OldPassword NewPassword

The OldPassword can actually be anything.

And ALWAYS check with 'vdc cryptfs verifypw NewPassword' before rebooting :)

[lithorus]

Forgot to mention that this was on nexus 4 cm13 nightly from 2016-1-1

[damaestro]

@xor-freenet Unfortunately, enabling encryption does not work when lock screen security is enabled (next boot fails with PIN, pattern and password set). Definitely a bug in CM 13 as everything worked in 12.1. However, I found this method and still managed to lock myself out of my device and wanted to report findings.

My test was:

• Fresh install of cm-13.0-20151226-NIGHTLY-himaul (works)
• Default settings, enable encryption and reboot (works)
• Enable lock screen PIN, pattern or passphrase (works, but password seems to not be updated as I'm not prompted for it during boot)
• Try to set a non-default password as previously referenced and reboot (fails, can't boot and TWRP can't unlock with what I set)

@lithorus how did you initially setup the encryption?

I did vdc cryptfs verifypw ... and got a 200, but the next boot failed and I was unable to unlock via TWRP with the same password.

[lithorus]

@damaestro I enabled it under security. 200 is not enough, it has to be "200 0 0". "200 0 1" means that it failed. And again this was with nightly 20160101.

[damaestro]

I'll try again with a fresh install from the latest nightly.

[strobelm]

Hi i can confirm the bug in latest nightly of cm13 on a nexus 5 (hammerheadcaf).

I used '''vdc cryptfs changepw password ''' and i'm pretty sure i'm typing it in correctly. Nevertheless it won't decrypt saying "wrong password". Any idea how to decrypt the phone (despite a reset - of course)?

[lithorus]

Seems to be fixed in the latest nightly (20160109). I changed lockscreen password and the startup password was the same.

[eugenesan]

As of today (20160116) on CM13.0 the following happens:

1. Invoking vdc cryptfs changepw provides the following usage output: 500 0 Usage: cryptfs changepw default|password|pin|pattern [currentpasswd] default|password|pin|pattern [newpasswd].
2. In practice 5th parameter is not supported, meaning one can't specify the new password type. As result the following should be the actual usage: Usage: cryptfs changepw default|password|pin|pattern [currentpasswd] [newpasswd].
3. Since new password type can't be specified, it stays as it was before the command. So if you invoke something like this: vdc cryptfs changepw pin 1234 test, the password will indeed change to "test" but the boot keyboard UI will still be PIN. Note, while you won't be able to boot Android, you still can access data using TWRP.

It would be nice if someone could update us if above changes.

[lithorus]

I would rather think that the first argument is the new password type. Current password is ignored anyway by the command. You can put anything in there really. On 17 Jan 2016 17:23, "Eugene San" [email protected] wrote:

As of today (20160116) on CM13.0 the following happens:

1. Invoking vdc cryptfs changepw provides the following usage output: 500 0 Usage: cryptfs changepw default|password|pin|pattern [currentpasswd] default|password|pin|pattern [newpasswd].
2. In practice 5th parameter is not supported, meaning one can't specify new password type. As result the following is actual usage should be: Usage: cryptfs changepw default|password|pin|pattern [currentpasswd] [newpasswd].
3. Since new password type can't be specified, it stays as it was before the command. So if you invoke something like this: vdc cryptfs changepw pin 1234 test, the password will indeed change to "test" but the boot keyboard UI will still be PIN. Note, while you won't be able to boot Android, you still can access data using TWRP.

It would be nice if someone could update us if above changes.

— Reply to this email directly or view it on GitHub https://github.com/nelenkov/cryptfs-password-manager/issues/14#issuecomment-172346835 .

[eugenesan]

@lithorus, you are correct. Inspecting the code confirms your suggestions. This the commit that introduced the change: https://github.com/CyanogenMod/android_system_vold/commit/a7219c6c66b1bdcad495f3b76be0eb773180b78a

The fix would be the following:

index df4f173..6cd2d93 100644
--- a/CryptCommandListener.cpp
+++ b/CryptCommandListener.cpp
@@ -225,8 +225,7 @@ int CryptCommandListener::CryptfsCmd::runCommand(SocketClient *cli,
         rc = cryptfs_enable_file();
     } else if (!strcmp(argv[1], "changepw")) {
         const char* syntax = "Usage: cryptfs changepw "
-                             "default|password|pin|pattern [currentpasswd] "
-                             "default|password|pin|pattern [newpasswd]";
+                             "default|password|pin|pattern [currentpasswd] [newpasswd]";
         const char* password;
         const char* currentpassword;
         if (argc == 4) {

So the actual format is: Usage: cryptfs changepw default|password|pin|pattern [currentpasswd] [newpasswd]. According to the code one can omit the passwords and then the command will only change UI type.

Test vector was:

1. Enable pin using Settings
2. Enable encryption using settings and test pin after reboot
3. Test PIN using: vdc cryptfs verifypw 1234
4. Change to password: vdc cryptfs changepw password 1234 test
5. Test password using: vdc cryptfs verifypw test
6. Test password after reboot in boot UI.

[nelenkov]

Thanks everyone for the updates. I'll add support for CM13 once the interface stabilizes, but it seems this is not yet the case.

[eugenesan]

Actually I believe CM's interface is stable at least since August-2015. There were two distinct issues since then:

1. Misled interpretation of incorrect usage printout of vdc cryptfs changepw on CM3, which is probably a cosmetic error during merge and not related to the interface itself.
2. There were incremental changes/bugs/fixes in CM13 SettingsApp and are mostly related to the management of the "default" password management and are not directly related to the vdc cryptfs or "cryptfs-password-manager".

Both of the above above issues seems to be resolved and we left with two variants of vdc cryptfs command to support: AOSP's one and CM's.

[tdm]

CM inherited this code from QCOM and, since there is only one call site in the entire code base, it surely wasn't tested for third party usage. I've posted http://review.cyanogenmod.org/#/c/129185 to try and maintain backward compatibility. Can some folks here please test and report back? Thanks!

[nelenkov]

@tdm Looks good, thanks! Hopefully it gets merged.

[nelenkov]

BTW, any idea why CM removed the native support for different FDE and lockscreen passwords (was in CM11, IIRC)? That is by far the best option.

[eugenesan]

Actually I was attempting to push this functionality during the course of several versions of CM and it was finally pulled in during CM10.1. After the functionality was dropped from CM12.1 I've ported even better implementation from https://github.com/CopperheadOS, along with some security improvements, but it was ignored: http://review.cyanogenmod.org/109207 http://review.cyanogenmod.org/109208 http://review.cyanogenmod.org/109209 http://review.cyanogenmod.org/109210

I guess CM has different agenda security wise or they really believe in new H/W assisted Scrypt or/and OnePlus's "TPM" (or whatever it called) while ignoring all users using different devices :-(

P.S. Above is probably a bit unfair toward CM since all AndroidOS vendor (except CopperHeadOS) doing the same, especially Google! There is a several years old open issue on subject on their support forum.