New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decryption unsuccessful on N5 running Stock 6.0 with ElementalX 6.03 #14

Open
tejus opened this Issue Oct 31, 2015 · 66 comments

Comments

Projects
None yet
@tejus
Copy link

tejus commented Oct 31, 2015

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 comment has been minimized.

Copy link

mirko commented Dec 1, 2015

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

This comment has been minimized.

Copy link
Owner

nelenkov commented Dec 2, 2015

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

This comment has been minimized.

Copy link

mirko commented Dec 2, 2015

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

This comment has been minimized.

Copy link

gavinhungry commented Dec 13, 2015

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

This comment has been minimized.

Copy link
Owner

nelenkov commented Dec 14, 2015

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 comment has been minimized.

Copy link
Owner

nelenkov commented Dec 14, 2015

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

@gavinhungry

This comment has been minimized.

@nelenkov

This comment has been minimized.

Copy link
Owner

nelenkov commented Dec 16, 2015

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

This comment has been minimized.

Copy link

gavinhungry commented Dec 16, 2015

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

This comment has been minimized.

Copy link

damaestro commented Dec 30, 2015

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

This comment has been minimized.

Copy link

damaestro commented Dec 30, 2015

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

This comment has been minimized.

Copy link
Owner

nelenkov commented Dec 30, 2015

Sounds like CM broke something again.

@xor-freenet

This comment has been minimized.

Copy link

xor-freenet commented Dec 30, 2015

@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

This comment has been minimized.

Copy link

xor-freenet commented Dec 30, 2015

@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

This comment has been minimized.

Copy link

lithorus commented Jan 3, 2016

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

This comment has been minimized.

Copy link

lithorus commented Jan 3, 2016

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

@damaestro

This comment has been minimized.

Copy link

damaestro commented Jan 5, 2016

@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

This comment has been minimized.

Copy link

lithorus commented Jan 5, 2016

@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

This comment has been minimized.

Copy link

damaestro commented Jan 6, 2016

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

@strobelm

This comment has been minimized.

Copy link

strobelm commented Jan 6, 2016

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)?

@aradis

This comment has been minimized.

Copy link

aradis commented Jan 9, 2016

For those of us unlucky enough to have used Cryptfs Password with CM13, is there a workaround to unlock the phone? I mean, even if CM13 isn't using the new password we provided, it must be using something. The empty string?

Also, until this is fixed, I think Cryptfs Password should add a warning when starting up not to use it with CM13.

@lithorus

This comment has been minimized.

Copy link

lithorus commented Jan 9, 2016

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

@aradis

This comment has been minimized.

Copy link

aradis commented Jan 9, 2016

@lithorus It might work if you are using CM13's built-in password changing (in Settings), but using 'vdc cryptfs changepw password ' (like Cryptfs Password does) is still broken.

As for recovering after using Cryptfs Password on CM13, my analysis shows that the empty string is indeed used as the encryption password. The code flow seems to be:

cryptfs changepw password <newPassword>

vold:
     currentpassword=""
     password=""

     cryptfs_changepw(CRYPT_TYPE_PASSWORD, currentpassword, password)
          = cryptfs_changepw(CRYPT_TYPE_PASSWORD, "", "")
     e4crypt_crypto_complete(DATA_MNT_POINT)
     e4crypt_change_password(DATA_MNT_POINT, CRYPT_TYPE_PASSWORD, newpw)
          = e4crypt_change_password(DATA_MNT_POINT, CRYPT_TYPE_PASSWORD, "")

system/cryptfs.c:
     cryptfs_set_password(<current crypto footer>, password, master_key_bytes)
     encrypt_master_key(password, ftr->salt, master_key, ftr->master_key, ftr, true)

If Cryptfs Password thinks it detected a failure to change the password (which it did in my case), it will try to roll back the change by trying to set the password to the previous password ("current password" in the GUI). In my case the "current password" I used was my PIN, so Cryptfs Password did:

cryptfs changepw pin <original PIN>

vold:
     currentpassword=""
     password=""

     cryptfs_changepw(CRYPT_TYPE_PIN, currentpassword, password)
     e4crypt_crypto_complete(DATA_MNT_POINT)
     e4crypt_change_password(DATA_MNT_POINT, CRYPT_TYPE_PIN, newpw)
          =  e4crypt_change_password(DATA_MNT_POINT, CRYPT_TYPE_PIN, "")

system/cryptfs.c:
     cryptfs_set_password(<current crypto footer>, password, master_key_bytes)
     encrypt_master_key(password, ftr->salt, master_key, ftr->master_key, ftr, true)

If your current password was not a PIN, then it would the flow for the rollback would be the same as the first block of code. AFAICT, the only difference between encrypting the master key with a PIN versus a password is what password entry UI will be used by Android when booting.

Nothing in this flow checks if the password is empty, so it should be using the empty string to encrypt the master key (along with all of the other steps used to encrypt the master key, of course). twrp decrypt doesn't allow an empty password though, so I haven't been able to test if decryption using an empty string is actually successful.

@aradis

This comment has been minimized.

Copy link

aradis commented Jan 13, 2016

To follow up on my workaround attempt, the password is not the empty string. It's also not any four digit numeric PIN, or default_password, or any dictionary word, or any word from the source files. Maybe it's just random bytes that happened to be in memory at the time. In any case, I gave up and did a factory reset & wipe.

@eugenesan

This comment has been minimized.

Copy link
Contributor

eugenesan commented Jan 17, 2016

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

This comment has been minimized.

Copy link

lithorus commented Jan 17, 2016

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

This comment has been minimized.

Copy link
Contributor

eugenesan commented Jan 17, 2016

@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

This comment has been minimized.

Copy link
Owner

nelenkov commented Jan 18, 2016

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

xor-freenet referenced this issue in CyanogenMod/android_device_lge_hammerheadcaf Jan 18, 2016

Revert "hammerhead: Enable hardware-based full disk encryption"
This reverts commit fdc8bf6.

Change-Id: Iabb466bd762bf92e449913c1091b2d9abe531301
@donnm

This comment has been minimized.

Copy link

donnm commented Mar 3, 2016

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

This comment has been minimized.

Copy link

saltlamp commented Mar 3, 2016

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

This comment has been minimized.

Copy link

donnm commented Mar 3, 2016

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

This comment has been minimized.

Copy link

JW0914 commented Mar 3, 2016

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

This comment has been minimized.

Copy link

saltlamp commented Mar 4, 2016

@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

This comment has been minimized.

Copy link
Owner

nelenkov commented Mar 4, 2016

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

This comment has been minimized.

Copy link

saltlamp commented Mar 4, 2016

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

This comment has been minimized.

Copy link

xor-freenet commented Mar 6, 2016

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

This comment has been minimized.

Copy link

bestouff commented Mar 6, 2016

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

This comment has been minimized.

Copy link

saltlamp commented Mar 7, 2016

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

This comment has been minimized.

Copy link

donnm commented Mar 7, 2016

@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

This comment has been minimized.

Copy link

saltlamp commented Mar 7, 2016

@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

This comment has been minimized.

Copy link
Owner

nelenkov commented Mar 8, 2016

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

This comment has been minimized.

Copy link

bestouff commented Mar 8, 2016

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

This comment has been minimized.

Copy link
Owner

nelenkov commented Mar 8, 2016

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

This comment has been minimized.

Copy link

saltlamp commented Mar 9, 2016

@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

This comment has been minimized.

Copy link
Contributor

xmikos commented Mar 21, 2016

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?

@aradis

This comment has been minimized.

Copy link

aradis commented Apr 3, 2016

@donnm @saltlamp So sorry it took so long to reply about how I was able to test different passwords. I added a Gist with the information at the time, but obviously I should have posted it here too.

https://gist.github.com/aradis/e0fe179d69b87afadc90

As well I can remember, the process was:

  1. Don't use TWRP, instead use Cyanogenmod Recovery. The reason is that TWRP doesn't have vold/minivold or vdc so there is no way to mount using the command line.
  2. Cyanogenmod Recovery does run minivold and has vdc. However, ADB is not enabled by default so there is no way to connect to the phone via ADB and therefore no way to run vdc to test different passwords.
  3. To enable ADB in Cyanogenmod Recovery you just have to flip two 0 bytes to 1 bytes using a hex editor. The details are in the Gist.
  4. After booting into the modified Cyanogenmod Recovery image you can connect to the phone via ADB and run vdc to test different passwords. I think the command is "vdc cryptfs verify [password]" or something like that, but consult the vdc source code for the exact format.

I tried every variety of passing an empty password in, but no luck. Automated it to try different PINs and passwords, all a bust. I didn't consider any password attempt limits that might be enforced by the phone. AFAICT the Nexus 5X doesn't have any, or if it does then they are silent. If the 5X does have a limit of 10 or so, then it is possible the limit was reached before I tried the empty password.

For the record, my feature request for enabling ADB by default in Cyanogenmod Recovery is here:
https://jira.cyanogenmod.org/browse/CYAN-7332

@jfeise

This comment has been minimized.

Copy link

jfeise commented Apr 27, 2016

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

This comment has been minimized.

Copy link
Owner

nelenkov commented Apr 28, 2016

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

@donnm

This comment has been minimized.

Copy link

donnm commented Jul 2, 2016

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

This comment has been minimized.

Copy link

bungabunga commented Jul 5, 2016

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.
@aradis

This comment has been minimized.

Copy link

aradis commented Jul 17, 2016

Just confirming that CM13.0 snapshot from April 18, 2016 (cm-13.0-20160418-SNAPSHOT) DOES work with Cryptfs v1.2.6.

Since Cyanogen fixed their syntax, CM13 builds after 20160426 may not work with Cryptfs. If anyone has tried with a newer build and can confirm if it works or not, that would be useful.

@Exagram

This comment has been minimized.

Copy link

Exagram commented Dec 3, 2016

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

@gsauthof

This comment has been minimized.

Copy link

gsauthof commented Jun 5, 2017

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

This comment has been minimized.

Copy link
Owner

nelenkov commented Jun 5, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment