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:
CyanogenMod/android_system_vold@a7219c6#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
#14 (comment)
.

[eugenesan]

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

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.

[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.

[bestouff]

There's no /etc/fstab* nor cryptofooter partition on my LG H815:

lrwxrwxrwx 1 root root 21 2015-01-06 23:26 DDR -> /dev/block/mmcblk0p30
lrwxrwxrwx 1 root root 20 2015-01-06 23:26 aboot -> /dev/block/mmcblk0p8
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 abootbak -> /dev/block/mmcblk0p14
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 apdp -> /dev/block/mmcblk0p18
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 boot -> /dev/block/mmcblk0p38
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 cache -> /dev/block/mmcblk0p49
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 cust -> /dev/block/mmcblk0p48
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 devinfo -> /dev/block/mmcblk0p17
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 dpo -> /dev/block/mmcblk0p20
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 drm -> /dev/block/mmcblk0p40
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 eksst -> /dev/block/mmcblk0p33
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 encrypt -> /dev/block/mmcblk0p32
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 factory -> /dev/block/mmcblk0p43
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 fota -> /dev/block/mmcblk0p44
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 fsc -> /dev/block/mmcblk0p27
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 fsg -> /dev/block/mmcblk0p26
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 grow -> /dev/block/mmcblk0p51
lrwxrwxrwx 1 root root 20 2015-01-06 23:26 hyp -> /dev/block/mmcblk0p6
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 hypbak -> /dev/block/mmcblk0p12
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 keystore -> /dev/block/mmcblk0p29
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 laf -> /dev/block/mmcblk0p37
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 limits -> /dev/block/mmcblk0p16
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 misc -> /dev/block/mmcblk0p22
lrwxrwxrwx 1 root root 20 2015-01-06 23:26 modem -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 modemst1 -> /dev/block/mmcblk0p24
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 modemst2 -> /dev/block/mmcblk0p25
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 mpt -> /dev/block/mmcblk0p42
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 msadp -> /dev/block/mmcblk0p19
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 persist -> /dev/block/mmcblk0p23
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 persistent -> /dev/block/mmcblk0p35
lrwxrwxrwx 1 root root 20 2015-01-06 23:26 pmic -> /dev/block/mmcblk0p2
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 pmicbak -> /dev/block/mmcblk0p10
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 raw_resources -> /dev/block/mmcblk0p45
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 raw_resourcesbak -> /dev/block/mmcblk0p46
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 rct -> /dev/block/mmcblk0p34
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 recovery -> /dev/block/mmcblk0p39
lrwxrwxrwx 1 root root 20 2015-01-06 23:26 rpm -> /dev/block/mmcblk0p7
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 rpmbak -> /dev/block/mmcblk0p13
lrwxrwxrwx 1 root root 20 2015-01-06 23:26 sbl1 -> /dev/block/mmcblk0p3
lrwxrwxrwx 1 root root 20 2015-01-06 23:26 sbl1bak -> /dev/block/mmcblk0p9
lrwxrwxrwx 1 root root 20 2015-01-06 23:26 sdi -> /dev/block/mmcblk0p5
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 sdibak -> /dev/block/mmcblk0p15
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 sec -> /dev/block/mmcblk0p31
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 sns -> /dev/block/mmcblk0p41
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 spare1 -> /dev/block/mmcblk0p21
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 spare2 -> /dev/block/mmcblk0p36
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 ssd -> /dev/block/mmcblk0p28
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 system -> /dev/block/mmcblk0p47
lrwxrwxrwx 1 root root 20 2015-01-06 23:26 tz -> /dev/block/mmcblk0p4
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 tzbak -> /dev/block/mmcblk0p11
lrwxrwxrwx 1 root root 21 2015-01-06 23:26 userdata -> /dev/block/mmcblk0p50

[nelenkov]

There must be a fstab file somewhere, check in the root directory. ls -l /fstab*. The cryptofooter partition goes by different names, that's why you need to check fstab. If there is really no dedicated partition, the cryptofooter is at the end of the userdata partition, right after the end of the filesystem.

[saltlamp]

@nelenkov The warning is well after the actual cryptfs command for Marshmallow and it only warns against CM13 not other MM roms which clearly suffer from this issue. Anyone who goes to this page will run the command thinking it is safe, as there is no indication it can cause potential data loss.

Really hoping someone is working on figuring out how to recover from this empty password issue, if you require a higher compensation please request to contact me directly.

[xmikos]

I have fixed this in my SnooperStopper app (it includes fork of cryptfs-password-manager). See also pull request #16.

Btw. there were no issues on stock Android 6 Google ROM, it has worked without problems (I have tested this extensively on Nexus 5). Only CyanogenMod 13 has been broken. So I really don't know what was @saltlamp problem, maybe LG something broke in their ROM?

[jfeise]

FYI, It seems that after a long long time CM has now support for the original AOSP usage of vold cryptfs back in:
http://review.cyanogenmod.org/#/c/129185/

[nelenkov]

Right after I finally added support for there new syntax...

[donnm]

This has recently come to light, which may be of use for those of us who have backup images we are unable to decrypt:

https://bits-please.blogspot.ro/2016/06/extracting-qualcomms-keymaster-keys.html

[bungabunga]

had problems with Cryptfs PWM after updating my Sony Xperia Z3 compact to Android 6.0.1. It worked on KitKat and Lollypop but not with Marshmallow. I use stock rooted rom, not CM. After reading this post and trying it on my device I can confirm that this command now works on my device:

# vdc cryptfs changepw password (the UI you want) <CURRENT_PIN(PASSWORD/PATTERN)> <NEW_PASSWORD>

so it would look something like this:

# vdc cryptfs changepw password 1234 heyyoudneverguess

the procedure (via @eugenesan):

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.

[Exagram]

Verified with: CM13.0 snapshot from April 19, 2016.

[gsauthof]

I can confirm that with LineageOS 14.1 (20170530-nightly-hammerhead) you still need this syntax:

vdc cryptfs changepw password $oldpw $newpw

It would be great if the README would include such an example. Because the vdc help message doesn't actually match that syntax and is thus misleading:

cryptfs changepw default|password|pin|pattern [currentpasswd] \
                             default|password|pin|pattern [newpasswd]

(i.e. it shows 4 arguments to the changepw instead of 3)

Also, on my system, vdc signals success for verifypw via a 3-tuple like:

200 1234 0

where 1234 seems to be some arbitrarily changing number and the last component denotes the return code (0 -> success, 1 -> failure).

Btw, it would also be great if the README would mention cryptfs cerifypw $currentpw. Perhaps with the recommendation to execute it before and after executing changepw.

Otherwise, the README is a good reference for changing the filesystem password - even if you don't use the app.

[nelenkov]

Please submit a pull request that Lineage OS details to the readme, and I'll merge.