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" notifications@github.com 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.

[donnm]

I'm having this problem.

I noticed that after flashing a recent nightly my CM13 began booting without asking for a password (I have FDE enabled w/ password). Somehow it was reset? So after trying unsuccessfully with the Cryptfs Password app I changed the password using the (wrong) vdc syntax:

vdc cryptfs changepw password "my new password"

Yes it contains some spaces. I received "200 0 0" and then rebooted and now I cannot decrypt the data partition. Sadly I did not try to verify before rebooting and my backup lies on the data partition.

Seeing as I left the newpassword blank, what password could I now use to decrypt my data partition?

[donnm]

@aradis How did you rule out the empty string, 4 digit pin, etc? I'm not ready to give up and wipe. See my comment above.

[cm13test]

The issue is still there, I have tested with more CM13 (Android 6.0) nightlies (21st, 22nd, 23rd February) on Samsung Galaxy S5 (klte).

Please support Cyanogenmod 13, cryptfs password manager is one of the first apps I install on all of my phones.

I also would like to say thank you for the valuable job you do.

[JW0914]

I don't believe this is an issue with CM13, as I've had this issue on stock Android for my Nexus 6 (image pulled directly from google), as well as CM13 (nightlies from 2/24 & 2/26). I've tried around 5x on stock Android, and 3 or 4x on CM13, with cli cryptfs, as well as the cryptfs password app, both changing the encryption password successfully, but not accepting the password for decryption.

Seeming as this was not an issue in 5.x backwards, and only began with 6.0, this seems to indicate this is either a bug in 6.0, or some fundamental change was made in 6.0 to the changing of the encryption password.

[saltlamp]

I am in need of urgent assistance. I have lost extremely valuable data and am willing to pay for its recovery. My backup has been damaged and currently this is the only option i have left. This question has been asked in this thread before but no answer has been given.

Was running LG H4 H811 stock rooted Android 6.0.1 with TWRP installed, with a 4 pin code screen lock with encryption enabled. Everything was fine and I could boot by entering the pin code without issue. I used the following command:

vdc cryptfs changepw password [another 4 digits]

It returned 200 "something"...I don't remember what. I chose 4 digits because I was worried it would not switch from the pin code keyboard to the qwerty keyboard so I was testing it out. Once restarted it did indeed switch to a full password qwerty keyboard however neither the old or the new pin are working. TWRP also cannot access the encrypted partition however it couldn't before either it is simply not updated properly for Marshmallow yet on my device.

Could someone please explain what has happened? I must recover this data. Anyone who is able to help me with this issue will be compensated for their time in FULL.

Currently i believe either some empty or arbitrary password has been set, or the entry UI is set to qwerty password vs pin entry which may lead to a different handling of the input which would explain why it won't boot. It seems someone has tested an empty password saying it doesn't actually work. The next step for me is to try and switch the input UI back to pin code however I am unsure how to do this.

Please guys help me shed some light on this issue.

[damaestro]

I'm sorry to let you know, the only way I got around this was to reset my device; erasing everything.There seems to be a disconnect between the user space and the underlying crypto functions. I really hope we figure it out as this has bit me multiple times. I was hopeful it was a CM13 bug, however I'm no longer sure.

[JW0914]

I haven't been able to get it to work on a stock Nexus 6 or a Nexus 6 with CM13 installed.... Android simply refuses to accept the correct password

[donnm]

I'm in the process of trying to compile TWRP from source with a patch to allow entry of an empty password to see if that decrypts. @aradis did you by chance already try this?

@saltlamp I would recommend making an image of your data partition.

[saltlamp]

The image of the data partition won't help unless it's on the phone itself because the key is stored in a trusted execution chip of sorts.

What i am wondering is how to reset the number of tries remaining i'm down to 22/30 or if this is even possible.

Also wondering if this chip has a hard limit regardless if the attempts are made through boot or twrp.

Also wondering if the input keyboard makes a difference, eg qwerty or pin code, and where that flag is stored (data/system/?).

Also wondering what exactly the source code says android does when it receives an empty password.

There's a bounty to get TWRP working with MM encryption but no takers, I'd probably bump it up significantly if I knew someone would work on it:

https://www.bountysource.com/issues/25741595-twrp-for-h815-2-8-7-0-and-2-8-6-1-can-not-decrypt-lg-g4-h815

Looking forward to your guys' findings. If someone is technically capable of researching these issues let me know and I'm happy to pay for your time.

Also, the readme for this github needs to be updated because it is giving people the wrong instructions regarding manual password updating through terminal on MM (and other versions possible) which is why I am in this situation to begin with.

[donnm]

I made an image in the hopes that once this was solved I could reflash it and try again, in the mean time I had to wipe the data partition to use my phone. Is this feasible or is there something I'm missing?

Do you see some limited number of tries when you say you are down to 22/30? Or are you manually keeping track? I may be over that limited already.

[JW0914]

From another conversation on a different thread, there's the possibility cryptfs took the inputted password as hex. take the password you had entered and convert the entire string to hex and see if that works to decrypt. If it's just numbers, all windows calculators have a programmer option which allows you to convert dec <-> hex

If the all numerical password had an odd number of digits, you may have to input 0 in front of the hex output when entering it as a password.

[saltlamp]

@donnm Yes it actually tells you how many tries you have left and despite restarting the phone it will keep that record until you input the correct password and it resets to 30 tries again. After you have exhausted your tries it says it will perform a factory reset (will wipe the data).

As for your image it might be different for different phones, the image might still work assuming when android initially boots it doesn't reset the embedded hardware keys. Some phones have encryption on by default in which case it probably would reset them.

[nelenkov]

If you boot into recovery, without mounting /data, you can reset the number of tries by editing the cryptofooter with a binary editor. Take an image of the cryptofooter partition and analyze it on your PC. See the Santoku-Linux repo.

[saltlamp]

I tried converting dec->hex with both upper case and lower case characters. Also tried converting string->hex. Doesn't work unfortunately.

I will repeat my offer who ever figures this out I will pay more than the cost of a brand new high end phone.

@Nelenkov if you have time please look into this issue, also update the readme of this git as it doesn't warn of such hazards using the cryptfs without the "old password" variable.

[xor-freenet]

I went to IRC and pointed the CyanogenMod folks at this issue, this was the reply:

<ciwrl> im fairly sure thats external to the device itself and something we looked at already
<ciwrl> http://review.cyanogenmod.org/#/c/129185/
<ciwrl> for the cryptfs item

[bestouff]

Hi everyone,

I don't know if it's related, but today I encrypted my CM13 2016-03-03 phone (H815), which has a schema lockscreen. Now I can decrypt successfully when entering the schema at boot, but after that entering it again to unlock doesn't work. I'm locked out of my phone, any idea ?

[saltlamp]

Ok so just to reiterate, this problem is not exclusive to the CM13 builds, it happened on my MM 6.0.1 T-mobile LG G4 H811.

The code seems to use the empty password to encrypt, but as @aradis has pointed out that this does not work to decrypt. Not sure how he did these tests as in some cases if we was using TWRP then TWRP cannot decrypt regardless of if you are using the correct password or not. @aradis any input on how you did these tests would be appreciated.

@nelenkov Please update the readme so others don't lose data like I did.

I am now offering $2000 to anyone who can figure out how to recover the encrypted data partition after executing cryptfs with an empty password.

[donnm]

@saltlamp I've now compiled TWRP 3.0.0 to accept empty passwords, but haven't been successful testing it yet due to minor issues with my build like ADB not connecting and TWRP's terminal commands not working. I'm getting there though.

In the mean time, @aradis please provide more info on how you tested!

[saltlamp]

@donnm make sure that twrp can decrypt a normally encrypted data partition first since as I mentioned above twrp does not successfully decrypt all the newer phones.

[nelenkov]

I've updated the README. It has had warnings all along. It is not exactly clear what LG changed to break things with FDE. You should take a full (with dd) backup of the userdata and cryptofooter partition. Look for the encryptable or forceencrypt flag in /etc/fstab.<devicename> to find out the cryptofooter partition.