Can't decrypt CM13 (Sultan) Oneplus One (bacon)

[raqbit]

When I put it my pattern for decryption, it doesn't decrypt. I normally would put the recovery log in here, but I'm worried it contains sensitive data that could be used for decryption.

[raqbit]

This is on TWRP 3.0.0-0, because for some reason 3.0.0-1 doesn't wanna flash. (Tried fastboot and Flashify app)

EDIT: apparently I am using 3.0.0-1, but the version number displays otherwise.

[raqbit]

I was able to fix the issue by switching to a pin instead of pattern.

Still the issue exists for the pattern

[zhimsel]

Same issue happening with me on Bacon with CM13 nightlies and TWRP (2.6.8.0-3.0.0-1). I tried with password, pin, and pattern.

[chuegel]

You mean decryption is fixed in 3.0.0.1?

[scheffold]

No, it doesn't work with 3.0.0.1. I'm using pin pattern. The log files says:

I:operation_start: 'TWRP CLI Command' Attempting to decrypt data partition via command line. crypt_ftr->fs_size = 117021080 Using scrypt with keymaster for cryptfs KDF Trying to convert ascii string of odd length Failed to convert passwd from hex kdf failed failure decrypting master key Failed to decrypt master key crypt_ftr->fs_size = 117021080 Using scrypt with keymaster for cryptfs KDF keymaster module name is Keymaster QCOM HAL keymaster version is 3 Found keymaster0 module, using keymaster0 API. Signing safely-padded object Failed to decrypt data. I:Done reading ORS command from command line I:TWFunc::Set_Brightness: Setting brightness control to 255 I:operation_end - status=0 I:Set page: 'decrypt' I:ORS command line read returned an error: 0, 1, Operation not permitted I:ORS command line read returned an error: 0, 1, Operation not permitted

[chuegel]

Ok, thank you. I guess I'll wait with the encryption.

[chuegel]

2.8.7.0 works with encryption

[dtto]

I also have this problem. I upgraded to CM 13. Upgrade went fine, but I went to recovery to install gapps and TWRP 3.0.0.1 cannot decrypt.

Is there any fix in the works?

[dtto]

@huegelc I tried downgrading to 2.8.7.0, but I get the same error.

[xenithorb]

I also noticed this bug today when I attempted to diverge my encryption authentication from my lockscreen authentication (using SnoopStopper - a tool that allows you to change the password, and also shuts down the device when lockscreen is incorrect three times)

Well, It seems there's no way to get this to work right now without using PIN - which is what I was previously using, so I didn't notice anything for a long time.

https://github.com/TeamWin/android_device_oneplus_bacon/issues/10 #

[chuegel]

@dtto using 3.0.0.6 by tugapower this one works for bacon

https://www.androidfilehost.com/?fid=24438995911973604

[h-2]

I have PIN and it doesn't work. Neither with TWRP 3.0.1-0 nor with 2.8.7.0 @huegelc What is tugapower? I am reluctant just flashing anything to my fon.

[bgcngm]

Flash TWRP 3.0.2-0 and it will work.

[h-2]

@bgcngm it does not.

@huegelc tugapower doesn't work either.

[h-2]

Anything I can do to narrow this problem down? Since CM13 I cannot update anymore, if I cannot decrypt so this is a real problem :sob:

[xenithorb]

Im not sure exactly why, but the best thing that you can probably do is backup all your data - use TWRP 3.0.2-0 to format /data, not wipe it - format it. Then wipe everything else, re-flash your image of choice ( if sultans, don't forget to check the forum post and flash the recommended CM build first)

Then boot into a fresh install without restoring anything yet (it will take much less time to encrypt) then encrypt the phone from security settings. Enable pin lock with asking on reboot from lockscreen settings. Test again

[chuegel]

@h-2 strange, pin works for me with tugapower

[ghost]

Flash away =)

TWRP-3.0.2-0-bacon-with-decryption-cm13-AtAM1.img

< compiled using https://github.com/lj50036/platform_manifest_twrp_cm.git + https://github.com/TeamWin/android_device_oneplus_bacon >

[rababerladuseladim]

Flash away =)

TWRP-3.0.2-0-bacon-with-decryption-cm13-AtAM1.img

< compiled using https://github.com/lj50036/platform_manifest_twrp_cm.git + >https://github.com/TeamWin/android_device_oneplus_bacon >

This actually works for me O.O Thank very much @AtAM1

[zhimsel]

@AtAM1 Confirmed, this works for me as well. Thanks!

[dtto]

@AtAM1 Thanks for the fix!

[ghost]

You are all welcome. The crypto patch was actually submitted by @Dees-Troy - so all credit to him (https://gerrit.omnirom.org/#/c/17716/1/crypto/lollipop/cryptfs.c). I merely compiled a working build with the patch included.

[maciejstromich]

Thanks! Finally a working version of TWRP! @AtAM1 @Dees-Troy thank you very much and keep up the good work 👍

[simonepsp]

Unfortunately that TWRP build didn't worked for me :( I'm using a text password (changed with vdc) and I'm not able to decrypt the data partition. I have tried with TWRP 3.0.2.0, 2.8.0.1, 2.7.1.0. None of these worked :(

What should I do? Thanks

I:Copying file /cache/recovery/log to /cache/recovery/last_log I:Is encrypted, do decrypt page first I:Switching packages (TWRP) I:Set page: 'decrypt' I:Set page: 'trydecrypt' I:operation_start: 'Decrypt' crypt_ftr->fs_size = 117021080 Using scrypt with keymaster for cryptfs KDF Invalid hex string Failed to convert passwd from hex, using passwd instead keymaster module name is Keymaster QCOM HAL keymaster version is 3 Found keymaster0 module, using keymaster0 API. Signing safely-padded object load_crypto_mapping_table: target_type = req-crypt load_crypto_mapping_table: real_blk_name = /dev/block/mmcblk0p28, extra_params = fde_enabled Error temp mounting decrypted block device '/dev/block/dm-0' crypt_ftr->fs_size = 117021080 Using scrypt with keymaster for cryptfs KDF keymaster module name is Keymaster QCOM HAL keymaster version is 3 Found keymaster0 module, using keymaster0 API. Signing safely-padded object Failed to decrypt data. I:Set page: 'decrypt' I:operation_end - status=1 I:Set page: 'main' I:Set page: 'clear_vars' I:Set page: 'main2' I:Set page: 'main' I:Set page: 'clear_vars' I:Set page: 'main2'

[libove]

In desperation I've installed this 3.0.2.0 unofficial recovery to again be able to install CM13 nightly updates to my OnePlus One. I was very surprised to find that:

1. it did not ask for a decryption password upon entering recovery, as the stock TWRP 3.0.2.0 (and all recent previous) so, and
2. upon going into advanced -> file manager and copying a file from /sdcard (which is encrypted) to USB-OTG to see if this recovery was really able to get past the encryption, not only did it still not ask me for a decryption password, it said something like "successfully decrypted USING DEFAULT PASSWORD". And, the file copied to USB-OTG is valid, so it did in fact decrypt.

This scares the daylights out of me, because it implies that somehow this recovery is totally bypassing the encryption, or captured and stored the encryption password or key such that anyone who gets their hands on the device can read all the data on the (encrypted) sdcard.

Can someone please comment on just exactly how this unofficial 3.0.2.0 TWRP is doing this bit of decryption magic?

thank you.

[xenithorb]

It's not magic, I think your password is just currently literally "default_password" which is set... by default. It tries this when it detects encryption before anything else

[libove]

xenithorb commented:

It's not magic, I think your password is just currently literally "default_password" which is set... by default. It tries this when it detects encryption before anything else

Not sure why/how my encryption password could get set to "default_password", since I'm the one who set the password when I encrypted the device, and that definitely isn't the password I chose... :-}

I tried to use vdc commands to test my password, but in TWRP Recovery terminal it seems that the vold isn't running to take the commands.

I looked in Settings on the phone and was surprised to find a (new?) option to set up "secure startup", whereby a?the? PIN would be required at startup before the phone would be usable. Not sure if this is in any way related to device encryption, since device encryption comes well before anything is running to a point of being "usable". I set that option just to see what it would do; verdict: wowza... it seems that either a recent CM13 nightly update, or flashing the TWRP 3.0.2.0 unofficial-which-can-decrypt removed the 8-digit PIN encryption-key protector that I'd set before.

Once I re-set that secure startup option, it returned to needing my PIN both at Android startup time, and (working) in Recovery to mount data /sdcard.

[xenithorb]

Right, unsetting the secure startup option sets the vdc password to "default_password" iirc. That's why you don't get prompted for a password on startup, nor does TWRP ask for one either.

[libove]

Thing is, I didn't un-set the secure startup option. It seems to have happened as part of either a CM13 update or of flashing the TWRP 3.0.2.0 unofficial. That's the sort of thing that needs very clear notice to the user at the time, so that the user does not end up unencrypted without realising that it has happened.

[rababerladuseladim]

I was facing the same issue of a suddenly disappearing startup password prompt. Accessibility services seem to disable the prompt: I installed tasked and without any notice the prompt was gone. Any chance you installed an accessibility/notification access app in the meantime? This is rather a general android security policy thing than cm13/twrp specific.

[xenithorb]

Ah yeah I forgot about that. If you look at accessibility settings the wrong way it disables the startup lock.

[libove]

Nope, no changes in accessibility settings, no accessibility apps installed recently (nor ever). The only changes I made were updating CM13 nightlies (until a week+ ago when it became impossible with TWRP 3.0.2.0 standard, or 2.8.6.1 which I also tried earlier today) and flashing TWRP 3.0.2.0 unofficial with the decryption fix in (after which I flashed last night's CM13 nightly). So it was either the Recovery flash or a CM13 nightly that did it. As I had NOT updated Recovery since I first started with CM13 some months ago, and I think - I think - that I realised that the startup PIN prompt was gone quite recently, my guess is that it was something in a CM13 nightly within the past couple of weeks.

[nitram9]

Yes - that us exactly what happened to me and seems like it could be an attack vector to compromise the system.

On Aug 3, 2016 17:57, "Jay Libove" notifications@github.com wrote:

Thing is, I didn't un-set the secure startup option. It seems to have happened as part of either a CM13 update or of flashing the TWRP 3.0.2.0 unofficial. That's the sort of thing that needs very clear notice to the user at the time, so that the user does not end up unencrypted without realising that it has happened.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/TeamWin/Team-Win-Recovery-Project/issues/596#issuecomment-237225083, or mute the thread https://github.com/notifications/unsubscribe-auth/ATQEZ4d9mgyCSRwLaU3Jw9chcA_MOipzks5qcIuXgaJpZM4HqFF- .

[libove]

Oh, h*ll. Known issue with Android: https://lastpass.com/support.php?cmd=showfaq&id=8936 https://code.google.com/p/android/issues/detail?id=79309

Until Google fixes this craziness, we have to be aware that enabling Accessibility services (which includes things like LastPass, Moto Voice, and others) can SILENTLY disable the requirement to enter a PIN,etc before the device can access its decryption key, effectively making the device unencrypted. (There's detail in the code.google.com page above about why actually the device is still encrypted, but it's a major weakness compared to the decryption key itself being encrypted with a password/PIN). And, though Android does give a (poorly worded, confusing) warning about it, I still assert that the disabling of the PIN-at-boot security is 'silent' because normally to disable any kind of PIN security the user must explicitly enter their PIN at the moment the security feature is disabled, and here the user flow disconnects the two enough that it's not clear to me (as a security engineer, nor to others who have also posted on the code.google.com thread) what is about to happen, and how to fix it thereafter.

[libove]

So anyway it was probably neither the Recovery flash nor the CM13 nightly flash, but rather a recent LastPass update and this Android bug/feature which caused the PIN-at-boot to go away.

And we've hijacked the original purpose of this thread - which is that TWRP can't decrypt CM13 devices which are encrypted. Hopefully the presently-unofficial TWRP 3.0.2.0 will get updated to include the decryption bugfix soon!

[ArchangeGabriel]

Is there a planned release with this fix included? Would be nice. ;)

[UltraSalem]

Thanks AtAM1. Saved my butt there. :)

[gnufred]

@AtAM1 fix works for me! Thanks :)

[ArchangeGabriel]

@Raqbit Why did you close this? It’s not fixed in the latest 3.1.0 release, is it?

[raqbit]

Whoops! Was cleaning up old issues and thought this was fixed already. I updated to cm14 without encryption, and currently on the latest LineageOS nightly, still without encryption. So this issue isn't 'mine' anymore, but I'll open it if you still think this is something that's going to be fixed in the future.

[ArchangeGabriel]

Well OK, this is expected to be an issue only on Android 6 builds, so I guess I should just make the jump to LineageOS or Omnirom…