Changing Android's disk encryption password

We've been discussing some of Jelly Bean's new security features, but this post will take a few steps back and focus on an older one that has been available since Honeycomb (3.0), announced in the beginning of the now distant 2011: disk encryption. We'll glance over the implementation, discuss how passwords are managed and introduce a simple tool that lets you change the password from the comfort of Android's UI.

Android disk encryption implementation

Android 3.0 introduced disk encryption along with device administrator policies that can enforce it, and advertised it as one of several 'enhancements for the enterprise'. Of course Honeycomb tablets never really took off, let alone in the enterprise. Disk encryption however persevered and  has been available in all subsequent versions. Now that ICS is on about 16% of all Android devices and Jelly Bean's share will start to increase as well in the coming months, disk encryption might finally see wider adoption.

Unlike most internal Android features, disk encryption has actually been publicly documented quite extensively, so if you are interested in the details, do read the implementation notes. We'll only give a short overview here, focusing on key and password management.

Android's disk encryption makes use of dm-crypt, which is now the standard disk encryption sybsystem in the Linux kernel. dm-crypt maps an encrypted physical block device to a logical plain text one and all reads and writes to it are decrypted/encrypted transparently. The encryption mechanism used for the filesystem in Android is 128 AES with CBC and ESSIV:SHA256. The master key is encrypted with another 128 bit AES key, derived from a user-supplied password using 2000 rounds of PBKDF2 with a 128 bit random salt. The resulting encrypted master key and the salt used in the derivation process are stored, along with other metadata, in a footer structure at the end of the encrypted partition (last 16 Kbytes). This allows for changing the decryption password quickly, since the only thing that needs to be re-encrypted with the newly derived key is the master key (16 bytes).

The user-mode part of disk encryption is implemented in the cryptfs module of Android's volume daemon (vold). crypfs has commands for both creating and mounting an encrypted partition, as well as for verifying and changing the master key encryption password. Android system services communicate with cryptfs by sending commands to vold through a local socket, and it in turn sets system properties that describe the current state of the encryption or mount process. This results in a fairly complex boot procedure, described in detail in the implementation notes. We are however, more interested in how the encryption password is set and managed.

Disk encryption password

When you first encrypt the device, you are asked to either confirm your device unlock PIN/password or set one if you haven't already, or are using the pattern screen lock. This password or PIN is then used to derive the master key encryption key, and you are required to enter it each time you boot the device, then once more to unlock the screen after it starts. As you can see from the screenshot below, Android doesn't have a dedicated setting to manage the encryption password once the device is encrypted: changing the screen lock password/PIN will also silently change the device encryption password.

This is most probably a usability-driven decision: most users would be confused by having to remember and enter two different passwords, at different times, and would probably quickly forget the less often used one (for disk encryption). While this design is good for usability, it effectively forces you to use a simple disk encryption password, since you have to enter it each time you unlock the device, usually dozens of times a day. No one would enter a complex password that many times, and thus most users opt for a simple numeric PIN. Additionally, passwords are limited to 16 characters, so using a passphrase is not an option.

So what's the problem with this? After all, to get to the data on the phone you need to guess the screen unlock password anyway, so why bother with a separate one for disk encryption? Because the two passwords protect your phone against two different types of attack. Most screen lock attacks would be online, brute force ones: essentially someone trying out different passwords on a running device after they get brief access to it. After a few unsuccessful attempts, Android will lock the screen for a few minutes (rate-limiting), then if more failed unlock attempts ensue, completely lock (requiring Google account authentication to unlock) or even wipe the device. Thus even a relatively short screen lock PIN offers adequate protection in most cases. Of course, if someone has physical access to the device or a disk image of it, they can extract password hashes and crack them offline without worrying about rate-limiting or device wiping. This in fact, is the scenario that full disk encryption is designed to protect from: once a device is stolen or confiscated for some reason, the attacker can either brute force the actual device, or copy its data and analyze it even after the device is returned or disposed of. As we mentioned in the previous section, the encrypted master key is stored on disk, and if the password used to derive its encryption key is based on a short numeric PIN, it can be brute forced in seconds, or at worst, minutes. This presentation by viaForensics details one such attack (slides 25-27) and shows that this is far from theoretical and can be achieved with readily available tools. A remote wipe solution could prevent this attack by deleting the master key, which only takes a second and renders the device useless, but this is often not an option, since the device might be offline or turned off.

Hopefully we've established that having a strong disk encryption password is a good idea, but how can we set one without making screen unlocking unusable?

Changing the disk encryption password

As we mentioned in the first section, Android services communicate with the cryptfs module by sending it commands through a local socket. This is of course limited to system applications, but Android comes with a small utility command that can directly communicate with vold and can be used from a root shell. So as long as your phone is rooted, i.e., you have a SUID su binary installed, you can send the following cryptfs command to change the disk encryption password:

$ su -c vdc cryptfs changepw newpass
su -c vdc cryptfs changepw newpass
200 0 0

This doesn't affect the screen unlock password/PIN in any way, and doesn't impose any limits on password length, so you are free to set a complex password or passphrase. The downside is that if you change the screen unlock password, the device encryption one will be automatically changed as well and you will need to repeat the procedure. This is not terribly difficult, but can be cumbersome, especially if you are on the go. You should definitely start this Android issue to have it integrated in Android's system UI (which will probably require extending the device policy as well), but in the meantime you can use my Cryptfs Password tool to easily change the device encryption password.

The app tries to make the process relatively foolproof by first checking your current password and then displaying the new one in a dialog if the change succeeds. However, you will only be required to use the new password at the next boot, so it is important not to forget it until then, and take a full backup just in case. Short of brute-forcing, the only way to recover from a forgotten encryption password is to factory reset the device, deleting all user data in the process, so proceed with caution. The app will verify that you have root access by checking if you have one of the more popular 'superuser' apps (Superuser or SuperSU) installed, and trying to execute a dummy command with su at startup. If your device is not encrypted, it will refuse to start.

The implementation is quite straightforward: it simply invokes the verifypw and changepw cryptfs command using the passwords you provided. If you are interested in the details, or simply won't let a random app mess with your device encryption password, clone the code and build it yourself. If you are the more trusting kind, you can install via Google Play.


While Android's disk encryption is a useful security feature without any (currently) know flaws, its biggest weakness is that it requires you to use the device unlock PIN or password to protect the disk encryption key. Since those are usually rather short, this opens to door to practical brute force attacks against encrypted volumes. Setting a separate, more complex disk encryption password using the provided tool (or the directly with the vdc command) makes those attacks far less effective. This does currently require root access however, so you also need to make sure that your device is otherwise secured as well, mainly by relocking the bootloader, as described in this article


SeattleAndrew said…
This was the most helpful article I've read on android disk encryption yet, thank you
Nikolay Elenkov said…
Thanks! Glad you find it useful.
SeattleAndrew said…
Do you know if Jelly Bean (Android 4.1) changed anything about this process? Like if the encryption and/or key are now SHA-2 (256-bit) rather than 128-bit?
Nikolay Elenkov said…
I was looking at Jelly Bean source code while I was writing this, so it should be up-to-date. Also see my comments on the android-security-discuss mailing list :)
SeattleAndrew said…
Already did, just going to say you're awesome, definitely the person I need to be talking to. :D
Geoff Flarity said…
Wow, your blog is very informative. Thanks so much for sharing!

Marcos said…
This comment has been removed by the author.
konker said…
Thanks for the information & for making this utility available to the public!
Do you know if its possible to change the password for encrypting an external SD card?
My ICS tablet offers the ability to encrypt the external SD card but it only uses the unlock password. Changing the DE password does not affect the password for mounting/encrypting the SD card.
Nikolay Elenkov said…
Glad you find it useful.

Encrypting the SD card is a vendor (or other third party) extension, and is probably different on different devices, so I can't really help. What device are you using? Do you have any third party MDM (device management, etc.) apps/extensions installed?
konker said…
Thanks for your prompt response!
I'm using a rooted Us Thinkpad Tablet running official stock ICS 4.0.3 ROM.
I'm under the impression that the SD card encryption is based or dependent on the ICS Device Encryption capabilities.
Is it possible to use the commands you highlighted to change the password for the SD card?
What options or perimeters should I use?
Nikolay Elenkov said…
It might be an extension of the AOSP code, but I have no idea how it is implemented and I don't have this device either. Maybe try searching on Thingpad Tablet forums on XDA or similar sites, someone might have done this already.
konker said…
Thanks for the reply.
I think I would have to dig deeper to see if there's a way to do that.
BTW, I tried your app on a friend's rooted stock ICS 4.0.4 AT&T Samsung Captivate Glide & it kept reporting an invalid password with the warning "The current encryption password is incorrect".
I've typed the password many times & I'm confident it is correct.
I even changed the password even after a reboot, I got the same error message.
Are you aware of anything that could possibly prevent the change of the encryption password?
konker said…
I just ran the ADB command you outlined:
$ su -c vdc cryptfs changepw newpass
& it worked flawlessly.
I was able to change the disk encryption password.
Nikolay Elenkov said…
If it works from the command line it might be a problem with the app. Does the password have any special characters in it (not letters or digits)? The app does handle does, but the procedure is somewhat tricky so there might be a problem somewhere.
Thank you. Very well and understandable written.
I'm new to the smartphone world ( I will receive my first one this week) and looking for security issues and your article is very informative and i will use this information to change my encryption password.
Nikolay Elenkov said…
Thanks, glad you find the post useful. Keep in mind that using this method requires rooting the device, which may void your warranty in some cases. Make sure your device works reliably first and, as usual, proceed with caution.
David Jones said…
This stuff is down t earth, hats off buds out there.
learn how to root your android tablet and phone
Deviant Ollam said…
this is a fantastic piece. i am definitely going to have more of my clients experiment with using Android encryption, now that i know it's so easy to set the crypto password as something separate from the screenlock.

I am VERY curious how android encryption is handled when making nandroid or other similar filesystem backups. For example, i use Team Win Research Project's TWRP Recovery. I have read that this supports and understands encrypted /data partitions but i am very curious as to how well it works.

I am also wondering how secure the resulting backup files (which often reside on the microSD card) are. Does it just make a raw image of that partition, in its encrypted state?

And therefore, it must be a requirement that RESTORING from backup should involve restoring /system as well as /data ... since the resultant boot scenario must be one where the android O/S is expecting to see an encrypted /data partition.

Nikolay Elenkov said…
Thanks, glad you find it useful. Do keep in mind that this requires root and as such is not supported (by Google, carriers, etc.), in case support is important for your clients.

TWRP works fine with encrypted /data. It will ask for your password on boot and mount /data if you provide the correct one. If you don't it still works, but is not particularly useful. On phones where the 'SD card' (external storage) actually resides in /data that is actually the only way to backup/restore. If you use such a device, the backup images will be in /data and thus encrypted. I haven't looked into the implementation in detail though and don't know whether it takes a raw image of the encrypted partition (probably does).

Not sure what you mean by the /system comment above? IIRC, Android will check the /data header to see if it is encrypted, and if so present the password prompt so it can decrypt it. There is nothing special in /system, as long as it is a compatible version (3.0+), it should work.

Marie John said…
hi, When encrypting an Android device, do the certificates installed on the device get encrypted too. Please reply..
Nikolay Elenkov said…
As explained in the first section, the /data partition is encrypted. Anything stored there will be encrypted on disk.
BengtSv said…
Hi! Rooted my Galaxy S2 with jelly bean, installed cryptfs, changed pin to password and encrypted the SD card. Cryptfs will not work, I get the message that the device is not crypted, which is correct. I assume that cryptfs is not intended to be used when only SD card is encrypted.
Before I go ahead and encrypt the whole device I would like to know how to enable screen lock print while encryption is active. Do I set password, encrypt, change PW with cryptfs and after that I can disable PW and set screen Pin. If that doesn't work I will have to a full restore to get out of encryption.
Nikolay Elenkov said…
Encrypting external storage (SD card) is not supported by stock Android, that's a Samsung extension. I have no idea how it works. Not exactly clear what you want to do, but generally after you encrypt, changing the screen lock password/PIN will also change the encryption password. You can use the app (or vdc cryptfs) to change only the device encryption password without affecting the screen lock PIN/password. This is explained in detail in the article.
konker said…

Thanks for responding.
I missed your reply & just returned from a trip with my family.
There are the normal characters & digits along with 1 or 2 special characters like @ & !.
It seems this is also happening on another Samsung Galaxy S2 Skyrocket running stock rooted ROM.
It kept saying the current password is invalid no matter how many times I typed it.
Using ADB, I got Invalid ID: cryptfs when running the commands.
What do you think is happening?
You seem to provide the most help yet:), but here is my situation: I encrypted phone and sd card in October. Couple days ago I changed pin lock screen. Now I cant get into phone with new or old passwords. I've tried several attempts and to no avail. In addition, I contacted service provider and Samsung. No one will help me. If I factory reset I lose all data on phone and encrypted card. I also tried ADB, but to no avail as well. My phone will not provide serial number, as well even acknowledge on my PC. Any suggestions?
Nikolay Elenkov said…
If you can boot the phone and get to the lock screen, in the standard Google configuration (not sure if Samsung has changed that) and keep trying different PINS, eventually it will ask you for your Google account password. If you provide that, you should be able to login and change the PIN, etc.

If you cannot boot, but have an unlocked bootloader or custom recovery, you can try extracting the boot sectors and brute force the encryption PIN, there are tools available for this. Since that's only 1000 combinations, it should be done in minutes tops.
I've tried 500 attempts, no avail for google, otherwise i would be all good. I truly believe my phone has a serious glitch. But on another note, as it is booting up, i noticed when i tap the home button repeatedly along with the emergency call button, at times i can see inside the phone such as: text messaging, phone dialer, etc., but i know i am not fast enough to overwrite that. I'm thinking the bootloader is locked (not that tech savvy), but i do know that when I hold the down volume key and power button, it goes to a custom os. I have not done anything there because I am nervous of wiping this phone out. With the information given could I still brute force? Or just give up?
Nikolay Elenkov said…
If it is booting, something could probably be done. Your best bet is find someone to actually look at it, or better yet, contact a company that specialized in data recovery.
Yea, I have a guy in town who gives me a 50% chance he may possibly retrieve the data but then I will have to reboot the phone. Taking it to him tomorrow. I appreciate your help. I just feel its unfortunate when the provider nor the manufacturer can assist in their products. I understand legalities, but it is my phone I want in. I did not lose my passwords, I know it is a glitch within my phone because every forum and person I spoke to has no understanding of my situation. And I have even reached out to "experts" and tried several different softwares. It is what it is. Thanks again!
That's awesome. Is there a way to decrypt from the command line as well?
Nikolay Elenkov said…
Decryption is not supported by AOSP, it is most likely a vendor extension. If you want to revert to unencrypted /data on a stock device, you have to reset it. You can use `adb backup` to save/restore same of your data and apps. To backup the entire partition use a recovery that understands encryption, such as TWRP.
Raoul Bhatia said…
I would like to emphasize that "changing the screen lock password/PIN will also silently change the device encryption password.".

I changed my password and a couple of days later my pin.

Another couple of days went by and i decided to upgrade my phone to the next release of my most favorite ROM (cyanogenmod).

Upon my first reboot, i was puzzled which key to use (old pin = old password or my manually updated one) and completely forgot about the above note.

I even thought that the update might have broken something ... tried to mount my encrypted data via clockworkmod recovery

I then, by chance, entered my current pin and voila, everything worked again.

I hope that this may help someone out there too :)
Anubis said…
Could you add that statement to the main entry? It's not specified the behaviour respect to both internal and external sdcards.
Anubis said…
Could you add that statement to the main entry?
Tal Palant said…
First great article!

A thought of the encryption key is stored locally on the device and could be retrieved by several ways like cold boot attacks.

In your opinion how effective is actually the android encryption?
Nikolay Elenkov said…
Thanks. The key is stored encrypted, cold boot, etc. try to read it from memory (RAM). Encryption it just as effective as on desktop PC's, etc. that do not have/use a TPM.
Aleka said…
Excellent tool!
Can the screen lock be reverted back to pattern unlock (or basically anything other than password/PIN) after using Cryptfs Password?
Nikolay Elenkov said…
No, this requirement is enforced by the system.
Chris Kerr said…
HI there,

Wondering if you might be able to help. Like konker reported back in March, I'm getting issues when trying to enter my password via TWRP too. I also have to have my device encrypted for my work's MS Exchange access

I'm using latest TWRP and have had no issues with my encryption password not being recognised with this version of TWRP before (previous TWRP versions, this current TWRP version on a previous ROM)

Device details - I'm using an international (GSM) HTC One. Recently I have upgraded to Android 4.4/Sense 5.5 via Telstra OTA update. The ROM is entirely stock from Telstra, just unlocked/rooted. Super user is via SuperSU v1.80

Any help would be awesome! I have also posted on XDA-Developers:
Chris Kerr said…
Sorry typo... phone is running Android 4.3 and not 4.4 as previously stated.
SBS said…
Nikolay, thanks for this - I just now noticed this post. Very good work. I've also experienced problems decrypting with TWRP (v. for 2012 wifi N7 aka grouper). Any thoughts on what may be causing this?

SBS said…
that wasn't supposed to be posted here. Not used to blogger's comment system.
Nikolay Elenkov said…
Not sure, but the key derivation algorithm has changed in 4.4. If you started an encrypted device with 4.4 at least once it has been updated. Maybe TWRP still does not support the new algorithms (scrypt)?
Philip S. said…
I was wondering, since the key is generated immediately after reboot from /dev/urandom, is there sufficient entropy in the system to guarantee security? I'm not sure whether Android saves any entropy on shutdown, particularly when it reboots automatically to encrypt in place.
Nikolay Elenkov said…
Android does save entropy periodically and on shutdown and feeds it to /dev/urandom on startup. As of 4.4 this is done pretty early in the boot sequence, so encryption should be OK. You'll have to check the exact sequence for previous versions.
Tal Palant said…
Hi do you know if encrypting the sdcard is still a Samsung extension? the built in version doesn't support sd card encryption?
Nikolay Elenkov said…
It depends on what you mean by 'SD card'. If it is used as external storage, it will be encrypted in 4.4. If it is treated as secondary external storage, it won't in AOSP. I have not idea what exactly Samsung are doing.
Atif Salman said…
I have erroneously encrypted my contacts in SMS. I don't remember the password. How can I cancel encryption in android.
Ricky Quinlan said…
i tried your instuctions but i was not successful.

root@android:/ # su -c vdc cryptfs changepw password
su -c vdc cryptfs changepw password
200 0 -1

i noticed my results ended in -1 where as yours ended in 0

Nikolay Elenkov said…
What device and Android version did you try this on? The -1 signifies some kind of error, look at logcat, there might be some error message there.
Ricky Quinlan said…
the device is a Samsung s3 i747. i am not sure what version of the software was on nor is the owner but i am guessing its 4.3. it has a custom recovery TWRP 2.6 so i am able to get into the recovery but wiping the phone is no good. where can i get the logcat?
Ricky Quinlan said…
This comment has been removed by the author.
Nikolay Elenkov said…
Samsung has made some changes to how disk encryption works, which could be the cause of your problems. Try entering the current password first using `su -c vdc cryptfs verifypw pass`
So why are you trying to change the encryption password anyway? Does it sync when you change the lockscreen password?
Ricky Quinlan said…
what i really want is to disable it. its preventing me from installing a new rom.
Nikolay Elenkov said…
The data partition being encrypted cannot prevent you from installing a new ROM. Also changing the password won't make a difference even if you succeed, the device will still be encrypted. AFAIK some Samsung devices allow for reverting device encryption, check if yours supports this. Otherwise you will have to back up the things you need and factory reset the device in order to return it to an unencrypted state.
Johan Mitander said…
Hi man. Please help ,me out!!

I have a Galaxy S5, with 4.2.2 ( see for full version) stock that is now rooted and encrypted. I really need and want to change the password for only 16 characters. Not to mention having the password and PIN for screenlock seperated......

But it won't work with your appfix, neither the adb command. I receive the same message as Ricky above with -1.

PLEASE help me out. I really need this!!

Thanks in advance
Johan Mitander said…
Also, just to be sure. I am supposed to:
$ su -c vdc cryptfs changepw insertymynewpasswordhere
su -c vdc cryptfs changepw insertmypnewasswordhere
200 0 0
Nikolay Elenkov said…
Yes, and if you get a "200 0 0" response, the command succeeded. Note that Samsung uses a proprietary disk encryption mechanism, and I have no idea how exactly it works. Make sure you backup your data, in case you are note able to boot the device after messing around with vdc cryptfs.
charu maan said…
hey i have encrypted my xolo phone but my sim card is not shown
fringotingo said…
Will you be able to update this app for Lollipop? I hope so. It has been fantastic on my phone so far. Cheers.
Nikolay Elenkov said…
Updated code is on Github, it needs a bit more testing before pushing to Play Store. You can build the app yourself if want to use it now.
Unknown said…
With CM-12 on OnePlus One, cryptfs (and the underlying vdc cryptfs changepw password ) fails.
When I reboot, it says "password is correct, but the data is corrupted."
The OnePlus One uses hardware encryption, that is likely to be the issue.
cryptfs works fine with CM-12 on my Nexus 4 and Nexus 7 devices.
Nikolay Elenkov said…
CM-12 has a dedicated menu for changing the encryption password, use that instead of this app. Hardware encryption, if implemented properly, should be transparent, so it's unlikely that this is the issue. Maybe there are other FDE customizations, but I don't have the device.
Dimitri Martens said…
I've got an issue with SD encryption on an HTC M8. It got factory reset by HTC while replacing a broken screen and now I can't access none of my pictures any more. I know my password but would like to know if there's any way I could decrypt the files.
Dimitri Martens said…
This comment has been removed by the author.
Resurrecting the dead... Thank Nikolay for sharing your expertise on this issue. Works like a charm.

Now I'm considering the next step for a gain in convenience without sacrificing security, and I'd like to profit from your expertise and get your opinion about it.

(Known) facts:
- You should use a strong encryption password, as described here, to protect against "cold" attacks (e.g. after losing your phone).
- You should use a display lock to protect against "hot" attacks, but it does not necessarily need to be as strong.
- You should use a SIM PIN lock to prevent people getting access to your phone number / connection.

As of now (I'm on Android 4.4.4), this means I have to enter three passwords on boot - first SIM PIN, then encryption pw, then display lock. I have a faint idea that there might be ways to avoid display lock right after boot, but what really bothers me is the SIM lock.
Is there any reason not to store the SIM PIN on the encrypted part of the phone, and have it entered automagically after mounting the cryptfs? (For a production version, probably a table which identifies the SIM card and chooses the appropriate password from a list of selected entries.)
AFAIU, there already are ROMs which keep the SIM PIN in memory to avoid connection losses after a crash of some software part followed by a soft reboot - e.g., I experienced this (or a similar) workaround for the infamous RIL bug of the Motorola Defy+ with its stock ROM. Also, there's a "soft reboot" feature enabled by some mods for rooted ROMs, which only restarts the software, but does not require unlocking the cryptfs once again; I'm not sure if the SIM is re-locked and re-unlocked during that process.

And if such an approach causes no security concerns, can you imagine an easy way of enabling it? Where "easy" for the time being means possible using the Xposed framework or the like on a rooted phone, but with some stock ROM. There is a module which avoids the need for unlocking the SIM after coming back from flight mode, but this seems to work by not locking the SIM in the first place.
Of course, integrating such a functionality for Cyanogenmod et al. might also be worthwhile, but is left as an exercise to the interested reader...
Whoopsie: Once you find the "Load more" button at the bottom, the thread doesn't look all that dead anymore... ;-)
Nikolay Elenkov said…
The interface to the RIL is different on different hardware and/or Android versions, so might be device-specific. An Xposed module might not be portable, but you could probably get one working for your own device. Just call the appropriate Telephony method to pass the PIN to the SIM after booting. You might want to modify the keyguard to unlock the SIM (if necessary) as part of unlocking the device. This will allow you to use the *device* PIN to derive a key which would encrypt the *SIM* PIN on disk. (because you don't really want to store the PIN on disk, disk encryption buys you nothing once the phone boots).
I see, thanks. Actually I did not think about having to modify the original ROM to delay the unlocking of the SIM. I guess that makes it more invasive (and more difficult) than what I wanted to achieve. And also you have a good point about not storing the PIN on disk - it will be protected if the device is lost powered off, but will lower security if the device is infected by some malware.

Back to the drawing board...
grx said…

some example logcat for the -1 error on changing pw:

D/VoldCmdListener( 239): cryptfs changepw password {}
W/Cryptfs ( 239): Password not correctly hex encoded.
D/QSEECOMAPI: ( 239): QSEECom_get_handle sb_length = 0x2000
D/QSEECOMAPI: ( 239): App is already loaded QSEE and app id = 2
D/QSEECOMAPI: ( 239): QSEECom_dealloc_memory
D/QSEECOMAPI: ( 239): QSEECom_shutdown_app, app_id = 2
I/Cryptfs ( 239): Using scrypt with keymaster for cryptfs KDF
E/Cryptfs ( 239): Trying to convert ascii string of odd length
E/Cryptfs ( 239): Failed to convert passwd from hex
E/Cryptfs ( 239): scrypt failed
E/Cryptfs ( 239): Error encrypting master key

also the usage of changepw seem to have slightly changed:

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

Nikolay Elenkov said…
This log is from Lollipop, which requires the password to be hex-encoded. See the README of the app for some details:
Hi, Nikolay. Tell me, please, how to enter the current password, if I use a 4x4 pattern lock? I tried different ways. The problem is, how to enter a two-digit number? In the case of 3x3 pattern simple. We have only single digits. What about double-digit?
Hi, Nikolay. Tell me, please, how to enter the current password, if I use a 4x4 pattern lock? I tried different ways. The problem is, how to enter a two-digit number? In the case of 3x3 pattern simple. We have only single digits. What about double-digit?
Hi, Nikolay. Tell me, please, how to enter the current password, if I use a 4x4 pattern lock? I tried different ways. The problem is, how to enter a two-digit number? In the case of 3x3 pattern simple. We have only single digits. What about double-digit?
loudsilence said…
Hi Nikolay, thanks for your great article!

Now, would you mind if I use your expertize? My phone woke up one day asking for a key to decrypt storage (upon a reboot)... needless to say that I never tried to encrypt it.

I have tried to do a factory reset but I can't access recovery menu. I also tried volume up/down + power key combination to do recovert but no luck.

Am I left with a bricked phone?

Model is Sony Xperia M

Any help would be welcome!
Thank you in advance

Popular posts from this blog

Password storage in Android M

Decrypting Android M adopted storage

Unpacking Android backups