Compatibility CM 13

[f4stb00t]

Hi,

first I want to thank you for the great work. Your little Software works like a charm. I still don't get it, why Google does not implement this. Who wants to use a 30+ symbols/letters/digits Password everytime to unlock a phone...

But back to Topic. I tried Snooper Stopper on CM 13. Fist run it asks for root priviliges. I grant them, but that's all. I cannot change the Password.

Please be so kind and have a look on this.

kind regards

fastboot

[xmikos]

@f4stb00t Sorry for late reply. You are lucky that it didn't work, CM13 broke vdc cryptfs command horribly, see e.g. here:
Decryption unsuccessful on N5 running Stock 6.0 with ElementalX 6.03 #14

I am looking into solution, problem is that some people are reporting similar problems with stock Android 6, but stock AOSP didn't make those changes to vdc cryptfs command (only CyanogenMod 13 did), so it should be OK there. I will test it on Nexus 5 soon.

[xmikos]

@f4stb00t New version of SnooperStopper is compatible with bot stock Android 6 and CyanogenMod 13 (I have tested it on Nexus 5).

[xenithorb]

This does not work with a OnePlus one on "stock" CM 13

Perhaps more work may be required

The warning message did display about it not working properly, and to gain a root shell to use vdc cryptfs before rebooting, which I did (though I adequately backed up everything anyway, so i wasn't worried)

That prompted me to follow the advice here: nelenkov/cryptfs-password-manager#14 (comment)

Which boiled down to using this: Usage: cryptfs changepw default|password|pin|pattern [currentpasswd] [newpasswd] (the actual message output by changepw is still incorrect)

And that worked, I was able to reboot and decrypt with my actual password, and my lockscreen password was also still usable.

[xmikos]

@xenithorb SnooperStopper is now using cryptfs changepw default|password|pin|pattern currentpasswd newpasswd format if it detects CyanogenMod 13. Am I right that OnePlus One is not using CyanogenMod, but Cyanogen OS (that is only based on CyanogenMod)? If that is true, maybe it isn't detected by SnooperStopper as CyanogenMod. I dont't have access to OnePlus One, so unfortunately I can't debug it. It is detected by searching for "ro.cm.version" string in /system/build.prop. Can you please look into that file is this string is there? If not, please attach /system/build.prop from your device.

[xenithorb]

I assure you I'm using CM13 nightly

shell@bacon:/ $ cat /system/build.prop  | grep ro.cm                                                                                                                   
ro.cm.device=bacon
ro.cm.build.version.plat.sdk=5
ro.cm.build.version.plat.rev=0
ro.cm.version=13.0-20160319-NIGHTLY-bacon
ro.cm.releasetype=NIGHTLY
ro.cmlegal.url=https://cyngn.com/legal/privacy-policy
ro.cm.display.version=13.0-20160319-NIGHTLY-bacon

The version of SnooperStopper is 1.3 from F-Droid. I do not have google play, sorry.

[xenithorb]

In attempting to try it again, it also thinks my current password, that I know works, is incorrect "Invalid password"

I'm going to attempt next to change the password to something simple and try again

[xmikos]

@xenithorb version 1.3 from F-Droid should be OK. This is strange, it should be detected all right (on Nexus 5 it did work without problems, I can't see what is different in this case).

Can you show me output of adb logcat when trying to change encryption password with SnooperStopper?

[xenithorb]

Ok, so a few things:

1. When I changed the password manually I did so to a 20+ character password. Works fine everywhere else but this app. SnooperStopper, seemingly because of the size of the string does not like the password, and threw "password invalid" as I stated above.
2. When I changed the password again, through adb shell as root, to 'test', then going back to SnooperStopper, and entering 'test' as the current password, and 'test1', 'test1' as the subsequent password change, it worked.
3. My initial experience where it failed was probably unrelated to the above, as I had a PIN code originally. I have just tested this theory again, by going through stock settings and setting a new PIN code. I then attempted to input that into the resulting window that popped up (asking me to change my SnooperStopper/cryptfs password again) and it failed with the same error message.)

So it would appear that there is an issue with PIN -> Password using SnooperStopper

[xenithorb]

Just to clarify since I can be wordy sometimes there appear to be two issues present:

1. Invalid password when using very long passphrases (or conflating using very long passwords from vdc cryptfs changepw and that is conflicting somehow)
2. PIN -> Password doesn't seem to work unless that is not expected to

[xenithorb]

Hmm. Weirder result than I thought:

From vdc cryptfs verifypw 'test' after going from a PIN, shows 200 0 0, where testing the original PIN fails.

Thus, it seems as though it is setting it properly but displaying the error message still. That was not something I tested for the first time

[xenithorb]

For issue 1. it had to do with spaces. I first tested string length and that didn't seem to cause a problem. Once I added a space it failed.

I then confirmed by making the password literally 'a b' and it told me it was invalid inside the app (while working fine on the commandline) Quoting or word-splitting issues?

To consolidate the issues again:

1. Spaces cause invalid password (thus basically disallowing people to use passphrases) in app only (works on the backend side)
2. Error message is displayed about setting password when going from PIN, but actually does set the password OK.

[xmikos]

Do you have some time? I will compile debug build with small change in passing of passphrase to vdc and with enabled debug logging and upload it so you can try it and send me output of adb logcat.

[xenithorb]

Sure. Do you have a list of things to grep for like App name, etc, will that be sufficient? I have various things running in the background and I'd rather not leak sensitive information since this is not a dev-only phone but my daily driver. If you're happy with just grepping that app name that makes things a lot easier

[xmikos]

Ok, here it is. Please beware that it is DEBUG build and this will log your password in logcat! Use it only for debugging purposes.
snooperstopper_debug.zip

EDIT: It is signed by different (debug) key, so you must first uninstall SnooperStopper and then install this debug build.

[xmikos]

I have tried changing from PIN to password on my Android 5 phone and it worked without errors. I can't try it on Android 6 right now (I have swtiched to Copperhead OS on my Nexus 5), but I am pretty sure that I have tried it before releasing version 1.3 and it has worked (both on stock Google ROM and CyanogenMod 13). So please try to extract relevant lines from logcat.

[xenithorb]

Case 1: Changing the password after using vdc cryptfs changepw:

• Symptom: An error message is displayed that the password change did not complete successfully, but it actually does

Lines 132-133:

32 03-24 18:25:33.201   204   233 E QSEECOMAPI: : Error::ioctl call to update the encryption key for usage 1 failed with ret     = -1, errno = 22
133 03-24 18:25:33.201   204   233 E Cryptfs : Error updating device encryption hardware key ret -9

Line 188, 219:

188 03-24 18:25:33.264 17244 17570 I SuShell : command: /system/bin/vdc cryptfs verifypw test1
219 03-24 18:25:34.333 17244 17570 D SuShell : command output: 200 0 0

Full log: http://paste.fedoraproject.org/344883/88588981

Case 2: Changing the password from stock "PIN":

• Symptom: When changing the password from stock PIN to password via SnooperStopper, an error message is displayed that it did not complete successfully, but it actually does.

Line 135-137, 220:

135 03-24 18:37:47.483   204   233 E QSEECOMAPI: : Error::ioctl call to update the encryption key for usage 1 failed with ret = -1, errno = 22
136 03-24 18:37:47.483   204   233 E Cryptfs : Error updating device encryption hardware key ret -9
137 03-24 18:37:47.484 17244 17363 D SuShell : command output: 200 0 -1

Note: when setting from the commandline manually, it ALSO outputs 200 0 -1 but verifypw still works, and it does decrypt. (That's my way of saying shrug)

220 03-24 18:37:48.603 17244 17363 D SuShell : command output: 200 0 0

Full log: http://paste.fedoraproject.org/344884/88595801

Case 3: Setting new password from a password with spaces

• Symptom: when entering a previous passphrase with spaces, the app displays an error icon (red stop sign) and notifies the user that the password is invalid when it is, in fact, not.

Line 9,21:

  9 03-24 18:52:32.595 17244 17570 I SuShell : command: /system/bin/vdc cryptfs verifypw a b
 21 03-24 18:52:32.633 17244 17570 D SuShell : command output: 500 0 Usage: cryptfs verifypw <passwd>

Does appear not to quote 'a b', the command errors out because it did not expect another argument. I'm going to leave testing setting a password with spaces up to you.

Full log: http://paste.fedoraproject.org/344889/86014714

[CaviaPorcellus]

Just wanted to add that it's definitely not just a CM13 thing: I just got this error on a Nexus 5 using stock Android 6.0.1 (MMB29V).

Also, there were no spaces in my password. I did have some other non-alphanumeric characters in it though.

[xmikos]

@xenithorb Both Case 1 and Case 2 seems to be caused by hardware encryption (QSEECOMAPI). It seems that it doesn't work as expected in CM13 on OnePlus One. I am surprised that decryption works after this (it apparently failed to upgrade key in hardware TEE / QSEE). I am afraid I can't do much about it :-( Bug must be IMHO somewhere in vdc cryptfs code.

Case 3 is probably because I forget to change verifypw too (I have only changed changepw). Try this new DEBUG build:
snooperstopper_debug_2.zip

[xmikos]

@aibaraiduas I have tested it extensively on Nexus 5 with stock Android 6.0.1 (MMB29V) and CyanogenMod 13.0 (snapshot from 20160316) and I didn't see any problems. But it is true that I have tested only simple password without spaces or more exotic special characters. If you have any special character which can be interpreted by shell, this can really be the cause. I should add some proper escaping...

[xenithorb]

@xmikos is it too unreliable to rely on the output of verifypw for case 1 and 2? It does in fact return 200 0 0 which is what I was trying to show you. (It almost seems like your checking verifypw is moot?) There is in fact a case that I was still working on that does complete successfully:

Case 4: Changing the password after changing it from within the app

• Symptom: Password changes successfully with no error messages, but you must exit app first completely, then restart app - this works without issue

Line 178-180:

03-24 19:17:49.407   204   233 E QSEECOMAPI: : SUCCESS::ioctl call to update the encryption key for usage 1 success with ret = 0
03-24 19:17:49.407   204   233 I Cryptfs : Encryption hardware key updated
03-24 19:17:49.408 21417 21676 D SuShell : command output: 200 0 0

Full log: http://paste.fedoraproject.org/344892/58861486

---

I myself am very confused as to why this scenario works.

Let me try the next build then...

[xenithorb]

Ok the new build works without issue regarding spaces

What's basically left is:

• First password set after vdc cryptfs changepw OR system lockscreen set gives false message about failure on OnePlus One (or maybe other HW implementations?)

I had no error since when I used debug_2 I did not use the system lockscreen settings or vdc to change the password beforehand.

[xmikos]

@xenithorb Thank you! Did you tried also to actually reboot device? Just to be sure that it didn't actually encrypted it with 'pass phrase' (including single quotes) instead of pass phrase...

[xmikos]

Btw. about that HW encryption problem... I remember reading somewhere (maybe it was in nelenkov/cryptfs-password-manager#14, but I am not sure) that cryptfs verifypw did say OK, but despite it after reboot device couldn't be decrypted (because of HW key not being updated, or HW key API expecting key to be in hexadecimal encoding... which is what your case also looks similar, seems like broken vdc cryptfs, but this case should have been fixed in latest snaphot of CM 13.0).

[xenithorb]

Hmm yeah, you're right. I rebooted and couldn't decrypt.

Well, now that my phone is bare, I guess I'll test out some scenarios

Edit: Ok I think that's because I was being lazy about inputting the previous password on the commandline before I changed it....

Something wonky happens when you don't give it the previous password and you get 200 0 -1

[xenithorb]

Very strange behavior indeed, it's almost embarrassing for something so integral to the security and data of the system:

root@bacon:/ # vdc cryptfs changepw
500 0 Usage: cryptfs changepw default|password|pin|pattern [currentpasswd] default|password|pin|pattern [newpasswd]
root@bacon:/ # vdc cryptfs changepw password 'test' 'test1' 
200 0 0
root@bacon:/ # vdc cryptfs changepw password 'foo' 'test2'
200 0 -1
root@bacon:/ # vdc cryptfs verifypw 'test2'
200 0 0
root@bacon:/ # vdc cryptfs verifypw 'test1'                                    
200 0 1
root@bacon:/ # # PW IS ACTUALLY 'test1' !!!!!
root@bacon:/ # vdc cryptfs changepw password 'test1' 'new_pass1'
200 0 0
root@bacon:/ # vdc cryptfs verifypw 'new_pass1'
200 0 0

That doesn't even work btw, it's totally broken. I have no idea what the key is again. Wow.
Edit: Lol that's what I get for trying TWRP first. So TWRP has separate limitations too, this keeps getting better. Wow.

[f4stb00t]

Hi xmikos,

thanks for the new version. But this one does not work for my HTC m8. It tells me that I used the wrong password. Any ideas?

[f4stb00t]

Btw. Is it possible to do the whole process by hand? Like in ADB shell or something to have a temporary workaround until snooper stopper works for me?

[takiainen]

@f4stb00t This worked for me: (first set short pin lock screen, then encrypted via settings): vdc cryptfs changepw password [your pin without brackets] [YourNewSuperSecureLongPasswordWithoutBrackets]

[zeorin]

OmniRom 6.0.1 user here. @takiainen's method worked for me, too.
I was also able to use spaces in my password by surrounding it with quotes (which are not necessary to use when entering decryption password on boot).

[Sirove]

Seems like changing the password is still not working with CM13. :(
I'm wondering why Cryptfs Password Manager is working for this purpose but SnooperStopper doesn't although the "whole device encryption password changing code is taken from Nikolay Elenkov's Cryptfs Password Manager."?

[utack]

vdc cryptfs changepw password oldpin newpassword

This is still working on LineageOs 14.1 luckily

[rodrigoaguilera]

@utack Can you explain a bit more the process of having this app working on lineageos?

I'm planning to wipe my phone and install lineage soon but I want this app to work correctly.
Is this issue relevant for correct function?
#22

What I'm looking for is some brief steps like
1- Encrypt phone
2- Set a lock pattern
3- Run the command vdc cryptfs changepw password oldpin newpassword
...

[utack]

@rodrigoaguilera did not use the app
Your steps are exactly what I did
I installed Lineage, installed the zip file they provide to root the phone, set up a pin and triggered encryption from the settings->security, used "adb shell" on my pc, typed "su" to get root in there, used the vdc command to change the pin to a long password for the encrypted data partition

[rodrigoaguilera]

@utack
Thank you.

From what I read you have to run the command every time you change the lock gesture/password.

Still I find interesting the reboot after some tries features and I hope it works just by installing the app.

[thomasjfox]

before upgrading to Lineage 14.1 this month, I was using Lineage 13.x.

Changing the password was broken for a while in Lineage 13.x and then later on fixed.
It worked fine for me when "upgrading" from a PIN to a passphrase on 13.x.

Reboot after xx wrong PIN entries works on Lineage 13.x and 14.1 for me.

[thomasjfox]

btw: I have a second phone for development, so I could easily switch between Lineage 13.x and 14.x to reproduce issues.

The 13.0 build is from 2017-04-22, the 14.1 build from 2017-06-07.

[eX00r]

I am experiencing the same issue in my Huawi Honor 5x (kiwi) with LineageOS-14.1-20170705-nightly-kiwi. When entering the old password in snooperstopper it says "invalid password".

Unfortunately trying to change the device encryption password with the mentioned vdc command gives me:

/system/bin/sh: vdc: not found

I typed: vdc cryptfs changepw password myoldpin newpassword

I Trier terminal emulator on the device vor shell via ADB. Both with the same error of course.

[thomasjfox]

On Thursday, 13 July 2017 12:37:27 CEST eX00r wrote: /system/bin/sh: vdc: not found I typed: vdc cryptfs changepw password myoldpin newpassword

the vdc binary must be there somewhere. Did you try with a root shell? Either use "adb root" followed by "adb shell" from your host. Or use "su" to become root when running the command from the phone. Cheers, Thomas

[eX00r]

@thomasjfox thanks. When running with su from phone ( su vdc cryptfs changepw password myoldpin newpassword) terminal answers with: unknown id: vdc

Will try from host later.

Sent from my HUAWEI KIW-L21 using FastHub

[rodrigoaguilera]

I think you are using "su" as if it was the "sudo" command.
You have to type "su" first alone to get a root shell

[eX00r]

@thomasjfox thanks a lot and sorry. That worked like a charm. I have seperated the encryption password from the screenunlocking pin successfully.

Sent from my HUAWEI KIW-L21 using FastHub

[DJCrashdummy]

while research and testing for my comment (be careful! i'm not sure if it also works for CM/LOS 13) at Cryptfs Password i came across this issue...

i just have to point out one error at @xenithorb's #8 (comment):

• at line 11: the password is still test2 until you changed it at line 12.
  ...as the status-code 1 in line 10 stands for false/unsuccessful and status-code 0 like in line 13 or 15 for true/successful
• at line 12: you would have changed the password also with foo instead of test1, since the currentpasswd seems to be irrelevant.

for more explanation have a look at the bigger part of my linked comment.
for now the only question marks left in my head are, what should the status-codes -1 and -2 (which i also came across while testing) tell us...!?

btw, thanks for the whole thread, it helped to understand the android-encryption-thing!

[utack]

FWIW i now run an AOSP 8.1 rom and the old
vdc cryptfs changepw password oldpin newpassword
still works for me
Even though I just had a situation where the default_password was used, it just ignored the wrong "oldpin", and set my "newpassword"

[DJCrashdummy]

@utack thanks for the info.

if you read the bigger part of this comment this is absolutely clear (and nothing new), because whatever you type at oldpin is completely samey.